JP5919205B2 - ネットワーク装置およびデータ送受信システム - Google Patents

Description

本発明は、ネットワーク装置およびデータ送受信システムに関する

通信異常を検出して通信の中継を制御する技術として、特開２００８−２３６４０８公報には、エラーフレームを送信しているＥＣＵが存在し通信異常となっているバスを検出すると共に、該バスに接続されたメッセージフレームの送信周期が異常であるＥＣＵを特定する情報処理装置を提供するため、多重通信用のバスを介して接続された複数のＥＣＵを中継接続ユニットを介して接続し、この中継接続ユニットでＥＣＵの通信を中継し、中継接続ユニットは通信異常の検出手段として、バスを介してＥＣＵから受信するメッセージフレームｍの数を、各メッセージフレームに付されたＩＤ（識別子）毎にカウントするカウンタと、カウンタでのカウント数を予め設定した単位時間あたりの基準値と比較してメッセージフレームが通信異常であると判定するカウンタ値チェック手段とを備える中継装置が記載されている。

また、特表２００７−５２８６２１号公報に記載された中継装置は、不正アクセスを検出して通信経路を切断するとともに、他の通信経路を確保するため、受信したパケットの通信ヘッダをアクセスパターンＤＢに基づいて検証して、不正アクセスを検出したか否かを判定し、不正アクセスを検出したと判定した場合、パケットの送信元の車載通信装置を識別し、車載通信装置のコネクションを切断するための制御信号を送信する。また、制御信号を送信するとともに、経路制御テーブルを更新して他の車載通信装置を経由する通信経路を確保する。

特開２００８−２３６４０８号公報 特開２００４−１９３９０３号公報

ネットワークを介し、不正機器が不正なデータを送信して機器の異常動作を引き起こす不正攻撃（後述するなりすまし攻撃など）が問題になっている。

このような不正攻撃による通信異常に、特許文献１の技術を適用した場合、メッセージフレームの送出周期を受信周期基準値の下限値と比較し、異常を判定するなどして、周期情報を正常値と比較することになる。また特許文献２の技術によれば、受信したデータのヘッダ情報に基づいて不正アクセスを検出することになる。

しかし、特許文献１ではなりすまし攻撃についての対処方法については考慮されておらず、特許文献２の方法では、なりすまし攻撃はヘッダが偽装されているため、なりすまし攻撃を検知することができない。

本発明は上記状況に鑑みて為されたものであり、なりすまし攻撃について検知および防御することを目的とする。

上記課題を解決するために、なりすまし攻撃発生時には、同一の識別子を持つデータのデータ送出周期が設計周期より短周期となることから、ネットワーク装置においてデータの受信周期を判定し、設計周期より短い周期でデータを受信した場合に、不正な攻撃が発生していることを検知し、攻撃に対する防御動作（フェールセーフ、不正転送防止、データの破棄、状態の記録、ユーザーまたは他システムへの警告通知、等）を行う。

本発明によれば、ネットワーク上で不正な攻撃（例えば後述するなりすまし攻撃）が発生した場合に防御動作を行い不正に対処することが可能となる。

また不正検知時の誤検知低減、データ確認時の負荷低減、についても可能になる。

データ受信時の制御部における周期判定処理を表すフローチャートである。 ネットワークシステムの例である。 ネットワークシステムの構成図である。 ネットワーク装置の構成図である。 ネットワーク装置のソフトウェアモジュール構成の例である。 ネットワーク上の通信プロトコルにおけるデータ構造の例である。 ネットワーク上のデータ送信およびなりすまし攻撃の例である。 フィルタテーブルの例である。 短周期検出時の制御部におけるフローチャートである 周期異常通知処理におけるメッセージ情報表示画面の例である。 第２の実施例におけるデータ受信時の制御部におけるフローチャートである。 第３の実施例におけるフィルタテーブルの例である。 受信時刻テーブルの例である。 第２の実施例における短周期検出時処理のフローチャートである。 第２の実施例におけるフィルタテーブルの例である。 異常関連情報ログの例である。

以下、本発明に好適な実施形態の例（実施例）として、車載ネットワークなどの周期的なデータ送受信を行うネットワークにおける装置およびシステムを例に発明の詳細を説明する。本発明は、車載ネットワーク装置および車載ネットワークにおけるデータ送受信システムに好適であるが、ネットワーク装置およびデータ送受信システム以外への適用を妨げるものではない。

＜ネットワークシステムの構成＞
図２に、本発明を用いたネットワーク装置を有するネットワークシステムを備えた制御システムの概要を示す。

自動車の内部に設けられた制御システム１は、車載ネットワーク（ＣＡＮ、ＦｌｅｘＲａｙ（登録商標）、Ｅｔｈｅｒｎｅｔ（登録商標）、等）により構成されるネットワークシステム２と、制御システム１の外部と無線通信（例えば携帯電話の通信、無線ＬＡＮ、ＷＡＮ、等のプロトコルを使用した通信）を行う無線通信部３、ネットワークシステム２とは異なるプロトコル、あるいは同一のプロトコルを用いたネットワークシステム４、ＯＢＤ（On Board Diagnosis）端子などの診断用端子やＥｔｈｅｒｎｅｔ端子、外部記録媒体（例えばＵＳＢメモリ、ＳＤカード、等）端子などの外部接続端子を備え、この外部接続端子を介した有線接続によりネットワークシステム２へのアクセスを行う有線通信部５、ネットワークシステム２に有線または無線で接続され、ネットワークシステム２から送出されるデータを受信し、受信したデータに基づくメッセージ情報（例えば映像、音）などの情報を表示または出力するための液晶ディスプレイや警告灯あるいはスピーカなどの出力装置６を備えている。

ネットワークシステム２は、ネットワークシステム４、無線通信部３、有線通信部５、出力装置６、などの装置と接続され、それぞれの装置との間で情報の送受信を行う。

