JP7496823B2 - 不正フレーム検知装置および不正フレーム検知方法 - Google Patents

不正フレーム検知装置および不正フレーム検知方法 Download PDF

Info

Publication number
JP7496823B2
JP7496823B2 JP2021529985A JP2021529985A JP7496823B2 JP 7496823 B2 JP7496823 B2 JP 7496823B2 JP 2021529985 A JP2021529985 A JP 2021529985A JP 2021529985 A JP2021529985 A JP 2021529985A JP 7496823 B2 JP7496823 B2 JP 7496823B2
Authority
JP
Japan
Prior art keywords
service
frame
communication
ecu
frame detection
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
JP2021529985A
Other languages
English (en)
Other versions
JPWO2021002264A1 (ja
Inventor
剛 岸川
亮 平野
良浩 氏家
智之 芳賀
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
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 Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JPWO2021002264A1 publication Critical patent/JPWO2021002264A1/ja
Application granted granted Critical
Publication of JP7496823B2 publication Critical patent/JP7496823B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • G—PHYSICS
    • 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/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
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • 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/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle

Landscapes

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

Description

本開示は、車載ネットワークセキュリティ技術についての不正フレーム検知装置および不正フレーム検知方法に関する。
近年、自動車の中のシステムには、電子制御ユニット（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ、以下、ＥＣＵ）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。
車載ネットワークには、多数の規格が存在するが、その中でも最も主流な車載ネットワークの一つに、Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（以降、ＣＡＮ（登録商標））という規格が存在する。
一方で、自動運転やコネクテッドカーの普及に伴い、車載ネットワークトラフィックの増大が予想され、車載イーサネット（登録商標）の普及が進んでいる。車載イーサネットでは、従来のようなシグナル指向型通信から、サービス指向型通信が導入されるようになっており、開発プロセスの効率化も図ることが可能となる。サービス指向型通信の実現方法として、Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ｍｉｄｄｌｅ ＷａｒＥ Ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（以下ＳＯＭＥ／ＩＰ）が、ＡＵＴｏｍｏｔｉｖｅ Ｏｐｅｎ Ｓｙｓｔｅｍ ＡＲｃｈｉｔｅｃｔｕｒｅ（ＡＵＴＯＳＡＲ）で規定されている。
ＳＯＭＥ／ＩＰ通信においても、ＣＡＮと同様に不正なノードによるなりすまし攻撃の脅威が考えられる。このような脅威に対して、従来のＩＰ通信で用いられてきた、暗号通信を用いて不正なノードによる通信を防ぐ方法が開示されている（例えば、非特許文献１および非特許文献２参照）。
ＲＦＣ５４０６：Ｇｕｉｄｅｌｉｎｅｓ ｆｏｒ Ｓｐｅｃｉｆｙｉｎｇ ｔｈｅ Ｕｓｅ ｏｆ ＩＰｓｅｃ Ｖｅｒｓｉｏｎ２ ＩＥＥＥ ８０２．１ＡＥ：ＭＡＣ Ｓｅｃｕｒｉｔｙ
しかしながら、非特許文献１または非特許文献２の方法では、暗号通信を用いるため、送受信ノードによる暗号化および復号処理が必要となりオーバーヘッドが発生する。また鍵管理が重要となり、鍵が漏洩した場合には、なりすまし攻撃が可能となってしまう。
そこで、本開示は、通信時のオーバーヘッドを抑制しつつ、不正なＥＣＵが正規のサーバまたはクライアントになりすますことを防ぐことができる不正フレーム検知装置等を提供する。
上記課題を解決するために、本開示の一態様に係る不正フレーム検知装置は、複数の電子制御ユニットと、複数のネットワークと、によって構成される車載ネットワークシステムにおける、不正フレーム検知装置であって、前記複数の電子制御ユニットは、サービス指向型通信により、前記不正フレーム検知装置を介して通信を行い、前記不正フレーム検知装置は、前記複数のネットワークのそれぞれに対応する複数の通信ポートと、通信制御部と、不正フレーム検知部と、を備え、前記複数の通信ポートのそれぞれは、前記複数のネットワークのうちの対応する所定のネットワークに接続され、前記所定のネットワークを介して前記所定のネットワークに接続された電子制御ユニットとフレームの送受信を行うインタフェースを有し、前記通信制御部は、前記複数の通信ポートのうちのいずれかの通信ポートがフレームを受信した場合、前記複数の通信ポートのうちの前記フレームを受信した通信ポート以外の通信ポートから、前記フレームが送信されるように転送制御を行い、前記不正フレーム検知部は、前記フレームに含まれる、サービスの識別子と、前記フレームを送信した電子制御ユニットがサービスの提供側かサービスの受領側かを示すサービスのタイプと、前記フレームを受信した通信ポートを識別するためのポート情報とが、予め定められた許可ルールに合致するか否かを判断し、前記判断の結果を出力する。
本開示によれば、通信時のオーバーヘッドを抑制しつつ、不正なＥＣＵが正規のサーバまたはクライアントになりすますことを防ぐことができる。
図１は、実施の形態１における、車載ネットワークシステムの全体構成を示す図である。 図２は、実施の形態１における、ＳＯＭＥ／ＩＰ ＳＤのメッセージフォーマットを示す図である。 図３は、実施の形態１における、ＳＯＭＥ／ＩＰ ＳＤのメッセージの一例を示す図である。 図４は、実施の形態１における、Ｚｏｎｅ ＥＣＵの構成を示す図である。 図５は、実施の形態１における、ブレーキＥＣＵの構成を示す図である。 図６は、実施の形態１における、鍵の一例を示す図である。 図７は、実施の形態１における、モードと車両状態の一例を示す図である。 図８は、実施の形態１における、許可テーブルに格納される許可ルールの一例を示す図である。 図９は、実施の形態１における、Ｚｏｎｅ ＥＣＵによる初期化モードにおける許可テーブルの登録シーケンスを示す図である。 図１０は、実施の形態１における、Ｚｏｎｅ ＥＣＵによる通常モードにおける不正なフレームを遮断するシーケンスを示す図である。 図１１は、実施の形態１における、Ｚｏｎｅ ＥＣＵによる通常モードにおける許可テーブルの更新シーケンスを示す図である。 図１２は、実施の形態１における、Ｚｏｎｅ ＥＣＵによる全体処理のフローチャートである。 図１３は、実施の形態１における、Ｚｏｎｅ ＥＣＵによるモード変更処理のフローチャートである。 図１４は、その他の変形例（３）における、Ｚｏｎｅ ＥＣＵによる全体処理のフローチャートである。 図１５は、その他の変形例（４）における、マニフェストファイルの一例を示す図である。 図１６は、その他の変形例（４）および変形例（５）を組み合わせたときの、Ｚｏｎｅ ＥＣＵによる全体処理のフローチャートである。
本開示の一実施態様の不正フレーム検知装置は、複数の電子制御ユニットと、複数のネットワークと、によって構成される車載ネットワークシステムにおける、不正フレーム検知装置であって、前記複数の電子制御ユニットは、サービス指向型通信により、前記不正フレーム検知装置を介して通信を行い、前記不正フレーム検知装置は、前記複数のネットワークのそれぞれに対応する複数の通信ポートと、通信制御部と、不正フレーム検知部と、を備え、前記複数の通信ポートのそれぞれは、前記複数のネットワークのうちの対応する所定のネットワークに接続され、前記所定のネットワークを介して前記所定のネットワークに接続された電子制御ユニットとフレームの送受信を行うインタフェースを有し、前記通信制御部は、前記複数の通信ポートのうちのいずれかの通信ポートがフレームを受信した場合、前記複数の通信ポートのうちの前記フレームを受信した通信ポート以外の通信ポートから、前記フレームが送信されるように転送制御を行い、前記不正フレーム検知部は、前記フレームに含まれる、サービスの識別子と、前記フレームを送信した電子制御ユニットがサービスの提供側かサービスの受領側かを示すサービスのタイプと、前記フレームを受信した通信ポートを識別するためのポート情報とが、予め定められた許可ルールに合致するか否かを判断し、前記判断の結果を出力する。
例えば、複数の通信ポートのそれぞれに接続されるＥＣＵは予め決まっており、すなわち、当該ＥＣＵから当該ＥＣＵに接続された通信ポートへ送信されるフレームに含まれるサービスの識別子、サービスのタイプおよびポート情報は予め決まっている。つまり、複数の通信ポートのそれぞれが受信する正規のフレームに含まれるサービスの識別子、サービスのタイプおよびポート情報を許可ルールとして予め定めることができ、その後受信したフレームに含まれるこれらの情報が許可ルールに合致しない場合には、不正なフレームが送信されていることがわかる。このように、サービス指向型通信の、サーバまたはクライアントの物理的な配置とサービスの内容に基づいてフレーム（以下ではメッセージともいう）の不正を検知することが可能となり、車載ネットワークシステムの安全性が高まる。また、送受信ノードによる暗号化および復号処理が不要であるため、通信時のオーバーヘッドを抑制しつつ、不正なＥＣＵが正規のサーバまたはクライアントになりすますことを防ぐことができる。
また、前記通信制御部は、前記複数の通信ポートのうちのいずれかの通信ポートがフレームを受信した場合に、前記フレームに含まれる、前記サービスの識別子と、前記サービスのタイプと、前記ポート情報とが、前記許可ルールに合致しないときには、前記フレームについて前記転送制御を行わなくてもよい。
これにより、この場合、受信したフレームが不正なフレームであるとわかるため、不正なフレームを他のＥＣＵへ転送することを防ぐことが可能となり、車載ネットワークシステムの安全性が高まる。
また、前記不正フレーム検知装置は、さらにルール更新部を備え、前記ルール更新部は、前記複数の通信ポートのうちのいずれか通信ポートが、電子制御ユニットの利用するサービスに関するマニフェスト情報を含むフレームを受信した場合、前記マニフェスト情報と、前記マニフェスト情報を含む前記フレームを受信した通信ポートを識別するポート情報とに基づいて、前記許可ルールを更新してもよい。
例えば、車両のアップデート等によって、ＥＣＵが提供するサービスに変更があった場合に、許可ルールの更新が必要になるときがある。そこで、不正フレーム検知装置の通信ポートに接続されたＥＣＵに、自身が利用するサービス、例えば、自身の役割を示すマニフェスト情報を含むフレームを送信させる。これにより、マニフェスト情報と、ポート情報すなわちメッセージの送信元の物理的な配置に基づいて、許可ルールを更新することができる。
また、前記不正フレーム検知装置は、さらにルール生成部を備え、前記ルール生成部は、前記車載ネットワークシステムの初回起動時に、前記複数の通信ポートが受信したフレームに含まれる、前記サービスの識別子と、前記サービスのタイプと、前記ポート情報とに基づいて、前記許可ルールを生成してもよい。
車載ネットワークシステムの初回起動は、例えば、車両が市場に出回る前の車両の工場等で行われ、初回起動時の車載ネットワークは安全な状態にあり、不正フレーム検知装置が受信するフレームは正規のフレームとなる。したがって、このような安全な状態にある車載ネットワークシステムで観測される通信をもとに、不正なフレームを検知するための許可ルールの生成が可能となる。また、車載ネットワークの初回起動時に自動で許可ルールを生成でき効率的である。
また、前記不正フレーム検知装置は、さらに、前記複数のネットワークに流れるフレームに基づいて、前記車載ネットワークシステムを搭載する車両の状態を判定する車両状態判定部を備え、前記不正フレーム検知部は、前記サービスの識別子と、前記サービスのタイプと、前記ポート情報と、さらに前記車両の状態とが、前記許可ルールに合致するか否かを判断してもよい。
例えば、車両が停車しているときにしか利用されないサービス、車両が走行しているときにしか利用されないサービスといったように、サービスには利用されるときの車両状態が決まっているものがある。したがって、サービスが利用される車両状態と、サーバまたはクライアントの物理的な配置をもとに、不正なフレームを検知することが可能となり、車載ネットワークシステムの安全性が高まる。
また、前記車両状態判定部は、前記車両の状態が自動運転モードであるか否かを判定し、前記不正フレーム検知部は、前記サービスの識別子が、自動運転に関わるサービスである場合に限り、前記サービスの識別子と、前記サービスのタイプと、前記ポート情報と、前記車両の状態とが、前記許可ルールに合致するか否かを判断し、前記許可ルールには、前記車両の状態が自動運転モードであるというルールが含まれていてもよい。
自動運転に関わるサービスは、特に安全性を高める必要がある。したがって、不正を検知するフレームを自動運転に関わるサービスに関するものに限ることで、自動運転に関わるサービスが利用されるタイミングにおける、不正なフレームの検知が可能となり、車載ネットワークシステムの安全性が高まる。
また、前記サービス指向型通信はＳｃａｌａｂｌｅ Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ ＭｉｄｄｌｅｗａｒＥ ｏｖｅｒ ＩＰ（ＳＯＭＥ／ＩＰ）であり、前記サービスのタイプは、Ｏｆｆｅｒ、Ｆｉｎｄ、ＳｕｂｓｃｒｉｂｅおよびＳｕｂｓｃｒｉｂｅ Ａｃｋのいずれか１つを含んでいてもよい。
これにより、ＳＯＭＥ／ＩＰのＳｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙの段階で、不正なフレームの検知が可能となり、不正なサーバまたはクライアントと正常なクライアントまたはサーバ間のセッション確立を阻止することが可能となる。
また、本開示の一態様に係る不正フレーム検知方法は、複数の電子制御ユニットと、複数のネットワークと、によって構成される車載ネットワークシステムにおける、不正フレーム検知装置による不正フレーム検知方法であって、前記複数の電子制御ユニットは、サービス指向型通信により、前記不正フレーム検知装置を介して通信を行い、前記不正フレーム検知装置は、前記複数のネットワークのそれぞれに対応する複数の通信ポートを備え、前記複数の通信ポートのそれぞれは、前記複数のネットワークのうちの対応する所定のネットワークに接続され、前記所定のネットワークを介して前記所定のネットワークに接続された電子制御ユニットとフレームの送受信を行うインタフェースを有し、前記不正フレーム検知方法は、前記複数の通信ポートのうちのいずれかの通信ポートがフレームを受信した場合、前記複数の通信ポートのうちの前記フレームを受信した通信ポート以外の通信ポートから、前記フレームが送信されるように転送制御を行う転送制御ステップと、前記フレームに含まれる、サービスの識別子と、前記フレームを送信した電子制御ユニットがサービスの提供側かサービスの受領側かを示すサービスのタイプと、前記フレームを受信した通信ポートを識別するためのポート情報とが、予め定められた許可ルールに合致するか否かを判断し、前記判断の結果を出力する不正フレーム検知ステップと、を含む。
これにより、サービス指向型通信の、サーバまたはクライアントの物理的な配置とサービスの内容に基づいてメッセージの不正を検知することが可能となり、車載ネットワークシステムの安全性が高まる。また、通信時のオーバーヘッドを抑制しつつ、不正なＥＣＵが正規のサーバまたはクライアントになりすますことを防ぐことができる。
以下、図面を参照しながら、本開示の実施の形態に関わる車載ネットワークシステムについて説明する。なお、以下で説明する実施の形態は、いずれも本開示の好ましい一具体例を示す。つまり、以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置および接続形態、ステップ、ステップの順序などは、本開示の一例であり、本開示を限定する主旨ではない。本開示は、請求の範囲の記載に基づいて特定される。したがって、以下の実施の形態における構成要素のうち、本開示の最上位概念を示す独立請求項に記載されていない構成要素は、本開示の課題を達成するために必ずしも必要ではないが、より好ましい形態を構成する構成要素として説明される。
（実施の形態１）
以下、複数のＥＣＵがＣＡＮバスおよびイーサネットを介して通信する車載ネットワークを用いた車載ネットワークシステムを搭載した車両における、不正なフレームを検知し、遮断する不正フレーム検知装置について説明する。
［１．１ 車載ネットワークシステムの全体構成］
図１は、実施の形態１における、車載ネットワークシステム１の全体構成を示す図である。車載ネットワークシステム１は、車両に搭載され、複数のＥＣＵと、複数のネットワークと、によって構成される。複数のネットワークには、イーサネットおよびＣＡＮ等が含まれる。車載ネットワークシステム１は、Ｚｏｎｅ ＥＣＵ１００ａ、１００ｂ、１００ｃおよび１００ｄと、ブレーキＥＣＵ２００ａ、ステアリングＥＣＵ２００ｂ、カメラＥＣＵ２００ｃ、ヘッドユニットＥＣＵ２００ｄ、レーダーＥＣＵ２００ｅおよびアンテナＥＣＵ２００ｆと、イーサネット１１、１２、１３、１４、１５および１６と、ＣＡＮ１０および１７とから構成される。
Ｚｏｎｅ ＥＣＵ１００ａは、Ｚｏｎｅ ＥＣＵ１００ｂとイーサネット１２によって接続され、Ｚｏｎｅ ＥＣＵ１００ｃとはイーサネット１１によって接続されている。さらにＺｏｎｅ ＥＣＵ１００ａはカメラＥＣＵ２００ｃおよびヘッドユニットＥＣＵ２００ｄとイーサネット１５によって接続されている。
Ｚｏｎｅ ＥＣＵ１００ｂは、Ｚｏｎｅ ＥＣＵ１００ａとの接続のほかに、Ｚｏｎｅ ＥＣＵ１００ｄとイーサネット１３によって接続されている。さらにＺｏｎｅ ＥＣＵ１００ｂは、レーダーＥＣＵ２００ｅとＣＡＮ１７によって接続されている。
Ｚｏｎｅ ＥＣＵ１００ｃは、Ｚｏｎｅ ＥＣＵ１００ａとの接続のほかに、Ｚｏｎｅ ＥＣＵ１００ｄとイーサネット１４によって接続されている。また、Ｚｏｎｅ ＥＣＵ１００ｃは、ブレーキＥＣＵ２００ａおよびステアリングＥＣＵ２００ｂとＣＡＮ１０によって接続されている。
Ｚｏｎｅ ＥＣＵ１００ｄは、Ｚｏｎｅ ＥＣＵ１００ｂおよび１００ｃと接続されているほかに、アンテナＥＣＵ２００ｆとイーサネット１６によって接続されている。
各Ｚｏｎｅ ＥＣＵは、互いにイーサネットで接続されており、サービス指向型通信を用いて通信を行う。サービス指向型通信は、例えば、ＳＯＭＥ／ＩＰである。１つのＺｏｎｅ ＥＣＵが接続されており、他にＺｏｎｅ ＥＣＵと接続されていないネットワーク、すなわち、ＣＡＮ１０および１７ならびにイーサネット１５および１６をゾーンと呼び、各Ｚｏｎｅ ＥＣＵは、それぞれのゾーンに接続されるＥＣＵ（センサまたはアクチュエータに接続されるＥＣＵ）の情報取得および制御を行う。
［１．２ ＳＯＭＥ／ＩＰメッセージフォーマット］
ＳＯＭＥ／ＩＰには、Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ、Ｆｉｒｅ／Ｆｏｒｇｅｔ、ＥｖｅｎｔｓおよびＧｅｔ／Ｓｅｔ／Ｎｏｔｉｆｉｅｒの４種類の方法が規定されており、これらを組み合わせることで、サービス指向型通信を実現する。ＳＯＭＥ／ＩＰでは、通信相手とセッションを確立する方法も準備されており、その方法をＳｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ（ＳＤ）とよぶ。
図２は、実施の形態１における、ＳＯＭＥ／ＩＰ ＳＤのメッセージフォーマットを示す図である。図２に示されるメッセージフォーマットは、イーサネットのペイロード部に格納される。図２の１つの行は３２ビット長であり、前半はＳＯＭＥ／ＩＰヘッダ、後半がＳＯＭＥ／ＩＰ ＳＤのペイロードである。
ＳＯＭＥ／ＩＰヘッダのＭｅｓｓａｇｅ ＩＤは、ＳＯＭＥ／ＩＰ ＳＤの場合は０ｘＦＦＦＦ８１００である。Ｌｅｎｇｔｈは、Ｌｅｎｇｔｈフィールドより後のデータのバイト数を格納する。Ｒｅｑｕｅｓｔ ＩＤは、Ｃｌｉｅｎｔ ＩＤとＳｅｓｓｉｏｎ ＩＤをあわせた数値を格納する。Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙの場合は、Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎを０ｘ０１、Ｉｎｔｅｒｆａｃｅ Ｖｅｒｓｉｏｎを０ｘ０１、Ｍｅｓｓａｇｅ Ｔｙｐｅを０ｘ０２、Ｒｅｔｕｒｎ Ｃｏｄｅを０ｘ００にそれぞれ設定される。
図３は、実施の形態１における、ＳＯＭＥ／ＩＰ ＳＤのメッセージの一例を示す図である。図３に示されるＳＯＭＥ／ＩＰ ＳＤメッセージは、サービスＩＤが０ｘ１０００のサービスを提供可能であることを示すメッセージの一例である。
まず、Ｅｎｔｒｙの領域では、Ｆｌａｇｓには０ｘ８０が設定されており、Ｒｅｂｏｏｔ Ｆｌａｇが設定されている。Ｒｅｓｅｒｖｅｄ領域は０に設定されている。Ｌｅｎｇｔｈ ｏｆ Ｅｎｔｒｉｅｓ Ａｒｒａｙ ｉｎ ＢｙｔｅｓにはＥｎｔｒｙのバイト数が格納されており、この例ではＥｎｔｒｙのバイト数は１６バイトである。
Ｔｙｐｅはサービスのタイプであり、サービスのタイプは、Ｏｆｆｅｒ、Ｆｉｎｄ、ＳｕｂｓｃｒｉｂｅおよびＳｕｂｓｃｒｉｂｅ Ａｃｋのいずれか１つを含む。例えば、Ｔｙｐｅは０ｘ００でＦｉｎｄ、０ｘ０１でＯｆｆｅｒを意味する。Ｆｉｎｄは、サービスの提供を受けるクライアントＥＣＵが、必要なサービスの提供を要求するときに用いられ、Ｏｆｆｅｒは、サービスの提供を行うサーバＥＣＵが、自身の提供可能なサービスを通知する場合に用いる。この例では、Ｔｙｐｅが０ｘ０１となっており、このメッセージは、サーバＥＣＵが自身の提供可能なサービスに関する情報を通知しているメッセージを示している。Ｉｎｄｅｘ １ｓｔ ｏｐｔｉｏｎｓは、最初のオプションの位置を示し、この例では０、つまり最初であることを示している。Ｉｎｄｅｘ ２ｎｄ ｏｐｔｉｏｎｓは、２つ目のオプションの位置を示し、この例では０が記載されている。＃ｏｆ ｏｐｔ１にはオプション１の個数が記載されており、この例では１が格納されている。＃ｏｆ ｏｐｔ２はオプション２の個数が記載されており、この例では０が格納されており、オプション２を用いないことを示している。
Ｓｅｒｖｉｃｅ ＩＤは、サービスの種類を示すＩＤを格納するフィールドであり、図３の例では０ｘ１０００が格納されている。Ｉｎｓｔａｎｃｅ ＩＤは、サービスのインスタンスを示すＩＤであり、図３の例では０ｘ０００１のインスタンスであることを示している。
Ｍａｊｏｒ Ｖｅｒｓｉｏｎは、サービスのバージョン管理に用いる情報であり、図３の例では０ｘ０１に設定されている。ＴＴＬは、サービスの有効期限（秒）を設定するフィールドであり、図３の例では０ｘＦＦＦＦが設定されている。ＴＴＬが０ｘＦＦＦＦの場合は、ＥＣＵの次の起動タイミングまでサービスが有効であることを示している。Ｍｉｎｏｒ Ｖｅｒｓｉｏｎは、サービスのバージョン管理に用いられる情報であり、図３の例では０ｘ０００００００２に設定されている。
次に、Ｏｐｔｉｏｎの領域では、まずＬｅｎｇｔｈ ｏｆ Ｏｐｔｉｏｎｓ Ａｒｒａｙ ｉｎ ＢｙｔｅｓにＯｐｔｉｏｎ領域の長さが格納され、図３の例ではＯｐｔｉｏｎ領域の長さが１２バイトであることを示している。
次のＬｅｎｇｔｈでは、オプションの種類に応じて設定される値が決まる。図３の例では、ＩＰｖ４を用いた通信例を示しており、この時、Ｌｅｎｇｔｈは９、Ｔｙｐｅは０ｘ０４、Ｒｅｓｅｒｖｅｄは０ｘ００となる。ＩＰｖ４アドレスは、サーバのＩＰアドレスであり、図３の例では、１９２．１６８．０．１が設定されている。次のＲｅｓｅｒｖｅｄ領域は０が格納される。Ｌ４－Ｐｒｏｔｏには０ｘ１１が格納されており、Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）を用いることを表している。最後にポート番号が格納されており、図３の例では、３５０００番ポートであることを示している。
［１．３ Ｚｏｎｅ ＥＣＵ１００ａの構成］
次に、Ｚｏｎｅ ＥＣＵについてＺｏｎｅ ＥＣＵ１００ａに着目して説明する。
図４は、実施の形態１における、Ｚｏｎｅ ＥＣＵ１００ａの構成を示す図である。Ｚｏｎｅ ＥＣＵ１００ａは、例えばプロセッサ、メモリおよび通信インタフェース等を備えるコンピュータにより実現され、ホスト部１０１と、通信部１０２と、鍵保持部１０３と、スイッチ１１０とから構成される。また、Ｚｏｎｅ ＥＣＵ１００ａは、不正フレーム検知装置を備える。不正フレーム検知装置は、複数のネットワークのそれぞれに対応する複数の通信ポートと、通信制御部と、不正フレーム検知部と、を備える。Ｚｏｎｅ ＥＣＵ１００ａにおけるスイッチ１１０が不正フレーム検知装置を構成していてもよく、不正フレーム検知部は、後述する通信制御部１１１によって実現されてもよい。また、Ｚｏｎｅ ＥＣＵ１００ａにおけるホスト部１０１、通信部１０２およびスイッチ１００が不正フレーム検知装置を構成していてもよく、不正フレーム検知部は、ホスト部１０１によって実現されてもよい。
なお、Ｚｏｎｅ ＥＣＵ１００ｂ、１００ｃおよび１００ｄは、Ｚｏｎｅ ＥＣＵ１００ａと同様の構成を有するが、接続されるイーサネットの数、およびＣＡＮと接続されるかによって、一部構成が異なる。例えば、Ｚｏｎｅ ＥＣＵ１００ｂでは、接続されるイーサネットの数は２つであり、ＣＡＮ１７は通信部１０２に接続される構成となる。複数のＥＣＵ１００ａ、１００ｂ、１００ｃおよび１００ｄは、サービス指向型通信（例えばＳＯＭＥ／ＩＰ）により、それぞれの不正フレーム検知装置（具体的にはスイッチ１１０）を介して通信を行う。
ホスト部１０１は、Ｚｏｎｅ ＥＣＵ１００ａのメイン部分であり、ＣＰＵとメモリによって実現される。ホスト部１０１は、通信部１０２から、通信内容を受信し、通信内容に応じた処理を実施する。例えばＺｏｎｅ ＥＣＵ１００ａの場合は、カメラＥＣＵ２００ｃから通知される情報を受信し、周辺に車両が走行していないか等の認識処理を行い、ブレーキＥＣＵ２００ａや、ステアリングＥＣＵ２００ｂを制御するために、Ｚｏｎｅ ＥＣＵ１００ｂに、制御情報を送信する。
このようにＺｏｎｅ ＥＣＵのホスト部１０１は、自身が接続するゾーンのネットワークに流れる通信内容と、他のＺｏｎｅ ＥＣＵからの通信内容、すなわち、他のゾーンの通信内容を受信し、解釈することで、車両の制御処理を実現する。
またスイッチ１１０内の許可テーブル１１６の更新を行うために、ホスト部１０１は、受信したフレームが正常なＥＣＵからの更新要求を示すフレームであるかを、鍵保持部１０３に格納される鍵を用いて検証する。
また、ホスト部１０１は、車載ネットワークシステム１の初回起動時に、複数の通信ポートが受信したフレームに含まれる、サービスの識別子と、サービスのタイプと、ポート情報とに基づいて、許可ルールを生成（登録）するルール生成部の一例である。
また、ホスト部１０１は、複数のネットワークに流れるフレームに基づいて、車載ネットワークシステム１を搭載する車両の状態を判定する車両状態判定部の一例である。ホスト部１０１は、モード保持部１０４に格納されるモードおよび車両状態を参照し、また更新を行う。
通信部１０２は、ホスト部１０１とスイッチ１１０との通信インタフェース、あるいはＣＡＮの通信インタフェースであり、通信コントローラまたはトランシーバ等によって実現される。
鍵保持部１０３は、暗号化処理等に用いる秘密情報の保持部である。
モード保持部１０４は、初期化モードか通常モードかを示すモードと、車両状態が保持されており、ホスト部１０１によって、値が更新される。
スイッチ１１０は、イーサネットフレームの転送制御を行う装置であり、通信制御部１１１と、通信ポート１１２、１１３、１１４、１１５と、許可テーブル１１６とから構成される。
通信制御部１１１は、複数の通信ポートのうちのいずれかの通信ポートがフレームを受信した場合、複数の通信ポートのうちのフレームを受信した通信ポート以外の通信ポートから、フレームが送信されるように転送制御を行う。具体的には、通信制御部１１１は、通信ポート１１２、１１３、１１４から通知されるイーサネットフレームに含まれるＩＰアドレス、ポート番号、ＭＡＣアドレスおよびＶＬＡＮタグ等を確認して、適切な通信ポートへイーサネットフレームを転送する。
また、受信した内容をホスト部１０１へ通知するために、通信制御部１１１は、通信ポート１１５へも、イーサネットフレームを通知する。
また、通信制御部１１１は、通信ポートが受信したフレームに含まれる、サービスの識別子と、フレームを送信したＺｏｎｅ ＥＣＵがサービスの提供側かサービスの受領側かを示すサービスのタイプと、フレームを受信した通信ポートを識別するためのポート情報とが、予め定められた許可ルールに合致するか否かを判断し、当該判断の結果を出力する。許可ルールは、許可テーブル１１６に保持されている。また、通信制御部１１１は、複数の通信ポートのうちのいずれかの通信ポートがフレームを受信した場合に、フレームに含まれる、サービスの識別子と、サービスのタイプと、ポート情報とが、許可ルールに合致しないときには、当該フレームについて転送制御を行わない。具体的には、通信制御部１１１は、不正なフレームの転送を防止するために、許可テーブル１１６を参照し、ＳＯＭＥ／ＩＰメッセージのサービスとメッセージのタイプおよび受信したポート番号の対応を確認し、許可テーブル１１６に保持された許可ルールに合致しない場合は転送を行わない。
なお、通信ポートが受信したフレームに含まれる、サービスの識別子と、フレームを送信したＺｏｎｅ ＥＣＵがサービスの提供側かサービスの受領側かを示すサービスのタイプと、フレームを受信した通信ポートを識別するためのポート情報とが、予め定められた許可ルールに合致するか否かを判断し、当該判断の結果を出力するのをホスト部１０１が行ってもよい。
通信ポート１１２、１１３、１１４、１１５は、通信先との通信インタフェースである。複数の通信ポートのそれぞれは、複数のネットワークのうちの対応する所定のネットワークに接続され、所定のネットワークを介して所定のネットワークに接続されたＺｏｎｅ ＥＣＵとフレームの送受信を行うインタフェースを有する。通信ポート１１２は、所定のネットワークとしてイーサネット１１に接続され、イーサネット１１に接続されたＺｏｎｅ ＥＣＵ１００ｃとの通信インタフェースとなっており、通信ポート１１３は、所定のネットワークとしてイーサネット１２に接続され、イーサネット１２に接続されたＺｏｎｅ ＥＣＵ１００ｂとの通信インタフェースとなっており、通信ポート１１４は、所定のネットワークとしてイーサネット１５に接続され、イーサネット１５に接続されたカメラＥＣＵ２００ｃおよび、ヘッドユニットＥＣＵ２００ｄとの通信インタフェースとなっている。通信ポート１１５は、通信部１０２と接続されており、ホスト部１０１との通信インタフェースとなっている。
許可テーブル１１６は、不正なＳＯＭＥ／ＩＰメッセージの転送を禁止するための許可ルールが保持されている。許可テーブル１１６はフラッシュメモリ等の不揮発メモリによって実現される。許可テーブル１１６の詳細は後述する。
［１．４ ブレーキＥＣＵ２００ａの構成］
図５は、実施の形態１における、ブレーキＥＣＵ２００ａの構成を示す図である。なお、ステアリングＥＣＵ２００ｂ、カメラＥＣＵ２００ｃ、ヘッドユニットＥＣＵ２００ｄ、レーダーＥＣＵ２００ｅおよびアンテナＥＣＵ２００ｆも同様の構成のため、これらの構成の説明を省略する。
図５に示されるように、ブレーキＥＣＵ２００ａは、通信部２０１と、ホスト部２０２と、から構成される。
通信部２０１は、ネットワークとの接続インタフェースであり、ＣＡＮ１０と接続される。通信部２０１は、ネットワークに流れるフレームを受信し、ホスト部２０２に通知するとともに、ホスト部２０２からの送信要求を受けて、ＣＡＮ１０にフレームの送信を行う。
ホスト部２０２は、センサまたはアクチュエータ等の外部接続機器から取得した情報を、フレームに含めて、通信部２０１へ送信要求を行う。また、通信部２０１から通知されるフレームの情報をもとに、ホスト部２０２は、アクチュエータの制御処理を行う。
［１．５ 鍵保持部に格納される鍵の一例］
図６は、実施の形態１における、鍵保持部１０３に格納される鍵の一例を示す図である。図６に示すように鍵は通信ポートごとに保持される。車両のアップデート等によって、ＥＣＵの提供するＳＯＭＥ／ＩＰにおけるサービスに変更があった場合に、許可テーブル１１６を変更（更新）するときに秘密鍵が用いられる。Ｚｏｎｅ ＥＣＵ１００ａは、秘密鍵を用いてチャレンジレスポンス認証を行い、正しいＥＣＵからの変更要求であると判断できた場合にのみ、許可テーブル１１６の該当サービスにおいて、ポート番号の追加もしくは削除、またはタイプの変更等を実施する。
図６の例は、通信ポート１１２に対応する鍵は０ｘ１１１１１１１１であり、通信ポート１１３に対応する鍵は０ｘ２２２２２２２２、通信ポート１１４に対応する鍵は０ｘ３３３３３３３３、通信ポート１１５に対応する鍵は０ｘ４４４４４４４４であることを示している。鍵は、工場における製造段階において、鍵保持部１０３に書き込まれる。
なお、本実施の形態では、鍵保持部１０３は、鍵を通信ポートごとに保持しているが、ＥＣＵごとに保持していてもよい。また本実施の形態では、鍵保持部１０３が保持する鍵として共通鍵を想定しているが、鍵保持部１０３は、他のＥＣＵの公開鍵または自身の秘密鍵を保持していてもよい。また、鍵の鍵保持部１０３への書き込みは工場出荷段階で行われなくてもよく、例えば、初回イグニッションＯＮ時に、鍵の交換が行われてもよいし、公開鍵を用いて、イグニッションＯＮの都度、鍵の共有が行われてもよい。
［１．６ モード保持部に格納されるモードの一例］
図７は、実施の形態１における、モード保持部１０４に格納されるモードと車両状態の一例を示す図である。モードは、許可テーブル１１６の初期登録（許可ルールの生成）が行われる「初期化モード」と、許可テーブル１１６に保存されている許可ルールに基づいて、不正なフレームの検出が行われる「通常モード」が存在する。
車両完成後の初回のイグニッション起動時のモードは「初期化モード」であり、許可テーブル１１６の初期登録が行われ、イグニッションＯＦＦ時に、ホスト部１０１によってモードが「通常モード」に切り替えられる。
車両状態は、イーサネットまたはＣＡＮを通じて得られるセンサ情報から、ホスト部１０１によって判断され、更新が行われる。例えば、ホスト部１０１は、車両の速度が０ｋｍ／ｈであれば、車両状態を「停止状態」に更新し、それ以外であれば「走行状態」に更新する。
図７では、現在のモードは「通常モード」であり、車両状態は「走行状態」である例を示している。
［１．７ 許可テーブルに格納されるルールの一例］
図８は、実施の形態１における、Ｚｏｎｅ ＥＣＵ１００ａの許可テーブル１１６に格納される許可ルールの一例を示す図である。図８に示すように許可ルールは、Ｓｅｒｖｉｃｅ ＩＤ、タイプ、通信ポートおよび車両状態の組で表される。
Ｓｅｒｖｉｃｅ ＩＤは、ＳＯＭＥ／ＩＰメッセージに含まれるＳｅｒｖｉｃｅ ＩＤであり、サービスの内容を表す識別子である。サービスのタイプは、フレームを送信したＥＣＵがサービスの提供側かサービスの受領側かを示す。タイプも同様にＳＯＭＥ／ＩＰメッセージに含まれるＴｙｐｅであり、サーバからのメッセージであるかクライアントのメッセージであるかを識別するために用いられる。通信ポートは、フレームを受信した通信ポートを識別するためのポート情報であり、ここでは、同一ルールのＳｅｒｖｉｃｅ ＩＤとタイプが一致するＳＯＭＥ／ＩＰメッセージを受信するポートを表している。なお、同一ルールのＳｅｒｖｉｃｅ ＩＤとタイプが一致するＳＯＭＥ／ＩＰメッセージを受信するポートは１つとは限らない。また車両状態は、該当のＳＯＭＥ／ＩＰメッセージが通信される車両状態を表している。
図８の例では、Ｓｅｒｖｉｃｅ ＩＤが０ｘ１０００を含むメッセージは、サービスとして操舵指示制御を行うメッセージであり、このサービスのＯｆｆｅｒを行うサーバＥＣＵは、通信ポート１１５に接続されており、車両状態が停車中のときに、スイッチ１１０はＳｅｒｖｉｃｅ ＩＤが０ｘ１０００でタイプがＯｆｆｅｒのメッセージを通信ポート１１５から受信することを表している。同様にＳｅｒｖｉｃｅ ＩＤが０ｘ１０００のサービスのＦｉｎｄを行うクライアントＥＣＵは、通信ポート１１２に接続されており、車両状態が停車中のときに、スイッチ１１０はＳｅｒｖｉｃｅ ＩＤが０ｘ１０００でタイプがＦｉｎｄのメッセージを通信ポート１１２から受信することを表している。
Ｓｅｒｖｉｃｅ ＩＤが０ｘ１０１０のサービスのＯｆｆｅｒを行うサーバＥＣＵは、通信ポート１１２に接続されており、車両状態によらず常にスイッチ１１０はＳｅｒｖｉｃｅ ＩＤが０ｘ１０１０でタイプがＯｆｆｅｒのメッセージを通信ポート１１２から受信することを表している。Ｓｅｒｖｉｃｅ ＩＤが０ｘ１０１０のサービスのＦｉｎｄを行うクライアントＥＣＵは、通信ポート１１５に接続されており、車両状態によらず常にスイッチ１１０はＳｅｒｖｉｃｅ ＩＤが０ｘ１０１０でタイプがＦｉｎｄのメッセージを通信ポート１１５から受信することを表している。
Ｓｅｒｖｉｃｅ ＩＤが０ｘ２０００のサービスのＯｆｆｅｒを行うサーバＥＣＵは、通信ポート１１３に接続されており、車両状態によらず常にスイッチ１１０はＳｅｒｖｉｃｅ ＩＤが０ｘ２０００でタイプがＯｆｆｅｒのメッセージを通信ポート１１３から受信することを表している。ＳｅｒｖｉｃｅＩＤが０ｘ２０００のサービスのＦｉｎｄを行うクライアントＥＣＵは、通信ポート１１２または１１５に接続されており、車両状態によらず常にスイッチ１１０はＳｅｒｖｉｃｅ ＩＤが０ｘ２０００でタイプがＦｉｎｄのメッセージを通信ポート１１２または１１５から受信することを表している。
Ｓｅｒｖｉｃｅ ＩＤが０ｘ３０００のサービスのＯｆｆｅｒを行うサーバＥＣＵは、通信ポート１１４に接続されており、車両状態によらず常にスイッチ１１０はＳｅｒｖｉｃｅ ＩＤが０ｘ３０００でタイプがＯｆｆｅｒのメッセージを通信ポート１１４から受信することを表している。Ｓｅｒｖｉｃｅ ＩＤが０ｘ３０００のサービスのＦｉｎｄを行うクライアントＥＣＵは、通信ポート１１５に接続されており、車両状態によらず常にスイッチ１１０はＳｅｒｖｉｃｅ ＩＤが０ｘ３０００でタイプがＦｉｎｄのメッセージを通信ポート１１５から受信することを表している。
なお、本実施の形態では、タイプをＳＯＭＥ／ＩＰ ＳＤのＯｆｆｅｒとＦｉｎｄのいずれかである場合を示しているが、これに限らなくてもよい。例えば、タイプは、ＳｕｂｓｃｒｉｂｅおよびＳｕｂｓｃｒｉｂｅ Ａｃｋのいずれかであってもよい。
［１．８ Ｚｏｎｅ ＥＣＵの初期化モードにおける許可テーブル登録シーケンス］
図９は、実施の形態１における、Ｚｏｎｅ ＥＣＵによる初期化モードにおける許可テーブル１１６のルールの登録シーケンスを示す図である。
（ステップＳ１０１）Ｚｏｎｅ ＥＣＵ１００ｂは、まずＳｅｒｖｉｃｅ ＩＤが０ｘ２０００のサービスを提供可能であることを知らせる、タイプがＯｆｆｅｒのＳＯＭＥ／ＩＰ ＳＤメッセージをイーサネット１２に送信する。
（ステップＳ１０２）Ｚｏｎｅ ＥＣＵ１００ａは、イーサネット１２が接続された通信ポート１１３でＳｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＯｆｆｅｒのメッセージを受信する。
（ステップＳ１０３）次にＺｏｎｅ ＥＣＵ１００ａは、許可テーブル１１６にＳｅｒｖｉｃｅ ＩＤを０ｘ２０００、タイプをＯｆｆｅｒ、通信ポートを１１３とする許可ルールを登録する。
（ステップＳ１０４）Ｚｏｎｅ ＥＣＵ１００ａは、受信したＳｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＯｆｆｅｒのメッセージを、受信した通信ポート以外の通信ポートから転送する。
（ステップＳ１０５）Ｚｏｎｅ ＥＣＵ１００ｃは、特定の通信ポートで、Ｓｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＯｆｆｅｒのメッセージを受信する。
（ステップＳ１０６）Ｚｏｎｅ ＥＣＵ１００ｃは、受信したＳｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＯｆｆｅｒのメッセージに関する許可ルールをＺｏｎｅ ＥＣＵ１００ｃが備える許可テーブル１１６に登録する。
（ステップＳ１０７）Ｚｏｎｅ ＥＣＵ１００ａは、Ｚｏｎｅ ＥＣＵ１００ｂから受けたメッセージが示すサービスの提供を受けるため、Ｓｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＳｕｂｓｃｒｉｂｅのメッセージを、Ｚｏｎｅ ＥＣＵ１００ｂに送信する。
（ステップＳ１０８）Ｚｏｎｅ ＥＣＵ１００ｂは、Ｚｏｎｅ ＥＣＵ１００ａからＳｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＳｕｂｓｃｒｉｂｅメッセージを受け、Ｓｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＳｕｂｓｃｒｉｂｅ ＡｃｋのメッセージをＺｏｎｅ ＥＣＵ１００ａに返信する。
［１．９ Ｚｏｎｅ ＥＣＵの通常モードにおけるフィルタリングシーケンス］
図１０は、実施の形態１における、Ｚｏｎｅ ＥＣＵによる通常モードにおける不正なフレームを遮断するシーケンスを示す図である。図１０では、Ｚｏｎｅ ＥＣＵ１００ｃが不正なＥＣＵであり、不正なＯｆｆｅｒのメッセージを送信して、不正にサービスを提供しようとしている場合を示している。なお許可テーブル１１６は、図９において登録されたものが用いられる。
（ステップＳ２０１）Ｚｏｎｅ ＥＣＵ１００ｃは、Ｓｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＯｆｆｅｒのメッセージをイーサネット１１に送信する。
（ステップＳ２０２）Ｚｏｎｅ ＥＣＵ１００ａは、Ｚｏｎｅ ＥＣＵ１００ｃから送信されたＳｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＯｆｆｅｒのメッセージを、イーサネット１１が接続された通信ポート１１２で受信する。
（ステップＳ２０３）Ｚｏｎｅ ＥＣＵ１００ａは、許可テーブル１１６を参照する。Ｓｅｒｖｉｃｅ ＩＤが０ｘ２０００であり、タイプがＯｆｆｅｒのメッセージは、通信ポート１１３で受信するという許可ルールが記載されているため、Ｚｏｎｅ ＥＣＵ１００ａは、通信ポート１１２で受信したＳｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＯｆｆｅｒのメッセージは不正であると判断し、このメッセージを破棄し、転送しない。
（ステップＳ２０４）次に正規のＺｏｎｅ ＥＣＵ１００ｂは、Ｓｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＯｆｆｅｒのメッセージをイーサネット１２に送信する。
（ステップＳ２０５）Ｚｏｎｅ ＥＣＵ１００ａは、Ｚｏｎｅ ＥＣＵ１００ｂから送信されたＳｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＯｆｆｅｒのメッセージを、イーサネット１２が接続された通信ポート１１３で受信する。
（ステップＳ２０６）Ｚｏｎｅ ＥＣＵ１００ａは、許可テーブル１１６を参照する。受信したＳｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＯｆｆｅｒのメッセージは、許可テーブル１１６に格納された許可ルールに合致するため、Ｚｏｎｅ ＥＣＵ１００ａは、通信ポート１１３で受信したＳｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＯｆｆｅｒのメッセージは不正でないと判断し、他の通信ポートへこのメッセージを転送する。
（ステップＳ２０７）Ｚｏｎｅ ＥＣＵ１００ｃは、転送されたＳｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＯｆｆｅｒのメッセージを受信する。
（ステップＳ２０８）Ｚｏｎｅ ＥＣＵ１００ａは、Ｚｏｎｅ ＥＣＵ１００ｂから受信したメッセージが示すサービスの提供を受けるため、Ｓｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＳｕｂｓｃｒｉｂｅのメッセージを、Ｚｏｎｅ ＥＣＵ１００ｂに送信する。
（ステップＳ２０９）Ｚｏｎｅ ＥＣＵ１００ｂは、ＥＣＵ１００ａから送信されたメッセージを受信したことを通知するため、Ｓｅｒｖｉｃｅ ＩＤが０ｘ２０００でありタイプがＳｕｂｓｃｒｉｂｅ ＡｃｋのメッセージをＺｏｎｅ ＥＣＵ１００ａに送信する。
［１．１０ Ｚｏｎｅ ＥＣＵの許可テーブル更新シーケンス］
図１１は、実施の形態１における、Ｚｏｎｅ ＥＣＵによる通常モードにおける許可テーブル１１６の更新シーケンスを示す図である。
（ステップＳ３０１）Ｚｏｎｅ ＥＣＵ１００ｃは、Ｓｅｒｖｉｃｅ ＩＤが０ｘ２０００であるメッセージに関する許可テーブル１１６の更新要求、例えば、Ｏｆｆｅｒのメッセージの送信の停止を示す更新要求をイーサネット１１に送信する。
（ステップＳ３０２）Ｚｏｎｅ ＥＣＵ１００ａは、更新要求をイーサネット１１が接続された通信ポート１１２で受信する。
（ステップＳ３０３）Ｚｏｎｅ ＥＣＵ１００ａは、更新要求が正当な要求であるかを確認するため、乱数シードを生成し、Ｚｏｎｅ ＥＣＵ１００ｃへ送信する。
（ステップＳ３０４）Ｚｏｎｅ ＥＣＵ１００ｃは、受信した乱数シードと、鍵保持部１０３に保持している鍵を用いて、所定の演算により、レスポンスを算出し、Ｚｏｎｅ ＥＣＵ１００ａに送信する。
（ステップＳ３０５）Ｚｏｎｅ ＥＣＵ１００ａは、レスポンスを検証し、正当な更新要求がされたとして、更新要求に従って、許可テーブル１１６の更新を行う。
（ステップＳ３０６）Ｚｏｎｅ ＥＣＵ１００ａは、他のネットワークのＺｏｎｅ ＥＣＵに対しても、Ｓｅｒｖｉｃｅ ＩＤが０ｘ２０００であるメッセージに関する許可テーブル１１６の更新を行うために、更新要求を、他の通信ポートへ送信する。
（ステップＳ３０７）Ｚｏｎｅ ＥＣＵ１００ｂは、受信した更新要求が正当であるかを確認するために、乱数シードをＺｏｎｅ ＥＣＵ１００ａに送信する。
（ステップＳ３０８）Ｚｏｎｅ ＥＣＵ１００ａは、受信した乱数シードと、鍵保持部１０３に格納されている鍵から、レスポンスを所定の演算に従って算出し、Ｚｏｎｅ ＥＣＵ１００ｂに送信する。
（ステップＳ３０９）Ｚｏｎｅ ＥＣＵ１００ｂは受信したレスポンスを検証し、正当な更新要求がされたとして、更新要求に従って、許可テーブル１１６の更新を行う。
［１．１１ Ｚｏｎｅ ＥＣＵの全体処理のフローチャート］
次にＺｏｎｅ ＥＣＵの全体処理について説明する。ここでは、Ｚｏｎｅ ＥＣＵを代表して、Ｚｏｎｅ ＥＣＵ１００ａの全体処理について説明する。
図１２は、実施の形態１における、Ｚｏｎｅ ＥＣＵ１００ａによる全体処理のフローチャートである。Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームに従った制御および通信処理を行うが、ここでは省略する。
（ステップＳ４０１）Ｚｏｎｅ ＥＣＵ１００ａは、フレームを受信しているかを判断する。フレームを受信していない場合（Ｎｏの場合）は、フレームを受信するまでステップＳ４０１を実行し、そうでない場合、すなわち、フレームを受信した場合（Ｙｅｓの場合）は、ステップＳ４０２を実施する。
（ステップＳ４０２）Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームがＳＯＭＥ／ＩＰ ＳＤの通信であるかを確認する。Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームがＳＯＭＥ／ＩＰ ＳＤメッセージでない場合（Ｎｏの場合）は、ステップＳ４０３を実行し、ＳＯＭＥ／ＩＰ ＳＤメッセージである場合（Ｙｅｓの場合）は、ステップＳ４０５を実行する。
（ステップＳ４０３）Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームが許可テーブル更新用フレームであるかを確認する。Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームが許可テーブル更新用フレームである場合（Ｙｅｓの場合）は、ステップＳ４０４を実行し、そうでない場合（Ｎｏの場合）はステップＳ４１０を実行する。
（ステップＳ４０４）Ｚｏｎｅ ＥＣＵ１００ａは、許可テーブル１１６の更新処理を行う。具体的には、Ｚｏｎｅ ＥＣＵ１００ａは、図１０のシーケンスで示したように、チャレンジレスポンス認証を行い、正当な更新要求であった場合に許可テーブル１１６を更新し、他のネットワークへも許可テーブル１１６の更新要求を行う。Ｚｏｎｅ ＥＣＵ１００ａは、正当な更新要求でない場合は、許可テーブル１１６の更新は行わない。
（ステップＳ４０５）Ｚｏｎｅ ＥＣＵ１００ａは、ＳＯＭＥ／ＩＰ ＳＤを含むフレームを受信したときに、自身が初期化モードであるかを確認する。Ｚｏｎｅ ＥＣＵ１００ａは、自身が初期化モードである場合（Ｙｅｓの場合）はステップＳ４０６を実行し、そうでない場合、つまり通常モードである場合（Ｎｏの場合）はステップＳ４０８を実行する。
（ステップＳ４０６）Ｚｏｎｅ ＥＣＵ１００ａは、自身が初期化モードであった場合は、受信したＳＯＭＥ／ＩＰ ＳＤメッセージに含まれる情報をもとに、許可テーブル１１６に許可ルールを登録し、ステップＳ４０７を実行する。
（ステップＳ４０７）Ｚｏｎｅ ＥＣＵ１００ａは、受信したＳＯＭＥ／ＩＰ ＳＤメッセージを、他の通信ポートへ転送する。
（ステップＳ４０８）Ｚｏｎｅ ＥＣＵ１００ａは、受信したＳＯＭＥ／ＩＰ ＳＤメッセージのＳｅｒｖｉｃｅ ＩＤと受信ポートとタイプ（ＯｆｆｅｒかＦｉｎｄか）が許可テーブル１１６に記載されている許可ルールと一致するかを確認する。Ｚｏｎｅ ＥＣＵ１００ａは、許可テーブル１１６に一致する場合（Ｙｅｓの場合）は、ステップＳ４０７を実行し、一致しない場合（Ｎｏの場合）は、ステップＳ４０９を実行する。
（ステップＳ４０９）Ｚｏｎｅ ＥＣＵ１００ａは、受信したＳＯＭＥ／ＩＰ ＳＤメッセージを破棄する。
（ステップＳ４１０）Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームがＳＯＭＥ／ＩＰメッセージであるかを確認する。受信したフレームがＳＯＭＥ／ＩＰメッセージである場合（Ｙｅｓの場合）は、ステップＳ４０８を実行する。この場合に、Ｚｏｎｅ ＥＣＵ１００ａは、ステップＳ４０８でＹｅｓの場合には、ステップＳ４０７でＳＯＭＥ／ＩＰメッセージを他の通信ポートへ転送し、ステップＳ４０８でＮｏの場合には、ステップＳ４０９でＳＯＭＥ／ＩＰメッセージを破棄する。Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームがＳＯＭＥ／ＩＰメッセージでない場合（Ｎｏの場合）はステップＳ４０７を実行する。この場合のステップＳ４０７では、Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームを、他の通信ポートへ転送する。
［１．１２ Ｚｏｎｅ ＥＣＵのモード変更に関わるフローチャート］
図１３は、実施の形態１における、Ｚｏｎｅ ＥＣＵ１００ａによるモード変更処理のフローチャートである。この処理は、図１２のＺｏｎｅ ＥＣＵ１００ａの全体処理と並列に実行される。
（ステップＳ５０１）Ｚｏｎｅ ＥＣＵ１００ａは、自身が初期化モードであるかを確認する。Ｚｏｎｅ ＥＣＵ１００ａは、自身が初期化モードである場合（Ｙｅｓの場合）は、ステップＳ４０６を実行し、そうでない場合（Ｎｏの場合）はモード変更処理を終了する。
（ステップＳ４０６）Ｚｏｎｅ ＥＣＵ１００ａは、受信したＳＯＭＥ／ＩＰ ＳＤメッセージをもとに、許可テーブル１１６に許可ルールを登録する。ステップＳ４０６での処理内容は図１２におけるものと同様のため説明を省略する。
（ステップＳ５０３）Ｚｏｎｅ ＥＣＵ１００ａは、イグニッションがＯＦＦであるかを確認する。Ｚｏｎｅ ＥＣＵ１００ａは、イグニッションがＯＦＦであれば（Ｙｅｓの場合）、ステップＳ５０４を実行し、そうでない場合（Ｎｏの場合）は、ステップＳ４０６を実行し、許可テーブル１１６の登録処理を継続する。
（ステップＳ５０４）Ｚｏｎｅ ＥＣＵ１００ａは、自身のモードを通常モードに更新する。
［１．１３ 実施の形態１の効果］
実施の形態１に係る車載ネットワークシステム１では、Ｚｏｎｅ ＥＣＵがＳＯＭＥ／ＩＰ ＳＤ通信に関して、サーバＥＣＵとクライアントＥＣＵの物理的な配置を接続ポートによって把握することによって（具体的には、車載ネットワークに接続されるＥＣＵの物理的な配置情報と、ＳＯＭＥ／ＩＰ ＳＤメッセージから各サービスについてサーバとクライアントとの対応付けを行って）、不正なＥＣＵによるサーバあるいはクライアントのなりすましメッセージの送信を検知する。すなわち、ＳＯＭＥ／ＩＰ等のサービス指向型通信を採用した車載ネットワークにおいて、攻撃者が不正なフレームを送信したとしても、サーバとクライアントとを物理的に接続するポートの関係から不正なフレームの送信を検知することを可能とする。これにより、車両の車載ネットワークのセキュリティが高まりうる。
さらに、Ｚｏｎｅ ＥＣＵは、不正と判断したフレームについて、他のネットワークへの転送を遮断する。これにより、正常なＥＣＵが不正なＥＣＵとセッションを確立することを防ぎ、車載ネットワークのセキュリティが高まる。
［その他変形例］
なお、本開示を上記各実施の形態に基づいて説明してきたが、本開示は、上記各実施の形態に限定されないのはもちろんである。以下のような場合も本開示に含まれる。
（１）上記の実施の形態では、本開示をＳＯＭＥ／ＩＰ通信に適用した例について説明したが、これに限定されることなく、その他のサービス指向型通信に適用してもよい。
（２）上記の実施の形態では、許可テーブル１１６の許可ルールのタイプとして、ＯｆｆｅｒとＦｉｎｄの例を示したが、別のタイプが用いられてもよい。例えば、Ｓｕｂｓｃｒｉｂｅでもよいし、Ｓｕｂｓｃｒｉｂｅ Ａｃｋでもよいし、通常のＳＯＭＥ／ＩＰで用いられるタイプを用いてもよい。
また許可テーブル１１６は、許可ルールにおけるタイプとして、サーバまたはクライアント等のサービスの役割を保持してもよい。
（３）上記の実施の形態では、Ｚｏｎｅ ＥＣＵは、許可テーブル更新用フレームによって、通常モード時に許可テーブル１１６を更新する例について説明したが、Ｚｏｎｅ ＥＣＵは、許可テーブル更新用フレームを用いずに許可テーブル１１６を更新してもよい。
例えば、Ｓｅｒｖｉｃｅ ＩＤが許可テーブル１１６に登録されていないＳＯＭＥ／ＩＰ ＳＤメッセージが観測された場合には、ＥＣＵのアップデート等により新しいサービスが追加されたとして、ＳＯＭＥ／ＩＰ通信のセッションが確立した段階で許可ルールを更新してもよい。
これにより、許可テーブル１１６の更新処理を行わずに、許可ルールが更新されるため、処理のオーバーヘッドが少なくなり効率的である。
図１４は、その他の変形例（３）における、Ｚｏｎｅ ＥＣＵ１００ａによる全体処理のフローチャートを示す。図１４は、図１２のステップＳ４０２にてＹｅｓの判定となった後の処理を表している。
（ステップＳ１４０５）Ｚｏｎｅ ＥＣＵ１００ａは、自身のモードが初期化モードであるかを判断する。Ｚｏｎｅ ＥＣＵ１００ａは、初期化モードである場合（Ｙｅｓの場合）は、ステップＳ４０６、そしてステップＳ４０７を実行し、そうでない場合（Ｎｏの場合）は、ステップＳ１４１０を実行する。
（ステップＳ１４１０）Ｚｏｎｅ ＥＣＵ１００ａは、受信したＳＯＭＥ／ＩＰ ＳＤメッセージに含まれるＳｅｒｖｉｃｅ ＩＤが許可テーブル１１６におけるいずれかの許可ルールとして登録されているかを確認する。Ｚｏｎｅ ＥＣＵ１００ａは、登録されている場合（Ｙｅｓの場合）はステップＳ４０８を実行し、以降の処理は図１２と同様のため説明を省略する。Ｚｏｎｅ ＥＣＵ１００ａは、登録されていない場合（Ｎｏの場合）はステップＳ１４１１を実行する。
（ステップＳ１４１１）Ｚｏｎｅ ＥＣＵ１００ａは、受信したＳＯＭＥ／ＩＰ ＳＤメッセージについて異なるポート間でセッションが確立するかを確認する。セッションが確立するとは、クライアントＥＣＵによるＳｕｂｓｃｒｉｂｅメッセージおよび、Ｓｕｂｓｃｒｉｂｅ Ａｃｋメッセージが観測されることであり、この場合、これらのメッセージに含まれるＳｅｒｖｉｃｅ ＩＤのサービスの提供が有効となっているということになる。Ｚｏｎｅ ＥＣＵ１００ａは、セッションが確立した場合（Ｙｅｓの場合）はＳ１４１２を実行し、そうでない場合（Ｎｏの場合）は、何もせずに終了する。
（ステップＳ１４１２）Ｚｏｎｅ ＥＣＵ１００ａは、当該Ｓｅｒｖｉｃｅ ＩＤに関する許可ルールを許可テーブル１１６に登録する。
（４）上記の実施の形態では、Ｚｏｎｅ ＥＣＵは、モードを保持し、モードが初期化モードの場合にＳＯＭＥ／ＩＰ ＳＤの許可ルールを登録していたが、モードを保持していなくてもよい。
例えば、各ＥＣＵは事前に、自身の利用するサービスに関するマニフェストファイル（マニフェスト情報）を保持しておき、マニフェストファイルをＺｏｎｅ ＥＣＵに通知し、Ｚｏｎｅ ＥＣＵがマニフェストファイルの正当性を検証することで、許可テーブル１１６を更新してもよい。例えば、ホスト部１０１は、ルール更新部の一例であってもよく、ルール更新部は、複数の通信ポートのうちのいずれか通信ポートが、ＥＣＵの利用するサービスに関するマニフェスト情報を含むフレームを受信した場合、マニフェスト情報と、マニフェスト情報を含むフレームを受信した通信ポートを識別するポート情報とに基づいて、許可ルールを更新してもよい。
これによりモードの管理が不要になるとともに、より信頼できる情報をもとに許可テーブル１１６への許可ルールの登録が可能となりセキュリティ強度が高まり効果的である。
図１５は、その他の変形例（４）における、マニフェストファイルの一例を示す図である。
マニフェストファイルには、各ＥＣＵが利用するＳｅｒｖｉｃｅ ＩＤと役割、および利用開始条件が記載されている。役割は、サービスの提供側のサーバであるか、サービスの受領側のクライアントであるかを示し、利用開始条件は、ＳＯＭＥ／ＩＰ ＳＤ通信が発生する車両状態の条件が記載されている。
図１５の例では、このマニフェストファイルを保持するＥＣＵは、Ｓｅｒｖｉｃｅ ＩＤが０ｘ１０５０のサービスのサーバであり、利用開始条件は停車中であることが示されている。さらに、当該ＥＣＵはＳｅｒｖｉｃｅ ＩＤが０ｘ２０５０のサービスのクライアントでもあり、利用開始条件は、車両状態によらずに常に利用開始しうることを示している。
（５）上記の実施の形態では、許可ルールに記載される車両状態を、不正なフレームの検知に利用していなかったが、不正なフレームの検知に利用してもよい。
図１６は、その他の変形例（４）および変形例（５）を組み合わせたときのＺｏｎｅ ＥＣＵ１００ａによる全体処理のフローチャートである。
（ステップＳ６０１）Ｚｏｎｅ ＥＣＵ１００ａは、フレームを受信しているかを確認する。Ｚｏｎｅ ＥＣＵ１００ａは、フレームを受信した場合（Ｙｅｓの場合）は、ステップＳ６０２を実行し、そうでない場合（Ｎｏの場合）は、フレームを受信するまでステップＳ６０１を実行する。
（ステップＳ６０２）Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームがＳＯＭＥ／ＩＰ ＳＤメッセージであるかを確認する。Ｚｏｎｅ ＥＣＵ１００ａは、ＳＯＭＥ／ＩＰ ＳＤメッセージでない場合（Ｎｏの場合）は、ステップＳ６０３を実行し、そうである場合（Ｙｅｓの場合）は、ステップＳ６０６を実行する。
（ステップＳ６０３）Ｚｏｎｅ ＥＣＵ１００ａは、マニフェストファイルを含むフレームを受信しているかを確認する。Ｚｏｎｅ ＥＣＵ１００ａは、マニフェストファイルを含むフレームを受信している場合（Ｙｅｓの場合）は、ステップＳ６０４を実行し、そうでない場合（Ｎｏの場合）は、ステップＳ６０７を実行する。
（ステップＳ６０４）Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームに含まれるマニフェストファイルが正当なものであるかを確認する。マニフェストファイルの正当性の検証は、マニフェストファイルに含まれるメッセージ認証コードの検証、または電子署名の検証により確認しうる。Ｚｏｎｅ ＥＣＵ１００ａは、マニフェストファイルが正当なものである場合（Ｙｅｓの場合）は、ステップＳ６０５を実行し、そうでない場合（Ｎｏの場合）は、処理を終了する。
（ステップＳ６０５）Ｚｏｎｅ ＥＣＵ１００ａは、マニフェストファイルに従って、許可テーブル１１６の許可ルールを更新する。Ｚｏｎｅ ＥＣＵ１００ａは、通信ポートに関しては、マニフェストファイルを含むフレームを受信したポートの情報を書き込む。
（ステップＳ６０６）Ｚｏｎｅ ＥＣＵ１００ａは、受信したＳＯＭＥ／ＩＰ ＳＤメッセージのＳｅｒｖｉｃｅ ＩＤ、受信ポート、タイプ、および現在の車両状態が、許可テーブル１１６に格納されている許可ルールと一致するかを確認する。Ｚｏｎｅ ＥＣＵ１００ａは、許可ルールと一致する場合（Ｙｅｓの場合）は、ステップＳ６０９を実行し、そうでない場合（Ｎｏの場合）は、ステップＳ６１０を実行する。
（ステップＳ６０７）Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームが、車両速度情報を含むフレームであるかを確認する。Ｚｏｎｅ ＥＣＵ１００ａは、車両速度情報を含むフレームである場合（Ｙｅｓの場合）は、ステップＳ６０８を実行し、そうでない場合（Ｎｏの場合）は、ステップＳ６０９を実行する。
（ステップＳ６０８）Ｚｏｎｅ ＥＣＵ１００ａは、フレームに含まれる車両速度情報に基づいて車両状態を更新する。具体的には、Ｚｏｎｅ ＥＣＵ１００ａは、車両速度が時速０キロであれば、車両状態を停止状態に更新し、それ以外であれば、走行状態に更新して、ステップＳ６０９を実行する。
（ステップＳ６０９）Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームを、適切なネットワークへ転送し、処理を終了する。
（ステップＳ６１０）Ｚｏｎｅ ＥＣＵ１００ａは、受信したフレームが、不正なフレームであったとして、受信したフレームを破棄して、処理を終了する。
（６）上記の実施の形態では、マニフェストファイルは平文で保持される例について説明したが暗号化されて保持されてもよい。また、マニフェストファイルには、正当性を証明するための、証明書またはメッセージ認証コードが含まれていてもよい。
（７）上記の実施の形態では、ゾーンネットワークにＣＡＮまたはイーサネットが利用される例について説明したが、ＣＡＮ－ＦＤまたはＦｌｅｘＲａｙ（登録商標）が利用されてもよい。
（８）上記の実施の形態では、イーサネット通信は平文で行われる例について説明したが、ＩＰｓｅｃ、ＭＡＣｓｅｃまたはＴＬＳ等の暗号化通信が行われてもよい。
（９）上記の実施の形態では、全てのネットワークが接続されている例について説明したが、Ｖｉｒｔｕａｌ ＬＡＮ（ＶＬＡＮ）によって論理的に分離されてもよい。これにより、セキュリティ強度が高まり効果的である。
（１０）上記の実施の形態では、初期化モードにおいて、許可テーブル１１６が登録される際に、車両状態の登録はされていなかったが、現在の車両状態に基づいて、車両状態が登録されてもよい。これにより、ＳＯＭＥ／ＩＰ通信のサービスの利用タイミングを限定することができ、不正なタイミングにおけるサービスの提供を検知することが可能となり効果的である。
（１１）上記の実施の形態では、最初のイグニッションＯＮ時のみに初期化モードになるが、初期化モードになる条件が別途設定されてもよい。例えば、ファームウェアの更新後または、診断コマンドによる初期化モードへの遷移等の条件が設定されてもよい。これにより車載ネットワークにおいて、サービスの提供関係が変化するタイミングで、新しい許可ルールを登録できるようにすることで利便性が高まり効果的である。
（１２）上記の実施の形態では、不正なフレームが検知された際に（具体的には、フレームに含まれる情報が許可ルールに合致しないという判断の結果が出力された際に）、他の通信ポートへ転送しない対応がとられる例について説明したが、別の対応がなされてもよい。例えば、不正なフレームの通信内容または不正なフレームの発生について各ＥＣＵのホスト部１０１へ通知されてもよいし、他のネットワークへ通知されてもよいし、車外のクラウドサーバへ通知されてもよい。これにより、不正なフレームによる、車両の制御を防ぐだけでなく、不正の発生状況の把握も可能となり、不正の発生原因の対処に有益である。また、不正なフレームを受信したポートが利用されないようにしてもよい。
（１３）上記の実施の形態では、Ｚｏｎｅ ＥＣＵの構成にスイッチが存在する例について説明したが、スイッチがＺｏｎｅ ＥＣＵと独立して存在し、不正なフレームのフィルタを行ってもよい。例えば、Ｚｏｎｅ ＥＣＵと不正フレーム検知装置が独立して存在していてもよい。
（１４）上記の実施の形態では、車両状態を、停止状態と走行状態の２通りとしている例について説明したが、車両状態はこれらに限らない。例えば、「高速走行中」「充電中」「自動運転モード」「ファームウェアアップデート中」等の車両状態について判断されてもよい。これにより、サービスが提供される時の車両状態をより厳密にすることで、セキュリティレベルを高められ効果的である。
（１５）上記の実施の形態では、初回のイグニッションＯＮ時からイグニッションＯＦＦまでに観測されたＳＯＭＥ／ＩＰ ＳＤメッセージをもとに許可テーブル１１６が登録されたが、初回のイグニッションＯＮ時からイグニッションＯＦＦの後も、所定の回数、初期化モードが繰り返されてもよい。これにより、初回のイグニッションＯＮからイグニッションＯＦＦまでに利用されなかったサービスについても、２回目以降の初期化モードにおいて観測される可能性があり、より正確な許可ルールの作成が可能となり効果的である。
（１６）上記の実施の形態では、Ｚｏｎｅ ＥＣＵは、受動的にＳＯＭＥ／ＩＰ ＳＤメッセージを観測していたが、自らＦｉｎｄメッセージを送信して、有効なサービスを探索してもよい。これにより、初期化モード時に、有効なサービスを許可テーブル１１６に登録することが可能となり効果的である。
（１７）上記の実施の形態では、全てのＳＯＭＥ／ＩＰ ＳＤメッセージに対して、許可ルールに合致するかを判断する例について説明したが、一部のサービスＩＤを含むＳＯＭＥ／ＩＰ ＳＤメッセージに対して実施されてもよい。例えば、自動運転に関わるサービスのみを対象としてもよい。具体的には、車両状態判定部（例えばホスト部１０１）は、車両の状態が自動運転モードであるか否かを判定し、不正フレーム検知部（例えばホスト部１０１または通信制御部１１１）は、サービスの識別子が、自動運転に関わるサービスである場合に限り、サービスの識別子と、サービスのタイプと、ポート情報と、車両の状態とが、許可ルールに合致するか否かを判断してもよく、許可ルールには、車両の状態が自動運転モードであるというルールが含まれていてもよい。これにより、安全に関わるサービスのみを監視することになり、メモリの消費量の削減に効果的である。
（１８）上記の実施の形態では、許可ルールに合致する通信のみを通信許可する例について説明したが、禁止ルールを保持し、禁止ルールに合致する通信を不正として検知してもよい。
（１９）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ハードディスクユニット、ディスプレイユニット、キーボードおよびマウスなどから構成されるコンピュータシステムである。ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
（２０）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭおよびＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部またはすべてを含むように１チップ化されてもよい。
また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩまたはウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
（２１）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭおよびＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
（２２）本開示は、不正フレーム検知装置として実現できるだけでなく、不正フレーム検知装置を構成する各構成要素が行うステップ（処理）を含む不正フレーム検知方法として実現できる。
不正フレーム検知方法は、複数のＥＣＵと、複数のネットワークと、によって構成される車載ネットワークシステムにおける、不正フレーム検知装置による不正フレーム検知方法であって、複数のＥＣＵは、サービス指向型通信により、不正フレーム検知装置を介して通信を行い、不正フレーム検知装置は、複数のネットワークのそれぞれに対応する複数の通信ポートを備え、複数の通信ポートのそれぞれは、複数のネットワークのうちの対応する所定のネットワークに接続され、所定のネットワークを介して所定のネットワークに接続されたＥＣＵとフレームの送受信を行うインタフェースを有し、不正フレーム検知方法は、図１２に示されるように、複数の通信ポートのうちのいずれかの通信ポートがフレームを受信した場合（ステップＳ４０１でＹｅｓ）、複数の通信ポートのうちのフレームを受信した通信ポート以外の通信ポートから、フレームが送信されるように転送制御を行う転送制御ステップ（ステップＳ４０７）と、当該フレームに含まれる、サービスの識別子と、当該フレームを送信したＥＣＵがサービスの提供側かサービスの受領側かを示すサービスのタイプと、当該フレームを受信した通信ポートを識別するためのポート情報とが、予め定められた許可ルールに合致するか否かを判断し、判断の結果を出力する不正フレーム検知ステップ（ステップＳ４０８）と、を含む。
また、不正フレーム検知方法におけるステップは、コンピュータ（コンピュータシステム）によって実行されてもよい。そして、本開示は、不正フレーム検知方法に含まれるステップをコンピュータに実行させるためのコンピュータプログラム、あるいは、コンピュータプログラムからなるデジタル信号として実現できる。
また、本開示は、そのコンピュータプログラムまたはデジタル信号を記録した非一時的なコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標） Ｄｉｓｃ）または半導体メモリなどとして実現できる。
また、本開示は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
また、本開示は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記録しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。
また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号をネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
（２３）上記実施の形態および上記変形例をそれぞれ組み合わせるとしてもよい。
本開示は、サービス指向型通信を用いる車載ネットワークシステムに利用することができる。
１ 車載ネットワークシステム
１０、１７ ＣＡＮ
１１、１２、１３、１４、１５、１６ イーサネット
１００ａ、１００ｂ、１００ｃ、１００ｄ Ｚｏｎｅ ＥＣＵ
１０１ ホスト部
１０２ 通信部
１０３ 鍵保持部
１０４ モード保持部
１１０ スイッチ
１１１ 通信制御部
１１２、１１３、１１４、１１５ 通信ポート
１１６ 許可テーブル
２００ａ ブレーキＥＣＵ
２００ｂ ステアリングＥＣＵ
２００ｃ カメラＥＣＵ
２００ｄ ヘッドユニットＥＣＵ
２００ｅ レーダーＥＣＵ
２００ｆ アンテナＥＣＵ
２０１ 通信部
２０２ ホスト部

Claims (8)

  1. 複数の電子制御ユニットと、複数のネットワークと、によって構成される車載ネットワークシステムにおける、不正フレーム検知装置であって、
    前記複数の電子制御ユニットは、サービス指向型通信により、前記不正フレーム検知装置を介して通信を行い、
    前記不正フレーム検知装置は、前記複数のネットワークのそれぞれに対応する複数の通信ポートと、通信制御部と、不正フレーム検知部と、を備え、
    前記複数の通信ポートのそれぞれは、前記複数のネットワークのうちの対応する所定のネットワークに接続され、前記所定のネットワークを介して前記所定のネットワークに接続された電子制御ユニットとフレームの送受信を行うインタフェースを有し、
    前記通信制御部は、前記複数の通信ポートのうちのいずれかの通信ポートがフレームを受信した場合、前記複数の通信ポートのうちの前記フレームを受信した通信ポート以外の通信ポートから、前記フレームが送信されるように転送制御を行い、
    前記不正フレーム検知部は、前記フレームに含まれる、サービスの識別子と、前記フレームを送信した電子制御ユニットがサービスの提供側かサービスの受領側かを示すサービスのタイプと、前記フレームを受信した通信ポートを識別するためのポート情報とが、予め定められた許可ルールに合致するか否かを判断し、前記判断の結果を出力する、
    不正フレーム検知装置。
  2. 前記通信制御部は、前記複数の通信ポートのうちのいずれかの通信ポートがフレームを受信した場合に、前記フレームに含まれる、前記サービスの識別子と、前記サービスのタイプと、前記ポート情報とが、前記許可ルールに合致しないときには、前記フレームについて前記転送制御を行わない、
    請求項１に記載の不正フレーム検知装置。
  3. 前記不正フレーム検知装置は、さらにルール更新部を備え、
    前記ルール更新部は、前記複数の通信ポートのうちのいずれか通信ポートが、電子制御ユニットの利用するサービスに関するマニフェスト情報を含むフレームを受信した場合、前記マニフェスト情報と、前記マニフェスト情報を含む前記フレームを受信した通信ポートを識別するポート情報とに基づいて、前記許可ルールを更新する、
    請求項１または２に記載の不正フレーム検知装置。
  4. 前記不正フレーム検知装置は、さらにルール生成部を備え、
    前記ルール生成部は、前記車載ネットワークシステムの初回起動時に、前記複数の通信ポートが受信したフレームに含まれる、前記サービスの識別子と、前記サービスのタイプと、前記ポート情報とに基づいて、前記許可ルールを生成する、
    請求項１～３のいずれか一項に記載の不正フレーム検知装置。
  5. 前記不正フレーム検知装置は、さらに、前記複数のネットワークに流れるフレームに基づいて、前記車載ネットワークシステムを搭載する車両の状態を判定する車両状態判定部を備え、
    前記不正フレーム検知部は、前記サービスの識別子と、前記サービスのタイプと、前記ポート情報と、さらに前記車両の状態とが、前記許可ルールに合致するか否かを判断する、
    請求項１～４のいずれか一項に記載の不正フレーム検知装置。
  6. 前記車両状態判定部は、前記車両の状態が自動運転モードであるか否かを判定し、
    前記不正フレーム検知部は、前記サービスの識別子が、自動運転に関わるサービスである場合に限り、前記サービスの識別子と、前記サービスのタイプと、前記ポート情報と、前記車両の状態とが、前記許可ルールに合致するか否かを判断し、
    前記許可ルールには、前記車両の状態が自動運転モードであるというルールが含まれる、
    請求項５に記載の不正フレーム検知装置。
  7. 前記サービス指向型通信はＳｃａｌａｂｌｅ Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ ＭｉｄｄｌｅｗａｒＥ ｏｖｅｒ ＩＰ（ＳＯＭＥ／ＩＰ）であり、
    前記サービスのタイプは、Ｏｆｆｅｒ、Ｆｉｎｄ、ＳｕｂｓｃｒｉｂｅおよびＳｕｂｓｃｒｉｂｅ Ａｃｋのいずれか１つを含む、
    請求項１～６のいずれか一項に記載の不正フレーム検知装置。
  8. 複数の電子制御ユニットと、複数のネットワークと、によって構成される車載ネットワークシステムにおける、不正フレーム検知装置による不正フレーム検知方法であって、
    前記複数の電子制御ユニットは、サービス指向型通信により、前記不正フレーム検知装置を介して通信を行い、
    前記不正フレーム検知装置は、前記複数のネットワークのそれぞれに対応する複数の通信ポートを備え、
    前記複数の通信ポートのそれぞれは、前記複数のネットワークのうちの対応する所定のネットワークに接続され、前記所定のネットワークを介して前記所定のネットワークに接続された電子制御ユニットとフレームの送受信を行うインタフェースを有し、
    前記不正フレーム検知方法は、
    前記複数の通信ポートのうちのいずれかの通信ポートがフレームを受信した場合、前記複数の通信ポートのうちの前記フレームを受信した通信ポート以外の通信ポートから、前記フレームが送信されるように転送制御を行う転送制御ステップと、
    前記フレームに含まれる、サービスの識別子と、前記フレームを送信した電子制御ユニットがサービスの提供側かサービスの受領側かを示すサービスのタイプと、前記フレームを受信した通信ポートを識別するためのポート情報とが、予め定められた許可ルールに合致するか否かを判断し、前記判断の結果を出力する不正フレーム検知ステップと、を含む
    不正フレーム検知方法。
JP2021529985A 2019-07-04 2020-06-24 不正フレーム検知装置および不正フレーム検知方法 Active JP7496823B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JPPCT/JP2019/026718 2019-07-04
PCT/JP2019/026718 WO2021002010A1 (ja) 2019-07-04 2019-07-04 不正フレーム検知装置および不正フレーム検知方法
PCT/JP2020/024855 WO2021002264A1 (ja) 2019-07-04 2020-06-24 不正フレーム検知装置および不正フレーム検知方法

Publications (2)

Publication Number Publication Date
JPWO2021002264A1 JPWO2021002264A1 (ja) 2021-01-07
JP7496823B2 true JP7496823B2 (ja) 2024-06-07

Family

ID=74100260

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021529985A Active JP7496823B2 (ja) 2019-07-04 2020-06-24 不正フレーム検知装置および不正フレーム検知方法

Country Status (5)

Country Link
US (1) US11930021B2 (ja)
EP (1) EP3996395B1 (ja)
JP (1) JP7496823B2 (ja)
CN (1) CN112889259B (ja)
WO (2) WO2021002010A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102019210226A1 (de) * 2019-07-10 2021-01-14 Robert Bosch Gmbh Vorrichtung und Verfahren für Angriffserkennung in einem Kommunikationsnetzwerk
WO2022153442A1 (ja) * 2021-01-14 2022-07-21 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ サービス仲介装置およびサービス仲介方法
JP2022144358A (ja) * 2021-03-19 2022-10-03 株式会社オートネットワーク技術研究所 車載装置、車載通信システムおよびデータ送信方法
CN113992344B (zh) * 2021-09-10 2022-11-22 深圳开源互联网安全技术有限公司 基于some/ip协议的通信数据异常检测方法、系统及可读存储介质
US20230185940A1 (en) * 2021-12-13 2023-06-15 Docusign, Inc. Batch processing of audit records
US11814010B1 (en) 2022-08-29 2023-11-14 Geotab Inc. Devices for shared vehicle access
US11970135B2 (en) 2022-08-29 2024-04-30 Geotab Inc. Methods for shared vehicle access

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140136589A1 (en) 2012-11-13 2014-05-15 Gogo Llc Communication System and method for Nodes Associated with a Vehicle
WO2015159520A1 (ja) 2014-04-17 2015-10-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 車載ネットワークシステム、不正検知電子制御ユニット及び不正検知方法

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111181732A (zh) * 2014-05-08 2020-05-19 松下电器（美国）知识产权公司 车载网络系统、电子控制单元及不正常检测方法
JP2016100842A (ja) * 2014-11-25 2016-05-30 富士通株式会社 通信制御装置、通信制御方法、および、通信制御プログラム
JP6595885B2 (ja) * 2015-01-20 2019-10-23 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 不正対処方法及び電子制御ユニット
JP6594732B2 (ja) * 2015-01-20 2019-10-23 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 不正フレーム対処方法、不正検知電子制御ユニット及び車載ネットワークシステム
US9866542B2 (en) * 2015-01-28 2018-01-09 Gm Global Technology Operations Responding to electronic in-vehicle intrusions
US9762509B2 (en) * 2015-04-20 2017-09-12 Ge Aviation Systems Llc Apparatus and method of operating a network traffic policing module
US9912754B2 (en) * 2015-05-01 2018-03-06 GM Global Technology Operations LLC Vehicular data isolation device
US10334445B2 (en) * 2015-10-14 2019-06-25 Cisco Technology, Inc. Accurate detection of rogue wireless access points
US10476893B2 (en) * 2015-10-30 2019-11-12 Citrix Systems, Inc. Feature engineering for web-based anomaly detection
US10356127B2 (en) * 2016-06-06 2019-07-16 NeuVector, Inc. Methods and systems for applying security policies in a virtualization environment
IT201600109368A1 (it) * 2016-10-28 2018-04-28 Magneti Marelli Spa "Dispositivo di protezione da attacchi informatici al veicolo tramite connettore diagnostico e corrispondente procedimento"
JP6547154B2 (ja) * 2016-11-30 2019-07-24 本田技研工業株式会社 通信システム
EP3373553B1 (en) * 2017-03-09 2024-05-08 Argus Cyber Security Ltd System and method for providing cyber security to an in-vehicle network
JP7020990B2 (ja) * 2017-07-19 2022-02-16 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 車載中継装置、中継方法及びプログラム
JP7033499B2 (ja) * 2017-07-26 2022-03-10 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常検知装置および異常検知方法
US20200389469A1 (en) * 2017-12-24 2020-12-10 Arilou Information Security Technologies Ltd. System and method for tunnel-based malware detection
US20190281052A1 (en) * 2018-03-08 2019-09-12 Auton, Inc. Systems and methods for securing an automotive controller network
WO2019237068A1 (en) * 2018-06-08 2019-12-12 Nvidia Corporation Protecting vehicle buses from cyber-attacks

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140136589A1 (en) 2012-11-13 2014-05-15 Gogo Llc Communication System and method for Nodes Associated with a Vehicle
WO2015159520A1 (ja) 2014-04-17 2015-10-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 車載ネットワークシステム、不正検知電子制御ユニット及び不正検知方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
鳥崎 唯之 ほか，CAN-Ethernet 混在車載ネットワークにおけるセキュリティ対策の検討と提案，2018年 暗号と情報セキュリティシンポジウム概要集，一般社団法人電子情報通信学会，2018年01月23日，pp.1-8

Also Published As

Publication number Publication date
JPWO2021002264A1 (ja) 2021-01-07
CN112889259A (zh) 2021-06-01
CN112889259B (zh) 2023-08-22
US20210314336A1 (en) 2021-10-07
US11930021B2 (en) 2024-03-12
EP3996395A1 (en) 2022-05-11
WO2021002264A1 (ja) 2021-01-07
EP3996395A4 (en) 2022-05-11
WO2021002010A1 (ja) 2021-01-07
EP3996395B1 (en) 2024-02-14

Similar Documents

Publication Publication Date Title
JP7496823B2 (ja) 不正フレーム検知装置および不正フレーム検知方法
CN106576096B (zh) 用于对具有不等能力的设备的认证的装置、方法及介质
JP7037550B2 (ja) ネットワークトラフィックのセキュア通信
US9350608B2 (en) Method and system for using virtual tunnel end-point registration and virtual network identifiers to manage virtual extensible local area network access
US7996894B1 (en) MAC address modification of otherwise locally bridged client devices to provide security
US8266286B2 (en) Dynamic key management server discovery
US9009302B2 (en) Dynamic group creation and traffic flow registration under a group in a group key infrastructure
WO2013122177A1 (ja) 車載ネットワークシステム
WO2021002013A1 (ja) 異常検知装置および異常検知方法
JP6674007B1 (ja) 車載通信装置、通信制御方法および通信制御プログラム
JP2019009596A (ja) 車載通信装置、通信制御方法および通信制御プログラム
JPWO2019021995A1 (ja) 通信装置、通信方法及び通信システム
US20200045057A1 (en) Motor vehicle having a data network which is divided into multiple separate domains and method for operating the data network
JP2023162313A (ja) 端末のネットワーク接続を認証及び制御するためのシステム及びそれに関する方法
EP3448001B1 (en) Communication security apparatus, control method, and storage medium storing a program
JP7045247B2 (ja) 通信保護装置、制御方法、および、プログラム
KR102638986B1 (ko) 이더넷 스위치 및 그 제어 방법
WO2022153708A1 (ja) サービス仲介装置、サービス仲介方法、および、プログラム
Burgardt In-Vehicle Network Security: Attacks and Countermeasures
CN113271283B (zh) 消息接入方法及系统
KR102545160B1 (ko) 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2022219551A1 (en) Computer-implemented methods and systems for establishing and/or controlling network connectivity

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230404

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240521

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240528

R150 Certificate of patent or registration of utility model

Ref document number: 7496823

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150