図３は、ネットワークシステム２の内部構成を示している。このネットワークシステム上のネットワーク装置はネットワークバス３０１に接続されており、ネットワークバス３０１は例えばＣＡＮバスなどである。ネットワークバス３０１には、図示していないハードウェアに接続され、各ハードウェアの制御およびネットワークバスとのデータ送受信を行うＥＣＵ（Electronic Control Unit：電子制御ユニット）３０２、およびネットワークバス間を接続してそれぞれのネットワークバスとデータの送受信を行うゲートウェイ（以下ＧＷ）３０３が接続されている。

ＧＷ３０３はＧＷ機能を有するＥＣＵであってもよく、またＥＣＵ３０２はＥＣＵの機能を有するＧＷであってもよく、ＧＷ３０３とＥＣＵ３０２はそれぞれが両方の機能を有する場合がある。

また、ＧＷ３０３やＥＣＵ３０２など、ネットワークバスで接続される装置のことをネットワーク装置と総称する。ネットワーク装置は、自身に接続されるハードウェアを制御している場合がある。例えば、ＥＣＵ３０２には図示されていないアクチュエータが接続され、ＥＣＵ３０２はこのアクチュエータを操作することで制御対象を制御する。また出力装置６はネットワークバスに接続され、ネットワーク装置は後述するようにネットワークバスを介して出力装置６を制御する。

ＧＷ３０３は複数のネットワークバスに接続されており、それぞれのネットワークバスにはＩＤが付与され、ＧＷ３０３の内部処理時には、どのネットワークバスに対する処理であるのかをこのＩＤにより識別する。この識別を行うＩＤをバスＩＤと呼ぶ。バスＩＤは「Ｃｈａｎｎｅｌ ＩＤ」とも呼ぶ。

また図３の例では、ネットワークシステム２のトポロジとして、ＣＡＮで用いられるバス型の接続を示しているが、本発明はスター型、メッシュ型、リング型などの異なるトポロジにおいても同様に適用可能である。

図４は、本発明にかかるネットワーク装置であるＧＷ３０３の内部構成を示した図である。ＧＷ３０３は、キャッシュやレジスタなどの記憶素子を持ち制御を実行するＣＰＵなどのプロセッサ４０１、複数のネットワークバス３０１に対してデータの送受信を行う通信Ｉ／Ｆ４０２、図示しないクロックなどを使用して時間および時刻の管理を行うタイマ４０３、プログラムおよび不揮発性のデータを保存するＲＯＭ（Read Only Memory）４０４、揮発性のデータを保存するＲＡＭ（Random Access Memory）４０５、ネットワーク装置内部での通信に用いられる内部バス４０６、を備えている。

ＥＣＵ３０２の内部構成も、ＧＷ３０３の内部構成と同様であるが、ＥＣＵ３０２がＧＷの機能を備えていない場合、各ネットワークバス間でデータの転送処理を行わない点が異なる。

次に、ネットワーク装置で動作するソフトウェアモジュールの構成を図５に示す。ネットワーク装置では、後述するフィルタテーブル５０４や、後述する受信時刻テーブル５０５がＲＡＭ４０５に格納されている。また、通信Ｉ／Ｆ４０２の動作および状態を管理して内部バス４０６を介し通信Ｉ／Ｆ４０２に指示を行う通信管理部５０２、タイマ４０３を管理して時間に関する情報取得や制御を行う時間管理部５０３、通信Ｉ／Ｆ４０２から取得したデータの解析やソフトウェアモジュール全体の制御を行う制御部５０１などの各モジュールがプロセッサ４０１によって実行される。また、後述する異常関連情報を記録しておく異常関連情報ログ５０６を有している。異常関連情報ログ５０６はＲＡＭ４０５に記録される。

この図５の構成についてはプロセッサ４０１上の動作概念を示したものであり、動作時に必要な情報はＲＯＭ４０４およびＲＡＭ４０５から適宜取得して動作を行う。
＜ネットワークプロトコルの例＞
図６に、ネットワークバス３０２で用いられる通信プロトコルによるデータ構造の例を示す。この図６ではＣＡＮの通信プロトコルにおけるフレームのデータ構造を示している。この図に示した数値は、フレームを構成する各フィールドのビット数を表している。

ＣＡＮでは同一バス上に接続されたネットワーク装置が、送信時にバス信号をドミナント（０）に設定し、送信時または受信時にバス信号のドミナント（０）またはリセッシブ（１）を検知することにより通信を行う。

ＳＯＦ（Start Of Frame）はフレームの開始位置を示しており、フレームの同期を取るためにも用いられている。

識別子（ＩＤ）は、フレームで送信するデータのＩＤ（以下、データＩＤ）を示しており、データＩＤによりフレームで送信しているデータの種類を識別可能である。

識別子（ＩＤ）とＲＴＲ（Remote Transmission Request）ビットからなる部分をアービトレーション・フィールドと呼び、このアービトレーション・フィールドの値によりバスのアービトレーション（調停）を行っている。

コントロール・フィールドのＲＢ１、ＲＢ０は予約ビットであり、図６（ａ）のフォーマットの例ではどちらもドミナントが設定される。また、データ長コードは、データ・フィールドのデータ長（バイト数）を表している。しかし、ＲＢ０の値にリセッシブが設定された場合には、アービトレーション・フィールドが図６（ｂ）に示すような拡張フォーマットであることを表し、この拡張フォーマットでは識別子（ＩＤ）を２９ビットで表現可能となる。拡張フォーマットのコントロール・フィールドに続くデータ・フィールド以降の構成は図６（ａ）と同様である。

データ・フィールドは、送信するデータの内容を示しており、Ｎバイト分のデータが可変長で送信される。

ＣＲＣ・フィールドには、フレームのＣＲＣが入力され、ＣＲＣ境界はアクノリッジとの境界のために、常にリセッシブで送信される。

受信ノード（本実施例における、ＥＣＵ３０２やＧＷ３０３）では、正しくデータを受信した場合に、応答のためにこのアクノリッジのビットをドミナントに設定することで送信データの応答を返す。

ＥＯＦ（End Of Frame）はフレームの終端を示し、７ビットのリセッシブとなっている。

ＣＡＮバスでは、以上のようなフォーマットでネットワーク装置同士がデータの送受信を行っている。

車載ネットワークでは、特定のネットワーク装置が定期的にネットワークに対して自ネットワーク装置が観測した値（例えばセンサの値）を発信して、別のネットワーク装置に状態（観測したセンサの値）を通知する処理などを行っている。

ＣＡＮではデータの送信時にアービトレーション・フィールドで調停を行っており、複数のネットワーク装置が同時に送信を開始した場合、優先度の低いネットワーク装置は送信を中断する。ＣＡＮの規格では、ＩＤが大きい、つまり調停期間により少なくドミナントを送信したデータ・フレームほど優先度が低いと定義されている。そのため、各ネットワーク装置が周期的にデータを送信したい場合でも、データの送出タイミングに送信可能であるにもかかわらず、アービトレーション・フィールドによる調停の結果、送信処理に中断が発生したり、または送信開始タイミングに他ネットワーク装置が既にデータを送信している場合にはデータを送信することが出来ず、送出周期がずれる可能性がある。このような、データの送出タイミングが重複する、またはデータを送信したい時に、バスを使用されている、などの状態を衝突と呼ぶ。

ここではＣＡＮを例に説明しているが、例えばＦｌｅｘｒａｙ（登録商標）などのプロトコルにおいても周期的なデータの送受信を行っている。またＥｔｈｅｒｎｅｔなどの例においても異なるフォーマットでデータの送受信を行っており、周期的に情報を送るなどの処理を行っており、本発明について同様に適用可能である。
＜通信Ｉ／Ｆにおけるデータ送受信処理＞
通信Ｉ／Ｆ４０２のデータ受信処理として、例えば設計時に定められた自ネットワーク装置で受信が必要なデータＩＤをプロセッサ４０１がフィルタテーブル５０４から読み出し、通信Ｉ／Ｆ４０２に指定する。受信が必要なデータＩＤの指定を受けた通信Ｉ／Ｆ４０２は、自ネットワーク装置が接続されているネットワークバス３０１で送信される信号を監視し、指定されたデータＩＤを有するデータ・フレームが、ネットワークバス３０１上で送信された場合に、このデータＩＤを持つデータ・フレームを受信して、データを受信したことをこのデータ・フレームのデータと共にプロセッサ４０１に通知する、といったデータ受信処理を行う。

一方、通信Ｉ／Ｆ４０２におけるデータ送信処理としては、プロセッサ４０１からデータの送信処理指示と送信するデータを受信した場合に、必要な情報を付加した上で、ネットワークプロトコルに合わせたデータ形式でネットワークバス３０１に対してデータを送信する。
＜出力装置におけるメッセージ情報の出力方法＞
出力装置６にメッセージ情報を出力する方法を説明する。出力装置６は、ＧＷ３０３やＥＣＵ３０２と専用線またはネットワークバス３０１などの通信路で接続されており、このような通信路から、例えば前述したネットワークプロトコルで定められたフォーマットのデータとして、データＩＤが０ｘ３００のデータは警告画面表示要求、データＩＤが０ｘ３０１のデータは、警告画面で表示する後述する周期異常ログ情報、のように定めておき、ＧＷ３０３やＥＣＵ３０２から臆されてくるデータ・フレームを受信し、そのデータに対応した図形や文字情報などの映像情報を作成して、出力装置６が有するディスプレイに表示する。

または、例えばデータＩＤが０ｘ３０２のデータは警告灯点灯要求であり、そのデータのペイロードに格納されている値が警告灯の点灯パターンを指定するものと定めておき、このようなデータを受信した際に警告灯を点灯するようにしてもよい。

あるいはまた、例えばデータＩＤが０ｘ３０３のデータは警告音声出力要求であり、そのデータのペイロードの値で警告音声のパターンを指定すると定めておき、このようなデータを受信した場合には、出力装置６が内部に保持する音声パターンの音声のなかから指定された音声をスピーカに出力するようにしてもよい。

このような出力制御により、検出された制御システムの状態（特に異常発生）についてのメッセージ情報を出力することで、ユーザーに対して制御システムの状態を通知する。
＜なりすまし攻撃の例＞
次に図７を用いて、本発明で主に防御の対象とする、なりすまし攻撃の例について説明する。

図７（ａ）は、正常時のデータ送信動作の例を示しており、横軸に示す時間の経過にともなうデータ・フレーム７０１の送信期間を表しており、図６で示したフォーマットによるデータ・フレーム７０１が、一定周期（Ｔ）ごとに、あるネットワーク装置から送信されている状態を表している。ここでは簡略化のために、ある特定のデータＩＤを持つデータ・フレームのみが送信されている状態を表している。ここで時間Ｔ２では、図に記載していない別のデータＩＤを持つデータ・フレームとの衝突により送出時刻に遅れが生じている様子を示している。

図７（ｂ）は、なりすまし攻撃が行われている場合のデータ送信の状態を示している。なりすまし攻撃により送信されたデータ・フレーム７０３は、正規のデータ・フレーム７０２と同一のデータＩＤを持っているが、本来のデータ・フレーム７０２送出タイミングとは異なるタイミングで、データ・フレーム７０２と同じ周期でデータを送信している。そのためこのデータＩＤのデータを受信するネットワーク装置はどちらのデータが正しいかを判定することができず、誤った動作を行う可能性がある。

このようななりすまし攻撃により、特定のデータＩＤを持つデータ・フレームのネットワークバス上での発生周期は、本来の送信周期Ｔより短くなり、受信側のネットワーク装置では、例えば図７（ｂ）の時間Ｘ、または時間Ｔ−Ｘ毎にデータを受信することになる。

本発明の第１の実施形態について以下に示す。ここでは図３におけるＧＷ３０３に本発明を適用した例を示す。

ＧＷ３０３が有するフィルタテーブル５０４のデータ構造について、図８を用いて説明する。フィルタテーブル５０４には、受信するデータ・フレームのデータＩＤ８０２と、各データＩＤごとのデータ送出周期８０３（以下、所定周期）が格納されている。また、ＧＷ３０３のように複数のネットワークバスに接続されている場合は、それぞれのデータＩＤを持つデータ・フレームを送出するネットワーク装置が接続されているネットワークバスのバスＩＤであるデータ発生バスＩＤ８０４を持つ場合もある。本発明では、これら情報を基になりすまし攻撃の有無の判定を行う。フィルタテーブル５０４に登録されているこれらの情報は、全てシステム設計時に決定され、システムの起動以前に登録されているものとする。

ＧＷ３０３では、通信Ｉ／Ｆ４０２においてネットワークバス３０１からデータ・フレームを受信した場合、通信管理部５０２がその受信を検知する。そして通信管理部５０２は、データ・フレームの受信を検知したタイミングで、そのデータの受信時刻を時間管理部５０３から取得し、制御部５０１に対して、受信したデータの内容およびデータの受信時刻を通知する。

通信管理部５０２からこの通知を受信した制御部５０１は、受信したデータの周期判定処理を行う。図１にこの周期判定処理のフローチャートを示す。周期判定処理ではまず、受信データのデータＩＤが、フィルタテーブル５０４に存在しているかを判定する（Ｓ１０１）、受信データのデータＩＤがフィルタテーブル５０４に存在していない場合（Ｓ１０１：Ｎｏ）、本来は送信されてくることのないデータＩＤを持ったデータ・フレームが送信されていることになるため、ＩＤ異常検出時処理を行う（Ｓ１０２）。

ＩＤ異常検出時処理Ｓ１０２を行う状態では、想定していないデータＩＤを持つデータがネットワークバス上に送信されていることから、不正攻撃が発生している可能性が高いと判断し、このＩＤ異常検出時処理としては、ＩＤに関する異常が発生したとみなして後述する異常検出時処理を行う。

Ｓ１０１における受信データのデータＩＤがフィルタテーブル５０４に存在しているか否かの判定において、フィルタテーブル５０４にデータ発生バスＩＤが記載されている場合は、データを受信したネットワークバスのＩＤと、フィルタテーブル５０４のデータ発生バスが一致しているか否かについても確認する。これにより、データＩＤの一致だけでなくデータ発生バスの一致についても確認可能なため、本来送出されてくるネットワークバス以外からのデータ送信を把握することができるため、より周期異常を検知しやすくなる。

ステップＳ１０１の処理において、受信データのデータＩＤがフィルタテーブル５０４に存在している場合（Ｓ１０１：Ｙｅｓ）は、次にステップＳ１０３の処理を行う。

ステップＳ１０３の処理で、制御部５０１は、通信管理部５０２からの通知に含まれる受信時刻と、後述する終了時処理において制御部５０１が受信時刻テーブル５０５に記憶しておいた同一データＩＤの前回受信時刻を比較して、受信データのデータＩＤが示すデータ・フレームの受信周期を計算し、計算した結果の受信周期を、フィルタテーブル５０４の周期と比較する周期判定を行う。この周期判定の結果が異常と判定された場合（Ｓ１０３：Ｎｏ）、短周期検出時処理を行う（Ｓ１０４）。短周期検出時処理については後述する。

この周期判定で異常と判定される場合とは、前回受信時刻に基づき計算した受信周期が、フィルタテーブル５０４に格納されている該当データＩＤの周期より小さい場合を指す。ここで比較の際には、フィルタテーブル５０４の周期と直接比較する以外に、誤差に対するマージンを計算し、判定を行ってもよい。具体的にはフィルタテーブルに格納されている周期が１０ｍｓであった場合に１０％のマージンを取り、受信周期が９ｍｓより小さい場合に短周期と判定する。これにより、衝突などにより周期が乱れた場合でも、短周期と誤判定する可能性が少なくなる。

計算した結果の周期をフィルタテーブル５０４と比較して異常でないと判定した場合（Ｓ１０３：Ｙｅｓ）は、終了時処理（Ｓ１０５）を実行する。ここでの終了時処理Ｓ１０５として、データＩＤを受信した受信時刻を、図１３に示すような受信時刻テーブル５０５に記憶し、データＩＤが示すデータの前回受信時刻として使用する。受信時刻テーブル５０５には、データＩＤ（１３０１）毎に、データ・フレームの受信時刻を記録する構成となっており、終了時処理において、データＩＤに対応する前回受信時刻（１３０２）の欄に受信時刻を記録してゆく。

このようにして制御部５０１ではデータ・フレームが予め決められていた周期よりも短周期で送信されている状態の検出を行う。
＜短周期検出時処理＞
次に、周期判定でデータ・フレーム送信周期の短周期を検出した時に制御部５０１で実行される短周期検出時処理について、図９に示すフローチャートを元に説明する。この短周期検出時処理では、同一データＩＤを持つデータ・フレームを予め決められていた周期よりも短周期で受信したと判定された際の処理であり、更に次の同一データＩＤのデータ・フレームを、一定時間内に受信するか否かを判定する。

そこで制御部５０１は、短周期を検出したデータＩＤを持つデータ・フレームのデータ受信を待つ。このため、通信管理部５０２から通知されるデータ・フレームのデータＩＤを監視し、短周期を検出したデータＩＤのデータ・フレームの受信が通知された場合（Ｓ９０１：Ｙｅｓ）、後述する周期異常検出時処理を実行する（Ｓ９０２）。短周期を検出したデータＩＤのデータを受信していない場合（Ｓ９０１：Ｎｏ）には、受信が通知されてきたデータ・フレームについて図１の処理を並行して行うと共に、ステップＳ９０３の処理で待機時間を経過していないかの確認を行う。

待機時間とは、短周期（想定している周期よりも短い周期でのデータ受信）を検出した場合に、基準とする前回受信時刻に対し想定している正常な周期でのデータ受信時刻までの時間を表し、図７（ｂ）の周期Ｔ−時間Ｘの時間に相当する。具体的には下記のような計算式（式１）で求めることが可能となる。

待機時間＝フィルタテーブルの周期−（データ受信時刻−前回受信時刻） …（式１）
この待機時間についても周期判定の場合と同様、マージンを含む計算を行っても良い。例えば計算した結果の待機時間が２ｍｓ（例えば、１０ｍｓ間隔での受信を想定している場合に、前回の受信から８ｍｓ後に同一データＩＤのデータを受信）の場合に、待機時間を計算で求めた２ｍｓでなく、衝突の発生などによる送信周期の乱れを考慮してフィルタテーブルに登録されている周期の時間の２０％を待機時間のマージンとし、このマージンに相当する２ｍｓを加算した４ｍｓを待機時間としても良い。これにより、短周期を検出した後に正常な周期で送信されてくるデータ・フレームを受信するまでの時間を調整することが可能となり、異常データ受信後に衝突等で正常な周期で正常データを受信できなかった場合に、不正が無いと誤判定することを防ぐことが可能となる。

制御部５０１は、現在の時間が待機時間を経過していない場合（Ｓ９０３：Ｎｏ）、には所定時間処理の待機を行い、再度ステップＳ９０１を実行する。また待機時間が到来した場合（Ｓ９０３：Ｙｅｓ）には、タイムアウト処理（Ｓ９０４）を行う。

タイムアウト処理Ｓ９０４では、タイムアウトが発生した場合（待機時間を経過した場合）には、短周期を検出したデータが実際はネットワークバス上の送出周期の乱れにより、周期が短くなっただけの正常なデータであり、なりすましのデータが受信されたものではない可能性が高いため、一旦は短周期と判定されたデータに対してこのデータを正常に受信したと判定された場合に実施する処理（例えばデータの転送処理）を実施する。

このようにしてデータの短周期が検出されたデータＩＤを持つデータ・フレームについて周期性を確認し、不正なデータ送信が無いかを確認する。

待機時間の別の計算例として、前回の誤差を記憶しておき、待機時間を補正する場合もある。例えば、フィルタテーブルの周期が１０ｍｓであり、前回のデータの受信間隔が１２ｍｓであったような場合、その次の周期でのデータ受信間隔は、送信のタイミングが一定である場合には８ｍｓで到着するような場合がある。その場合に誤って短周期と判定されないように、前回受信誤差（上記の例で、１２ｍｓ−１０ｍｓ＝２ｍｓ）を用いて、式（式２）のように待機時間を計算する。

待機時間＝フィルタテーブルの周期−（データ受信時刻−前回受信時刻）−前回受信誤差 …（式２）
このように計算することにより、一時的な衝突などによる周期乱れにより、誤って短周期と判定されることを防ぐことが可能となる。

フィルタテーブル５０４に登録しておく周期については、先に説明したようにシステム設計時に決めた周期を予め登録しておく以外に、例えばシステム起動時などに一定期間（例えば１０秒程度）データを受信し、その周期をフィルタテーブル５０４に登録することも可能である。例えばプロセッサ４０１が、起動もしくは待機状態から回復してから一定時間、通信Ｉ／Ｆ４０２を介してデータ・フレームの受信周期を監視し、フィルタテーブル５０４に登録する。このようにすることにより、予めフィルタテーブル５０４に設計周期を登録することが不要となる。
＜周期異常検出時処理＞
周期異常検出時処理としては、周期が異常であったという情報を基に、後述する異常検出時処理を実施する。
＜異常検出時処理＞
異常検出時処理としては、受信するＩＤが異常であった場合や、周期の異常を検出した場合に制御部５０１によって実行される。

異常検出時処理の例としては、（１）受信したデータを処理せずに破棄、（２）異常が発生したことを検出した異常の種類（ＩＤ異常、周期異常）と異常発生回数（累積値）と共に異常ログ情報へ記録、（３）異常を通知するための異常通知処理の実施、などの処理を行う。
＜異常通知処理によるメッセージ情報出力＞
異常が発生していることを通知するために、例えば異常を検知したネットワーク装置が出力装置６に対して後述する異常関連情報を通信路を介して通知し、出力装置６がこの異常関連情報を、異常を検知した旨のメッセージ情報として表示する。メッセージ情報の出力処理については前述の通りである。

メッセージ情報表示の例を図１０に示す。図１０では、出力装置６が有するディスプレイ１０００に、メッセージ情報１００１が表示されている例を示している。メッセージ情報の内容としては、異常を検出したデータ・フレームのデータＩＤである「データＩＤ」（１００２）、そのデータＩＤに関連付けられている“車両速度”等の具体的なデータ種別を表す「データ種別」（１００３）、累積での異常発生回数を表す「発生回数」（１００４）、異常を検出した直近の時刻である「最新発生時刻」（１００５）、異常を検知したネットワークバスのバスＩＤである「発生バスＩＤ」（１００６）、等の情報が表示されている例を示している。これらのメッセージ情報が表す情報を異常関連情報と呼ぶ。そしてこれらの情報を提示することにより、ネットワークでの異常発生とその詳細な内容を、ユーザーに対し警告として通知することが可能になる。
＜異常通知処理によるフェールセーフ実施＞
他の周期異常検出時の異常検出時処理として、ネットワークシステム全体をフェールセーフな状態とするために、制御部５０１は、予め定められた特定の信号（警告信号）を、ネットワークバス３０１に送信する異常通知処理を行う。特定の信号を受信したＥＣＵ３０２またはＧＷ３０３などのネットワーク装置はネットワーク上で周期異常が発生していることを検知した場合、例えば自身が制御するハードウェアを予め定められた安全な状態に制御した後にシステムを停止し、その他の通信機器に対してフェールセーフ制御を実行した旨を通知する、等の処理を実行する。このようにすることで、周期異常が検知された場合にシステムを安全な状態で停止させることが可能になる。

周期異常を検知したネットワーク装置が警告信号を送信する対象としては、無線通信部３、有線通信部５、また複数のネットワークバスに接続されているネットワーク装置の場合、周期異常を検出したネットワークバス以外のネットワークバスや別のネットワークシステム、などに通知を行うことにより、システム全体をフェールセーフ状態とすることが可能となる。
＜異常ログ情報への記録＞
異常検出時処理では、異常を検知したネットワーク装置、または周期異常通知処理を受信したネットワーク装置が、ネットワーク装置内部の異常関連情報ログ５０６として異常関連情報を保存しておく。この異常関連情報ログ５０６のデータ構造を図１６に示す。ここでは前述の異常関連情報の内、異常が発生したと判定されたデータ・フレームのデータＩＤをデータＩＤ１６０１に、異常が発生した累積回数を発生回数１６０２に、そして異常と判定された時刻を最終発生時刻１６０３に、異常が発生したネットワークバスのバスＩＤを発生バスＩＤ１６０４に、それぞれ記録して、異常関連情報ログとしている。
＜受信データの破棄による、通信路飽和攻撃への対応＞
また周期異常発生時に、異常検出時処理として受信したデータを処理せずに破棄することにより、例えばＤｏＳ（Denial of Service）などの通信路飽和攻撃により、正常な識別子を持つデータを大量に送信された場合でも、所定周期以下の間隔で送信されたデータであれば破棄されるため、攻撃を防ぐことが可能となる。

次に、実施例２として、短周期検出時処理において受信したデータの内容を比較する類似性判定処理を加味した上で周期異常の有無を判断する例を説明する。

実施例２におけるネットワーク装置の構成は、実施例１の場合と同様であり、制御部５０１における短周期検出時処理が、図９の処理に代わり図１４に示すフローチャートの処理となる。

実施例２においては、図１４に示すに示すように短周期検出時処理Ｓ１０４において、判定対象とするデータＩＤを持つデータ・フレームの受信が通知された場合（Ｓ９０１：Ｙｅｓ）、周期異常を検出した際のデータ・フレームと、その後待機時間経過までに受信したデータ・フレームのデータの内容を比較する類似性判定処理を行う（Ｓ１４０１）。この判定結果が正常（Ｓ１４０１：Ｙｅｓ）となった場合は、周期異常検出時処理Ｓ９０２を行わず、正常なデータ・フレームが受信されているものとしてタイムアウト処理Ｓ９０４を実行する。

類似性判定処理の判定結果が正常であるとは、例えば２つのデータ・フレームにおけるデータ・フィールドの差分値が、予め定められた一定量（差分上限）または一定比率以下、または示している状態が同一（ＯＮ／ＯＦＦを表すステータスが、共にＯＮなど）、設計基準値（正常範囲）以内、等のデータ・フィールドが意味するデータ種別に基づいて定められた値の範囲内であることを意味する。この場合、両方のデータを通常通りに処理してもシステムの制御状態には大きな変化は生じず、異常動作は発生しないと考えられ、なりすまし攻撃ではなく衝突により周期が短縮したと判断して、受信したデータに対して正常時にデータを受信した際に実施する必要な処理を行う。

そして類似性判定処理の判定結果が異常となるのは、逆に、差分値が差分上限より大きい、状態（値）が不一致、いずれかの値が正常範囲外、等の場合となる。この場合（Ｓ１４０１：Ｎｏ）には、受信したデータを処理することによりシステムの制御状態が大きく変わる恐れがあり、異常動作が発生する可能性が高く、またなりすまし攻撃である可能性が高いと判断して、データを処理せずに破棄し、周期異常検出時処理Ｓ９０２を行う。

実施例２におけるフィルタテーブル５０４のデータ構造を図１５に示す。実施例２では、フィルタテーブル５０４に、類似性判定処理で使用するデータ・フィールドの差分値と比較する値が格納される。データ・フィールドの差分値と比較する値としては、設計基準値（正常範囲）１５０１、差分上限１５０２がある。これらの値は、データＩＤごとにシステム設計時に例えばデータ種別が“車両速度”のデータの場合、これに対応するデータＩＤ：０ｘ００１対し、正常範囲：０〜３００、差分上限：５、等のようにあらかじめ決定しておき、フィルタテーブル５０４に登録しておく。

このようにして周期異常を検知した後に、更に該当データＩＤを持つデータ・フレームのデータの内容を確認してから周期異常の発生を判定することにより、正常時の衝突発生による誤検知を防ぎつつ周期異常を検知することが可能となる。

また、周期異常検知後にのみデータの内容を確認する処理を行うことにより、通常時に常にデータの内容を確認する処理が不要となり、処理負荷の削減も可能となる。

次に、ＧＷ３０３がデータ転送を行う場合の周期異常検出時処理と、これに伴う不正転送防止処理について説明する。実施例１と異なる点は、制御部５０１で実行する処理が、図１１に示すように周期異常検出時処理を行った後、転送処理Ｓ１１０２を行う点と、フィルタテーブル５０４が図１２に示すようにデータ転送先バスＩＤの情報を含む点である。以下、図１１のフローチャートを用いて制御部５０１における処理を説明する。

制御部５０１がデータ受信の通知を受けた際のＳ１０１〜Ｓ１０４の処理は、実施例１の場合と同様である。そして実施例１と同様に周期判定（Ｓ１０３）の処理を行い、計算した結果の周期をフィルタテーブル５０４と比較して異常ではないと判定した場合（Ｓ１０３：Ｙｅｓ）に、該当データＩＤが転送対象データか否かの判定を行う（Ｓ１１０１）。転送対象のデータであるか否かの判定は、図１２に示したフィルタテーブル５０４に基づき、受信データのデータＩＤに対応するデータ転送先バスＩＤ（１２０１）の値を調べ、転送先のネットワークバスのバスＩＤが記載されている場合、そのデータが転送対象であると判定する。例えば図１２に示したフィルタテーブル５０４の例では、データＩＤが０ｘ００１のデータ・フレームの場合には、データ転送先バスＩＤに‘Ｂ’が設定されているため、バスＩＤ‘Ｂ’を持つネットワークバスに対してデータ・フレームの転送処理を行う必要があることが解るため、このデータは転送対象データであると判定される。一方、データＩＤが０ｘ１０１のデータ・フレームの場合には、データ転送先バスＩＤに値の記載が無いため、データ・フレームの転送処理を行う必要がなく転送対象データではないと判定する。

以上の判定の結果、受信データが転送対象データでない場合（Ｓ１１０１：Ｎｏ）、データ・フレームの転送処理を行わずに終了時処理Ｓ１０５へ進む。また、受信データが転送対象データであると判定された場合（Ｓ１１０１：Ｙｅｓ）、転送処理Ｓ１１０２を行い終了時処理へ進む。ステップＳ１０３で受信周期が正常であると判定された場合にはこのように処理を行う。

一方、周期判定の処理の結果が異常と判定された場合（Ｓ１０３：Ｎｏ）には、短周期検出時処理を行う（Ｓ１０４）この場合の制御部５０１の処理については実施例１の場合と同様であるが、タイムアウト処理Ｓ９０４における処理が異なる。実施例１のタイムアウト処理Ｓ９０４においては、一旦は短周期と判定されたデータに対してこのデータを正常に受信したと判定された場合に実施する処理（例えばデータの転送処理）を実施するが、実施例３の場合には、一旦は短周期と判定された受信データがＳ１１０１と同様の判定処理により転送対象データであるか判定を行った後、転送対象データであると判定された場合に、データの転送を行う。

これにより、短周期を検出したデータについては即座に別のネットワークバスにデータ・フレームの転送を行わず、一時的にＧＷ３０３で保持し、その後、周期異常を検出した場合にはデータを破棄することにより、不正なデータ転送を防ぐことが可能になる。

また、Ｓ９０２の周期異常検出時処理において、実施例２と同様にデータ比較を行って類似性を判定した結果、データ・フィールドの差分が小さい場合に、同様に転送処理を行うなどの処理を行ってもよい。このようにすることにより、短周期検出時に、データの内容を比較してから、データ・フレームの転送の要否を判定することが可能になり、データ・フレームの不正転送防止および誤検出を防ぐことが可能になる。

これまでの実施例では任意のＥＣＵまたはＧＷで周期判定を行う例を説明していたが、実施例４では、実際にデータを受信する側となるＥＣＵ３０２で周期判定を行い、不正なデータ処理を防ぐ例について説明する。この実施例３によるＥＣＵ３０２の構成例は、実施例１にて説明した構成と同様であるが、制御部５０１の処理について、短周期検出時処理Ｓ１０４における、周期異常検出時処理Ｓ９０２とタイムアウト処理Ｓ９０４の内容が異なる。

即ち、タイムアウト処理９０４においては、短周期で受信したデータについて、待機時間が経過するまで後続する不正なデータを受信することが無かったため、なりすまし攻撃ではなく周期の乱れであると判定し、自ＥＣＵで受信したデータについて正常時に受信した場合の処理を実施することになる。

また周期異常検出時処理Ｓ９０２においては、短周期データ受信後に更に同一データＩＤのデータを受信しており、なりすまし攻撃が発生している可能性が高いため、受信したデータについて、受信したＥＣＵが正常時に受信した場合の処理を実施せず、そのまま受信データを破棄する。

このように制御を行うことにより、ＥＣＵ３０２がなりすましデータを受信したと判断した場合には、不正な処理を行うことを防ぐことが可能となる。

実施例５では、異常発生検知時に異常関連情報ログ５０６として記録した異常関連情報を用い、異常発生以降に、この記録しておいた異常関連情報を使用してユーザーに異常を通知する、また異常発生回数により異なる処理を実施する処理を行う。

実施例５では、制御部５０１が起動、終了、診断といった特定のタイミングにおいて周期異常ログ情報５０６に記録された異常関連情報を読み出し、前述した異常通知処理によるメッセージ情報出力と同様に通信路を介して出力装置６へ出力することにより、異常関連情報を、周期異常発生時以降においても確認することが可能となる。

また異常検出時処理において、異常発生回数が、一定値（例えば１０回程度）発生した場合にのみ、前述した異常通知処理によるメッセージ情報出力を行うことにより、周期判定および類似性判定処理において誤判定が行われた場合でも、即座に警告が発生してユーザーに誤解を与えることを防ぐことができる。

上記の実施例１から実施例５において、不正検知の対象とする識別子（ＩＤ）については、ネットワーク上の全データの識別子を対象とするだけでなく、特定の識別子のデータに絞って不正検知の対象としてもよい。具体的には、前述した通信Ｉ／Ｆ４０２におけるデータ受信処理で、特定のデータＩＤのみを受信対象とするように処理を行う。不正検知処理の対象を限定することにより、プロセッサ４０１における処理負荷を低減し、また通信Ｉ／Ｆ４０２におけるデータ受信領域：メールボックスなどの不正検知に使用するリソースを節約することも可能になる。

また、フィルタテーブル５０４に、更にデータの重要度として例えばデータが関連する機能のＡＳＩＬ（Automotive Safety Integrity Level）を登録しておき、例えばＡＳＩＬ Ａ以上といった重要度の高いデータのみを不正検知の対象としても良い。

更に、不正検知の対象を特定の識別子のデータに絞る場合、不正検知の対象を周期的に変更してもよい。具体的には、前述した通信Ｉ／Ｆ４０２におけるデータ受信処理において、受信対象とする特定のデータＩＤを順々に切り替える処理を行う。例えばリソースの制約により不正検知対象の識別子が１０種類に制約され、ネットワーク上の識別子の種類が３０の場合、一定のタイミングで不正検知対象の識別子を登録したテーブルを切り替えることで、１０種類ずつ３つのパターンで処理対象とする識別子を変更することにより、リソースを節約した上で不正を検知することが可能となる。また、パターンの切替えを上記データの重要度に応じて、重要度の高いデータを長時間不正検知の対象となるようなスケジューリングすることにより、リソースを節約した上で、より重要度の高いデータに対する不正を検知しやすくなる。

以上説明した実施例によれば、不正攻撃などにより、送信されるデータの短周期が発生した場合に検知を行い、異常発生の通知やデータの破棄、システムのフェールセーフの実行を行うことが可能となる。また短周期の計算方法として、周期のマージンについて、固定値や前回受信誤差を用いることにより誤検知の発生を防ぐことが可能になる。

また周期異常発生時に、それぞれのデータの内容を比較して不正か否かを判定することにより、周期異常による誤検知を防ぐことが可能になり、また周期異常発生時のみデータの内容を比較することにより、データ比較の処理負荷を低減することが可能になる。

また、周期異常検出時に、出力装置または外部のシステム等に対して異常が発生したことおよび各種の異常関連情報を含むメッセージ情報を通知することにより、ユーザー等に対して不正が発生したことおよびその詳細な情報を通知することが可能になる。また情報を保存しておくことにより、過去に不正が発生した際の情報についても確認可能となる。

またＧＷにおけるデータ転送時などにおいては、不正攻撃などによる周期異常のデータについて、データを転送することを防ぐことが可能になる。またＥＣＵにおけるデータ処理時について、不正なデータを受信して処理を行うことを防ぐことが可能になる。

１ 制御システム
２ ネットワークシステム
３ 無線通信部
４ ネットワークシステム
５ 有線通信部
６ 出力装置
３０１ ネットワークバス
３０２ ＥＣＵ
３０３ ゲートウェイ（ＧＷ）
４０１ プロセッサ
４０２ 通信Ｉ／Ｆ
４０３ タイマ
４０４ ＲＯＭ
４０５ ＲＡＭ
４０６ 内部バス
５０１ 制御部
５０２ 通信管理部
５０３ 時間管理部
５０４ フィルタテーブル
５０５ 受信時刻テーブル
５０６ 異常関連情報ログ
１０００ ディスプレイ
１００１ メッセージ情報

Claims (8)

1. データを受信する通信部と、データを受信した受信時間を管理する時間管理部と、受信したデータを処理する制御部とを有し、周期的にデータを受信して処理するネットワーク装置において、
   前記制御部は、前記通信部で受信したデータが有する識別子毎に前記時間管理部における受信時刻を記録し、前記受信時刻に基づいて決まる基準とするデータと同じ識別子を持つデータを受信した間隔が所定周期より短い第１のデータを受信した場合に、前記基準とするデータを受信した時刻から前記所定周期経過するまでに前記第１のデータと同じ識別子を持つ第２のデータを受信した時には、周期異常検出時処理を行い、前記所定周期経過するまでに前記第１のデータと同じ識別子を持つデータを受信しなかった時には、前記第１のデータについて所定の処理を行うことを特徴とするネットワーク装置。
2. 請求項１に記載のネットワーク装置において、
   前記制御部は、前記データを受信する間隔が所定周期より短い第１のデータを受信した
   場合に、前記所定周期までに前記第１のデータと同一識別子を持つ第２のデータを受信し
   たときには、更に第１のデータと第２のデータについて類似性判定処理を実施し、前記類
   似性判定処理の結果が非類似である場合に、周期異常検出時処理を実行し、類似と判定さ
   れた場合には、前記第１のデータと第２のデータについて前記所定の処理を行う
   ことを特徴とするネットワーク装置。
3. 請求項１または２記載のネットワーク装置において、
   前記制御部は、前記周期異常検出時処理として、前記第１のデータと第２のデータを破
   棄することを特徴とするネットワーク装置。
4. 請求項３に記載のネットワーク装置において、
   前記制御部は、前記周期異常検出時処理にて、周期異常を検出した識別子、周期異常発
   生回数、周期異常の発生時刻、周期異常を検知したバスＩＤ、のいずれか一つ以上の情報
   を異常関連情報として記憶する処理を行う、ことを特徴とするネットワーク装置。
5. 請求項４のネットワーク装置において、
   警告情報を出力するユーザー警告部を有し、
   前記制御部は、前記周期異常検出時処理の際に、警告指示として前記異常関連情報を前
   記ユーザー警告部に送信し、
   前記ユーザー警告部は受信した警告指示に基づく警告を行う
   ことを特徴としたネットワーク装置。
6. 請求項１に記載のネットワーク装置において、
   前記制御部は、前記データを受信する間隔が所定周期より短い第１のデータを受信した
   場合に、前記所定周期までに前記第１のデータと同一識別子を持つ第２のデータを受信し
   た時には、前記第１のデータおよび第２のデータの転送処理を行わずに破棄し、
   前記所定周期までに前記第１のデータと同一識別子を持つ第２のデータを受信しない時
   には、前記第１のデータを所定のネットワークに転送する転送処理を行う
   ことを特徴とするネットワーク装置。
7. ネットワークに警告指示を送信する第１のネットワーク装置と前記ネットワークに送信
   された警告指示を受信する第２のネットワーク装置により構成されるデータ送受信システ
   ムであって、
   前記第１のネットワーク装置において、データを受信し、警告指示を送信する通信部と
   、前記第１のネットワーク装置において、前記データを受信した受信時間を管理する時間
   管理部と、
   前記第１のネットワーク装置において、前記データを処理する制御部と、
   前記第２のネットワーク装置において、前記警告指示を受信する通信部と、
   前記第２のネットワーク装置において、前記通信部を管理し、警告指示を処理する制御
   部と、を有し、
   前記第１のネットワーク装置における制御部は、前記データを受信する間隔が所定周期
   より短い第１のデータを受信した場合に、前記所定周期までに前記第１のデータと同一識
   別子を持つ第２のデータを受信した時に、前記第１のネットワーク装置は、前記第２のネ
   ットワーク装置に対して警告指示を送信し、前記第２のネットワーク装置における制御部
   は、前記警告指示を処理する
   ことを特徴とするデータ送受信システム。
8. 請求項７に記載のデータ送受信システムにおいて、前記警告指示の処理ではフェールセ
   ーフ処理を実施する、ことを特徴とするデータ送受信システム。