JP6126980B2 - ネットワーク装置およびネットワークシステム - Google Patents

Description

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

本技術分野の背景技術として、非特許文献１がある。この文献には、「ＣＡＮはバスネットワークを前提としており、やり取りされるメッセージには送信元や宛先ノードの情報が含まれず、同一バス内の全てのノードにブロードキャストされる。また、メッセージ認証や送信元認証機能がないため，容易になりすましが可能である。」ことを課題とし、解決手段として「ＣＡＮの特徴であるブロードキャスト通信を利用し、不正メッセージがバス上に送信されていることを、なりすましの対象となったノード自身が検知し、エラーメッセージを送ることで、偽装メッセージの送信が完了する前にこれを破棄する」と記載されている。

Ｔ. Ｍａｔｓｕｍｏｔｏ, Ｍ. Ｈａｔａ, Ｍ. Ｔａｎａｂｅ, Ｋ. Ｙｏｓｈｉｏｋａ, Ｋ. Ｏｉｓｈｉ，"Ａ Ｍｅｔｈｏｄ ｏｆ Ｐｒｅｖｅｎｔｉｎｇ Ｕｎａｕｔｈｏｒｉｚｅｄ Ｄａｔａ Ｔｒａｎｓｍｉｓｓｉｏｎ ｉｎ Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ"， Ｖｅｈｉｃｕｌａｒ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏｎｆｅｒｅｎｃｅ （ＶＴＣ Ｓｐｒｉｎｇ）， ２０１２ ＩＥＥＥ ７５ｔｈ （２０１２）

非特許文献１には、送信ネットワーク装置のセキュリティ対策について記載が無い。送信ネットワーク装置が攻撃を受け動作不能になった場合には、他のネットワーク装置ではその攻撃を検出できないため、防御が困難になる。ネットワーク装置を攻撃から防御する際には、セキュリティモジュールの採用や脆弱性の実装を防ぐ検証方法など高度なセキュリティ対策が必要になり、それぞれの送信ネットワーク装置で対策コストが必要になる。

（１）請求項１に記載のネットワーク装置は、複数のネットワーク装置とバスで接続されたネットワーク装置であって、バスを介して複数のネットワーク装置のうちの１つが送信元装置として送信するデータに含まれるメッセージ認証用情報に基づいて、認証を行う認証部と、認証が失敗した場合は、送信元装置が複数のネットワーク装置のうちの他のネットワーク装置になりすまして不正データを送信したと判断し、データを無効化する加工部とを備えることを特徴とする。
（２）請求項９に記載のネットワークシステムは、請求項１に記載のネットワーク装置と、送信元装置とを備えることを特徴とする。

本発明によれば、ネットワーク上でなりすまし攻撃が発生した場合に、その攻撃を検出する確実性を高め、効率的にその攻撃に対する防御動作を行うことが可能となる。

本発明の各実施形態におけるネットワーク装置を有するネットワークシステムの一例を示す図である。 ネットワークシステム内部構成の一例を示す図である。 ネットワーク装置の構成例を示す図である。 ネットワーク装置のソフトウェアモジュール構成の一例を示す図である。 ネットワーク上の通信プロトコルにおけるデータ構造の一例を示す図である。 ネットワーク上の通信プロトコルにおけるデータ長符号化の一例を示す図である。 ネットワーク上の通信プロトコルにおけるデータ構造の一例を示す図である。 ネットワーク上の通信プロトコルにおけるデータ構造の一例を示す図である。 ネットワーク上の通信プロトコルにおけるデータ構造の一例を示す図である。 ネットワーク上の通信プロトコルにおけるデータ構造の一例を示す図である。 フィルタテーブルの一例を示す図である。 認証手順の一例を示す図である。 署名付き通信データフォーマットの一例を示す図である。 鍵管理テーブルの一例を示す図である。 データ検出時の制御部における処理を表すフローチャートである。 第２実施形態におけるデータ検出時の制御部における処理を表すフローチャートである。 第４実施形態におけるデータ検出時の制御部における処理を表すフローチャートである。

以下、本発明に好適な実施形態を説明する。主には移動体、例えば車両に搭載される車載ネットワークなどのデータ送受信を行うネットワークにおける装置およびシステムの動作について説明している。本発明は、車載ネットワーク装置および車載ネットワークにおけるデータ送受信システムに好適であるが、車載ネットワーク装置および車載ネットワークにおけるデータ送受信システム以外のネットワーク装置およびネットワークシステムへの適用も可能である。

−−−第１実施形態−−−
＜ネットワークシステムの構成＞
図１は本発明の第１の実施の形態におけるネットワーク装置を有するネットワークシステムの一例を示す図である。図１は、自動車などの移動体の内部にネットワークシステムを有する制御システム１、例えば車載ネットワーク（ＣＡＮ：Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ、ＣＡＮＦＤ：ＣＡＮ ｗｉｔｈ Ｆｌｅｘｉｂｌｅ Ｄａｔａ−ｒａｔｅ、Ｅｔｈｅｒｎｅｔ（登録商標）、等）により構成されるネットワークシステム２を示している。図２は、制御システム１の外部と無線通信（例えば携帯電話の通信、無線ＬＡＮ、ＷＡＮ、等のプロトコルを使用した通信）を行う無線通信部３、ネットワークシステム２と異なる、または同一のプロトコルを用いたネットワークシステム４を示している。図２は、例えば、診断端子（ＯＢＤ）やＥｔｈｅｒｎｅｔ端子、外部記録媒体（例えばＵＳＢメモリ、ＳＤカード、等）端子などを有し、かつ有線接続によってネットワークシステム２にアクセスを行う有線通信部５を示している。図２は、ネットワークシステム２に有線または無線で接続され、ネットワークシステム２から送出されるデータを受信し、メッセージ情報（例えば映像、音）など必要な情報を表示または出力する、液晶ディスプレイ、警告灯、スピーカなどの出力装置６、を示している。ネットワークシステム２は、ネットワークシステム４、無線通信部３、有線通信部５、出力装置６、などと接続され、それぞれとの情報の送受信を行う。

図２は、ネットワークシステム２の内部構成例を示している。図２は、ネットワーク上のネットワーク装置を接続するバスを構成する複数のネットワークリンク３０１を示している。ネットワークリンク３０１は、例えばＣＡＮバスなどのネットワークリンクである。図２は、ネットワークリンク３０１および図示していないハードウェア（例えばセンサ、アクチュエータ）やネットワークリンク３０１以外のネットワークリンク（専用線含む）に接続され、ハードウェアの制御およびネットワークとのデータ送受信を行うＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：電子制御ユニット）３０２を示している。図２は、複数のネットワークリンク３０１を接続し、それぞれのネットワークリンクとデータの送受信を行うゲートウェイ（以下、ＧＷと呼ぶ）３０３、を示している。

ＧＷ３０３は複数のネットワークリンクに接続されている場合があり、それぞれのリンクについてＩＤを付与して内部処理時にどのリンクに対する処理であるかについての識別を行う。この識別を行うＩＤをリンクＩＤと呼ぶ。リンクＩＤは、Ｃｈａｎｎｅｌ ＩＤ、またはドメインＩＤとも呼ばれる。

図２（ａ）、（ｂ）、（ｃ）はそれぞれ異なるネットワークトポロジの例を示している。図２（ａ）は、バスを構成する２つのネットワークリンク３０１ａおよび３０１ｂの各々に複数のＥＣＵ３０２が接続されている例を示している。ＧＷ３０３は、ネットワークリンク３０１ａに接続されたＥＣＵ３０２とネットワークリンク３０１ｂに接続されたＥＣＵ３０２との間のデータ転送を中継する。

図２（ｂ）は、複数のＥＣＵがそれぞれ、ネットワークリンク３０１ｃ、３０１ｄ、・・・、３０１ｅによって直接ＧＷ３０３に接続されるスター型と、バス型のトポロジが混在している例を示している。バスは、ネットワークリンク３０１ａおよび３０１ｃ、３０１ｄ、・・・、３０１ｅによって構成されている。ＧＷ３０３は、ネットワークリンク３０１ａ、３０１ｃ、３０１ｄ、・・・、３０１ｅのうちの２つのネットワークリンクを介したＥＣＵ３０２間のデータ転送を中継する。

図２（ｃ）はスター型のトポロジにスイッチ（以下、ＳＷと呼ぶ）３０４が挿入されている例を示している。ＳＷ３０４は、アップリンク側においてネットワークリンク３０１ｆによってＧＷ３０３に接続されている。ＳＷ３０４は、ダウンリンク側においてネットワークリンク３０１ｃ、３０１ｄ、・・・、３０１ｅによって、それぞれ１台ずつのＥＣＵ３０２を接続している。バスは、ネットワークリンク３０１ａおよび３０１ｆ、３０１ｇ、３０１ｈ、・・・、３０１ｉによって構成されている。ＳＷ３０４は、ネットワークリンク３０１ｆ、３０１ｇ、３０１ｈ、・・・、３０１ｉのうちの２つのネットワークリンクを介したＥＣＵ３０２間のデータ転送を中継する。ＧＷ３０３は、ネットワークリンク３０１ａおよび３０１ｆを介したＥＣＵ３０２間のデータ転送を中継する。

ＧＷ３０３とＥＣＵ３０２とは、必ずしも物理的に分離されているとは限らない。例えば、ＧＷ機能を有するＥＣＵ、またはＥＣＵの機能を有するＧＷであってもよい。

本実施の形態の説明においては、ネットワークプロトコルの変換が、ＧＷ３０３では行われ、ＳＷ３０４では行われない。本発明はＧＷ３０３およびＳＷ３０４のどちらにも適用可能である。

以下の説明において、ＧＷ３０３やＥＣＵ３０２、ＳＷ３０４など、ネットワークリンクで接続される装置のことをネットワーク装置とも呼ぶ。

ネットワークリンク３０１を介した通信においては、後述するネットワークプロトコル（手続き）の形式で通信を行う。後述するプロトコルによれば、ネットワーク装置間で送受信を行うデータ（以下、通信データ、またはペイロードとも呼ぶ）に対し、プロトコルで定められたヘッダを付与して通信を行う。

ＥＣＵ３０２はネットワークから受信したデータをもとに、ハードウェアへの制御信号の出力、ネットワークへの制御信号および情報の出力、内部状態の変更、などの移動体制御処理を行う。

図３は、本発明にかかるネットワーク装置であるＧＷ３０３、ＥＣＵ３０２またはＳＷ３０４の内部構成の一例を示す図である。図３は、キャッシュやレジスタなどの記憶素子を持ち、制御を実行するＣＰＵなどのプロセッサ４０１を示している。図３は、ネットワークリンク３０１に対してデータの送受信を行う通信インタフェース４０２を示している。図３は、図示しないクロックなどを使用し、時間および時刻の管理を行うタイマ４０３を示している。図３は、プログラムおよび不揮発性のデータを保存するＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）４０４、揮発性のデータを保存するＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）４０５、ＥＣＵ内部での通信に用いられる内部バス４０６を示している。図３は、鍵情報などを保護し、認証、ハッシュ演算、暗号、復号などの演算を行うセキュリティモジュール４０７を示している。

セキュリティモジュール４０７を用いることにより、不正アクセスから鍵情報を守り、認証などの処理負荷を削減することが可能となるが、耐タンパ性を強く求めない場合には、セキュリティモジュール４０７を使用しなくてもよい。

次にＣＰＵ４０１で動作するソフトウェアモジュールの構成について図４に示す。図４は、通信インタフェース４０２の動作および状態を管理し、内部バス４０６を介し通信インタフェース４０２に指示を行う通信管理部５０２を表している。図４は、タイマ４０３を管理し、時間に関する情報取得や制御を行う時間管理部５０３を表している。図４は、通信インタフェース４０２から取得したデータの解析や、ソフトウェアモジュール全体の制御を行う制御部５０１を表している。図４は、後述する鍵管理テーブル５０４、後述するフィルタテーブル５０５、受信したデータを保留するバッファ５０６を表している。

図４は、プロセッサ４０１上の動作概念を示したものである。プロセッサ４０１は、各ソフトウェアモジュールによって、動作時に必要な情報を、ＲＯＭ４０４およびＲＡＭ４０５から適宜取得し、またはＲＯＭ４０４およびＲＡＭ４０５に適宜書き込む。なお、後述する加工処理や認証処理においては高速処理が要求される場合もあるため、図４に示すような、制御部５０１によって実現される通信インタフェース４０２から取得したデータの解析は、ハードウェアで実現されることとしてもよい。

＜ネットワークプロトコルの例：ＣＡＮおよびＣＡＮＦＤ＞
図５に、ネットワークリンク３０２上での通信プロトコルにおけるデータ構造の例を示す。ここではＣＡＮおよびＣＡＮＦＤを使用した場合のフレーム（ネットワークにおける通信の１ブロック、パケットとも呼ぶ）のデータ構造を示しており、数値はフィールドごとのビット数を表している。

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

ＳＯＦ（Ｓｔａｒｔ Ｏｆ Ｆｒａｍｅ）はフレームの開始位置を示しており、フレームの同期を取るためにも用いられている。

識別子（ＩＤ）は、ＣＡＮデータのＩＤ（以下、ＣＡＮＩＤと呼ぶ）を示しており、ＣＡＮＩＤによりデータの種類を識別可能である。

ＩＤおよびＲＴＲ（Ｒｅｍｏｔｅ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｒｅｑｕｅｓｔ）ビットをアービトレーション・フィールドと呼び、このフィールドでバスのアービトレーション（調停）を行っている。

ＲＢ１、ＲＢ０は予約ビットであり、図５（ａ）の例では常にドミナントが入力される。一方、ＲＢ０の値がリセッシブの場合には、図５（ｂ）のような拡張フォーマットを表し、ＩＤを２９ビットで表現可能となる。拡張フォーマットのデータ・フィールド以降の構成は図５（ａ）と同様である。

データ長コードは、データ・フィールドのデータ長（バイト数）を表している。

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

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

アクノリッジについては、受信ノード（ネットワーク装置）が正しくデータを受信した場合に、応答のためにアクノリッジビットをドミナントにする。このようにして送信データの応答を返す。

ＥＯＦ（Ｅｎｄ Ｏｆ Ｆｒａｍｅ）はフレームの終端を示し、７ビットのリセッシブとなっている。以上のようなフォーマットでデータの送受信を行っている。

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

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

次にＣＡＮＦＤのプロトコルについて説明する。ＣＡＮＦＤはＣＡＮを拡張したプロトコルであるから、ＣＡＮとの差分についてのみ説明する。図５（ｃ）は、ＣＡＮＦＤの標準フォーマットにおけるデータ構造を示す。

ＥＤＬがＣＡＮＦＤのフォーマットであることを示すビットであり、ＥＤＬがリセッシブの場合には送信データがＣＡＮＦＤのフォーマットであり、ドミナントである場合にはＣＡＮのフォーマットであることを示している。

ＢＲＳはデータ送信中にビットレートを切り替えるか否かを示しており、リセッシブであればデータフェーズでビットレートを切り替え、ドミナントであればビットレートを切り替えない。

ＥＳＩはデータを送信するネットワーク装置のエラー状態を示しており、ドミナントであればデータを送信するネットワーク装置がエラーアクティブ、リセッシブであればエラーパッシブであることを示している。

またデータ長コードによるデータ長の符号化方式もＣＡＮＦＤとＣＡＮで異なる。データ長コードの符号化方法について図６に示す。ここでＣＡＮにおいてデータ長が８ｂｙｔｅの場合は、ｂｉｔ０、ｂｉｔ１、ｂｉｔ２はＤｏｎ’ｔ Ｃａｒｅである。図に示す通り、ＣＡＮＦＤでは６４ｂｙｔｅまでのデータ長の表現が可能である。

ＣＲＣフィールドは、ＣＡＮＦＤにおいては可変長であり、データ長により変化し、１７または２１ｂｉｔとなる。またＣＲＣ境界、アクノリッジについては、２ビットのデータを許容する。

ＲＢ１、ＲＢ０は予約ビットであり、図５（ｃ）の例では常にドミナントが入力される。ＣＡＮＦＤではＩＤＥの値がリセッシブの場合には、図５（ｄ）のような拡張フォーマットを表し、ＩＤを２９ビットで表現可能となる。拡張フォーマットのデータ・フィールド以降の構成は図５（ｃ）と同様である。

ＣＡＮのアービトレーション・フィールドおよびコントロール・フィールドをヘッダとも呼ぶ。

ＣＲＣを付与する目的は、信号に誤りが含まれていないかを確認するものであり、受信側で受信したデータが、送信者が送信およびＣＲＣを演算した内容と一致していれば、受信側で演算した結果についても同様となる。これにより、送信側が意図した送信データと不一致の場合（ＣＲＣエラー）には、受信側でデータを受信しない（破棄する）ことが可能となる。

＜ネットワークプロトコルの例：Ｅｔｈｅｒｎｅｔ＞
Ｅｔｈｅｒｎｅｔのデータ（フレーム）構造について図７に示す。図７（ａ）はＤＩＸ形式の構造であり、図７（ｂ）はＩＥＥＥ８０２．３形式の構造を表している。

プリアンブルおよびＳＦＤ（Ｓｔａｒｔ Ｆｒａｍｅ Ｄｅｌｉｍｉｔｅｒ）は、通信の同期を取るための固定パターンのデータを示している。宛先アドレスはデータ送信先のアドレス、送信元アドレスはデータ送信元のアドレスを示している。タイプは上位層のプロトコルの種別を示す値を表し、長さはデータ部分の長さ（オクテット：８ｂｉｔ単位）を表し、データはデータのペイロードを表す。ＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）はフレームのエラーを検出するためのフィールドであり、上述したＣＲＣと同様の演算結果を含む、図中に記載した数値はそれぞれのフィールドの長さ（オクテット単位）を示している。

＜ネットワークプロトコルの例：ＩＰ／ＴＣＰ／ＵＤＰ＞
ＥｔｈｅｒｎｅｔおよびＣＡＮの上位レイヤの例として、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）があり、データ構造を図８に示す。ＩＰヘッダの構造はバージョンにより異なり、バージョン４（ＩＰｖ４）のヘッダ構造を図８（ａ）に、バージョン６（ＩＰｖ６）のヘッダ構造を図８（ｂ）に記載する。長さは異なるが、どちらのバージョンにおいても送信元と送信先をヘッダ情報に含んでおり、これらの情報から送信者と受信者を判定することが可能である。通信データはペイロードに含まれる。

ＩＰのさらに上位のプロトコルの例として、ＴＣＰとＵＤＰがある。ヘッダ構造について、図９にＴＣＰヘッダの例を、図１０にＵＤＰヘッダの例を示す。ＴＣＰおよびＵＤＰのレイヤでは送信者および受信者の情報は無く、使用しているポート（通信の種類ごとに区別する番号）が記載されている。

これら複数プロトコルのレイヤ構造において、例えばＴＣＰ／ＩＰ／Ｅｔｈｅｒｎｅｔのプロトコルを使用して通信を行う場合には、通信データに対し、ＴＣＰヘッダが追加され、ＩＰヘッダが追加され、さらにＥｔｈｅｒｎｅｔのヘッダが追加されて、さらに必要により全体データが結合および分割されて送信される。

レイヤ構造を把握することにより、受信データのどの位置に送信者および通信の内容を特定する情報が含まれているか、また認証に必要なデータがどの部分か、を把握することが可能になる。

＜フォーマットエラー＞
上述したプロトコルにおいては、特定のビットについてはあらかじめ値、もしくは値の範囲が定められているフィールドがある。たとえば予約ビット（Ｒｅｓｅｒｖｅｄ ｂｉｔ）などがあり、それらがフォーマットに規定されている以外の値となることを、フォーマットエラーと呼ぶ。

また、ＣＡＮでは連続した６ビット以上の同一値の発生は、正常時の通信においては発生しないようにスタッフィングルール（５ビット連続した同一値の次には、異なる値によりスタッフィング）が定められている。それらに違反することもフォーマットエラーと呼ぶ。

また物理層の変調方式やデータリンク層の符号化方式により、あらかじめ定められたパターン以外（たとえば連続する電位値が４連続）になることも、フォーマットエラーと呼ぶ。

＜上書き可能なデータおよび上書き不可能なデータ＞
上記各プロトコルのデータ送信においては、それぞれの信号を電位の高低（１，０）や、ツイストペアケーブル間の差分電位の大小を制御することによって送信側が送信し、受信側でも同様に信号を判定し、受信している。その際、プロトコルの物理層の規定により、優位性のある信号の状態が存在する。

例えば、ＣＡＮの場合には、ドミナント（０）は、電位が０、もしくは差分電位が０となっており、リンクに接続されるネットワーク装置のいずれかが信号線を地絡した場合、他のネットワーク装置はリセッシブ（１）の値を発行できない。そのため、リセッシブは上書き可能なデータ、ドミナントは上書き不可能なデータとなる。

Ｅｔｈｅｒｎｅｔの場合についても、物理層の構成は異なるが、同様に信号線を地絡することにより、送信する電位値を書き換え可能な値、書き換え不可能な値により、データを上書きすることが可能となる。

＜フィルタテーブル＞
フィルタテーブル５０５の例を図１１に示す。図１１は、バスを介して転送されるデータを識別するためのデータＩＤ１２０１、データの送信元ＥＣＵ３０２が接続されているネットワークリンク３０１を示す送信元リンクＩＤ１２０２、そのデータの送信先ＥＣＵ３０２が接続されているネットワークリンク３０１を示す送信先リンクＩＤ１２０３、送信元ＥＣＵ３０２において使用されているデータ通信プロトコルを示す送信元プロトコル１２０４、そのデータの送信先ＥＣＵ３０２が接続されているネットワークリンク３０１において使用されるデータ通信プロトコルを示す送信先プロトコル１２０５、そのデータが認証対象であるか否かを示す認証対象フラグ１２０６、を表している。

フィルタテーブル５０５は、バスを介したデータの転送が許可されているか否かを、そのデータがデータＩＤ１２０１に適合しているか否かに基づいて管理するためのテーブルである。また、フィルタテーブル５０５は、データＩＤ１２０１に適合しているデータに対して、一方のネットワークリンク３０１、すなわち上りリンクから、他方のネットワークリンク３０１、すなわち下りリンクへのデータ転送処理を行うＧＷ３０３やＳＷ３０４にも設けられる。そうしたＧＷ３０３やＳＷ３０４に設けられるフィルタテーブル５０５は、送信元リンクＩＤ１２０２と送信先リンクＩＤ１２０３とによって、どのデータＩＤ１２０１に適合したデータが、どの上りリンクから到来すると、どの下りリンクから出ていくかについて表すフォワーディングテーブルでもある。さらには、ＧＷ３０３やＳＷ３０４に設けられるフィルタテーブル５０５は、送信元プロトコル１２０４と送信先プロトコル１２０５とによって、上りリンクから到来して下りリンクから出ていく際にプロトコル変換が必要であるか否かを表すプロトコル変換テーブルでもある。

データＩＤ１２０１の例としては、ＣＡＮやＣＡＮＦＤにおけるＣＡＮＩＤや、ＥｔｈｅｒｎｅｔにおけるＭＡＣアドレス、ＩＰにおけるＩＰアドレス、ＴＣＰやＵＤＰにおけるポート番号、およびそれら複数の情報の組み合わせ、がある。たとえばポート番号とＩＰアドレスの送信元および送信先を組み合わせることにより、通信経路と使用サービスとが特定される。

認証対象フラグ１２０６は、バスを介して転送されるデータに対して後述する認証処理を行うか否かを示している。ここでは“Ｙｅｓ”はそのデータに対して認証を行うことを表し、“Ｎｏ”はそのデータに対して認証を行わないことを表している。認証対象フラグ１２０６は、全データＩＤを認証対象とする場合、または後述する鍵管理テーブル５０４に記載のデータのみ認証対象とする場合、不要となる。

ＧＷ３０３にフィルタテーブル５０５が実装される場合は、ＧＷ３０３は、フィルタテーブル５０５に基づいて、バスを介して同一ネットワークリンク３０１に接続されたＥＣＵ３０２間で転送されるデータを検出したり、２つのネットワークリンク３０１を跨って転送されるデータを検出したりする。ＧＷ３０３は、フィルタテーブル５０５に登録されている受信元プロトコル１２０４および送信先プロトコル１２０５を参照し、必要に応じてデータ転送処理の際にデータのプロトコル変換を行う。ＥＣＵ３０２にフィルタテーブル５０５が実装される場合は、ＥＣＵ３０２は、一方のネットワークリンク３０１から他方のネットワークリンク３０１へのデータ転送処理を行わないため、ＥＣＵ３０２が接続される単一のネットワークリンク３０１で使用されるプロトコルが決まっていれば、フィルタテーブル５０５には、送信元リンクＩＤ１２０２、送信先リンクＩＤ１２０３、送信元プロトコル１２０４および送信先プロトコル１２０５が不要となる。ＳＷ３０４が、一方のネットワークリンク３０１から他方のネットワークリンク３０１へのデータ転送の際にプロトコルの変換を行わず、ＳＷ３０４が接続される複数のネットワークリンク３０１で使用されるプロトコルがあらかじめ限定されている（例えばＥｔｈｅｒｎｅｔのみに限定されている）場合、フィルタテーブル５０５には、受信元プロトコル１２０４および送信先プロトコル１２０５が不要となる。

＜通信インタフェースにおけるデータ検出処理、転送処理および加工処理＞
通信インタフェース４０２によるデータ検出処理のため、プロセッサ４０１は、例えば転送が必要なデータＩＤとして設計時に定められたデータＩＤに登録されているフィルタ情報を、フィルタテーブル５０５から読み出し、通信インタフェース４０２に指定する。こうしてデータＩＤが指定された通信インタフェース４０２は、送信元ＥＣＵ３０２から送信先ＥＣＵ３０２へネットワークリンク３０１で転送される信号を監視する。通信インタフェース４０２は、認証対象として指定されたデータＩＤに一致するデータがネットワークリンク３０１上で転送された場合に、プロセッサ４０１による認証処理のため、そのデータを、データＩＤと共にプロセッサ４０１に通知する。認証処理が通信インタフェース４０２によって行われる場合は、プロセッサ４０１への通知は必ずしも必要ではない。

データ検出処理においては、通信インタフェース４０２は、上述したフィルタテーブル５０５の一例に記載されたデータＩＤ以外のデータＩＤを、フィルタテーブル５０５に記載することによって、登録することも可能である。例えばＣＡＮのＣＡＮＩＤ、Ｅｔｈｅｒｎｅｔのアドレスについて、マスク指定（特定のビットについて、どの値でも受信）でフィルタテーブル５０５に登録することにより、通信インタフェース４０２は所定範囲のデータＩＤに対応するデータを検出可能であり、ＣＡＮＩＤおよびＥｔｈｅｒｎｅｔアドレスについて全ビットをマスクすることにより、すべてのデータを検出することも可能になる。

上りリンクから下りリンクへのデータ転送処理を行うＧＷ３０３やＳＷ３０４に設けられる通信インタフェース４０２の下りリンクから出ていくデータの転送処理としては、プロセッサ４０１からデータの転送処理指示が転送する情報を伴って通信インタフェース４０２に入力された場合に、その情報にさらに必要な情報を付加して得られるデータが、ネットワークプロトコルに合わせたデータ形式でネットワークリンク３０１に出ていく。

また通信インタフェース４０２は、指定されたデータを検出および転送するのみでなく、その指定されたデータに対して加工処理も行う。例えばネットワークリンク３０１上を流れる現在の信号値がデジタル表現の０（例えばネットワークリンク３０１の電位が基準値より低い）の場合に、デジタル表現の１（例えばネットワークリンク３０１の電位が基準値より高い）に信号値を書き換えるといった操作、または逆に、ネットワークリンク３０１上を流れる現在の信号値をデジタル表現の１から０に書き換える操作を行う。これらは通信の応答（Ａｃｋ等）が返される場合にも行われる。

＜なりすまし攻撃＞
本発明による主な防御の対象である、なりすまし攻撃の例について説明する。例えば図２において、攻撃者は、外部の通信機器と接続されているＥＣＵ３０２（以降、ＥＣＵ＿Ａと呼ぶ）について攻撃し、ＥＣＵ内部のＲＯＭ４０４またはＲＡＭ４０５のデータを不正に書き換える攻撃（改ざん）を行い、ＥＣＵ＿Ａからネットワークリンク３０１に対し、他のＥＣＵ（以降、ＥＣＵ＿Ｂと呼ぶ）になりすました不正なデータを送信させる。その場合、不正なデータを受信した他のＥＣＵは、状況判断を誤り不正な動作を起こす可能性がある。このような攻撃をなりすまし攻撃と呼ぶ。

なりすまし攻撃の経路としては、上記ＥＣＵ＿Ａの改ざん以外にも、ネットワークリンク３０１に直接不正な機器を接続される場合、ＥＣＵに接続される機器になりすまして不正な情報を送信する場合、などがある。

＜認証処理＞
なりすまし攻撃を防止する手段として、データ（メッセージ）に対する認証がある。認証とは、送信者が、所有している非公開情報（以降、鍵または鍵情報と呼ぶ）を用いて署名（電子署名）を作成し、受信者がその署名を確認することにより、正当な送信者からデータが送信されていることを確認する技術である。

例えば、データが改ざん無く正しい送信者から送信されたことを確認するために、署名（ＭＡＣ：Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）をメッセージ認証用情報として認証する方法がある。手順を図１２に示す。

図１２（ａ）は、送信側と受信側で同じ鍵情報を持つ共通鍵方式の場合の演算例を示す。送信側では、送信するデータのハッシュを求める演算を行う。ハッシュとはデータの特徴を表す情報であり、特にデータが改ざんされた場合にハッシュの値が大きく変わることから、データが改ざんされていないことを確認するために用いられる。

次にハッシュに対して暗号化（符号化）を行う。暗号化には送信者が有する鍵（送信者鍵）および付随情報を使用する。ハッシュを送信者鍵で暗号化したものを署名とし、データと共に送信を行う。

付随情報とは、例えば初期値ベクトル（ＩＶ：Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｖａｃｔｏｒ）の様に、生成される署名の偏りを防ぐ等の目的で鍵とは別に用いる情報であり、後述する鍵交換手順等で事前に送付され、または署名データに付与され、送信側と受信側で共通する情報を保持する。付随情報はデータと共に暗号化される場合と、暗号化されない場合の両方がある。

受信側では、受信したデータについて、送信者側と同じ手順で署名を生成する。この際に、受信側の鍵として送信者側と同じ鍵を用いて同じ処理を行うことにより、同じ署名データが得られる。

データまたは署名に対して改ざんが行われている場合には署名が一致しないため、データが改ざんされていないことを確認することができ、結果として送信元のなりすましが生じていないことを確認可能である。

上記手順以外に、ハッシュ演算と暗号化を同時に実施することも可能である（ＨＭＡＣ：Ｈａｓｈ−Ｂａｓｅｄ ＭＡＣ）。例えばハッシュ演算を行うデータに対し、送信者鍵を加算（ＸＯＲ）するなどの演算を行い、署名を作成する。その後受信側で同様の演算を行って署名を作成し、署名を比較することにより認証を行うことが可能となる。署名が一致した場合、認証ＯＫであり、署名が不一致の場合、認証ＮＧである。

また、上記では送信側と受信側で同じ鍵情報を持つ共通鍵方式の場合の演算例について示したが、共通鍵（対称鍵）ではない場合でも可能な処理について図１２（ｂ）に示す。この場合は、送信側の手順は同様で、受信側では同様の手順を実施する代わりに、署名を復号してデータのハッシュ値を求め、別途データから演算したハッシュ値と比較することにより、データの署名を確認する。ハッシュ値が一致した場合、認証ＯＫであり、ハッシュ値が不一致の場合、認証ＮＧである。このようにすることにより、非対称な鍵の場合でも署名を確認することができ、ハッシュ演算と復号化の並列処理も可能となる。

共通鍵の場合でも図１２（ｂ）と同様の認証処理を行ってもよい。

非対称鍵の演算は一般的に処理負荷が高くリアルタイム性が満たすことが厳しいため、後述する鍵交換手順を用いて、共通鍵を事前に共有しておく。

データについては、本来通信で必要なデータ以外にも様々なデータを付与して演算を行う。例えば、データにタイムスタンプ（送信するタイミングなどの時刻情報）を付与することにより、同じデータを再送してなりすましを行うリプレイアタックへの防御が可能になる。また乱数を付与することにより、毎回異なるデータを暗号化することになり、鍵情報を推測されることが困難になる。カウンタを付与することにより、正しい順序（タイミング）でデータが送信されることを確認することが可能となる。

ここでハッシュ演算については、何も処理を行わなくても良く、そのようにすることにより情報の撹拌性は低くなるが、演算量も低くなる。

＜署名付き通信データフォーマット＞
署名を付与した通信データのフォーマットについて図１３に示す。これは上記ネットワークプロトコルのペイロード部分のデータとなる。

図１３は、署名が付与されているか否かを表す署名有無１４０１、通信データの長さを表す通信データ長１４０２、署名の長さを示す署名長１４０３、通信データ１４０４、上記認証処理により送信者側で作成された署名データ１４０５、必要に応じ認証処理演算が終了するまでの時間猶予を保持するためのマージン１４０６、認証が正常に行われたか否かを判定するために用いられる認証結果情報を示す認証Ａｃｋ１４０７を表している。

署名付き通信データについては全てのフィールドが必須では無い。例えば署名有無のフィールドについては、上位のプロトコルのヘッダに情報を含むことも可能である。例としては、Ｅｔｈｅｒｎｅｔヘッダのタイプ、ＩＰヘッダのプロトコルにて、署名を使用するプロトコルとして定義を行うこととしてもよい。ＣＡＮおよびＣＡＮＦＤの予約ビットにて認証の有無を示すこととしてもよい。または、あらかじめ署名を使用する送信元や送信先、使用サービスの組み合わせを決定しておくこととしてもよい。これらの対応により、署名有無のフィールドは不要となる。これによりペイロードを受信する以前に認証有無が解り、処理が高速（ペイロードの判定が不要となることが判断可能、認証有無の情報を受信するタイミングが比較的早い）になる点や、レガシー機器との共存（不正なヘッダ、プロトコルであるため自動的に破棄）が可能になる。

また通信データ長、署名長について全ての転送データに含まれる必要は無く、署名付き通信を行う前にあらかじめ通信データ長や署名長を固定値で決定しておき、決定した固定値で通信を行うことにより不要となる。このようにすることにより、通信に使用するデータ量の削減が可能となる。

またマージン１４０６、認証Ａｃｋ１４０７についても、後述する使用方法により使用をしない場合には不要となる。

また署名データについては、全通信データに存在する必要はなく、上位レイヤにおける通信単位ごとに署名が作成されることとしても良い。例えば、元のデータが１Ｍｂｙｔｅであり、複数のパケットに分割される場合には、最終パケットにのみ署名が存在していれば良い。そのようにすることにより、送信側と受信側での演算量が削減可能となる。

＜鍵交換手順＞
認証処理においては、送信側および受信側で鍵の管理が必要になる。特に、同じ鍵を長期間使用し続けることはセキュリティ上鍵情報の漏洩リスクが高まるため、一定期間ごとに一時的な鍵（セッション鍵）を更新し、同じ鍵を使い続けないことが望ましい。

そのため、例えば２つのＥＣＵ３０２の間で鍵交換を行う場合、一方のＥＣＵ３０２は、他方のＥＣＵ３０２の公開鍵でセッション鍵を暗号化して他方のＥＣＵ３０２宛てに送信し、受信した他方のＥＣＵ３０２は自身の秘密鍵で復号化しセッション鍵を取得するなどの処理を行う。この交換したセッション鍵を、認証処理の送信者鍵および受信者鍵として使用する。

また別の方法としては、公開鍵と秘密鍵のペアを用いず、製造時またはメンテナンス時にそれぞれ固有の鍵（マスタ鍵）をＥＣＵ３０２のＲＯＭ４０４またはセキュリティモジュール４０７に埋め込み、製造時またはメンテナンス時にそれぞれ通信を行うＥＣＵ３０２のマスタ鍵情報を交換しておく。製品使用時にはこれらマスタ鍵を用いてセッション鍵を暗号化し、鍵を共有する。

これらの方法で、鍵情報、または鍵情報に関する様々な情報（鍵の有効期限、初期ベクトル、暗号対象のデータＩＤ、等）を安全に交換することが可能となる。なお、ＥＣＵ３０２の場合を例に説明したが、ＧＷ３０３またはＳＷ３０４の場合についても同様である。

＜鍵管理テーブル＞
鍵管理テーブルの例について、図１４に示す。鍵管理テーブル５０４は、認証対象のデータを識別するデータＩＤ１５０１、認証対象のデータの通信に用いられるプロトコル１５０２、認証に用いられる鍵データ１５０３、鍵データの有効期限１５０４、鍵が有効か否かを示すフラグ１５０５、通信データ１４０４のデータ長１５０６、署名の長さ１５０７、により構成される。鍵管理テーブル５０４は、認証対象のデータに対する制御部５０１による認証用の鍵を管理するテーブルである。

データＩＤ１５０１については、フィルタテーブル５０５におけるデータＩＤ１２０１と同様である。通信経路と使用サービスなどを表すデータＩＤ１５０１の情報から、各データＩＤ１５０１に対応する鍵を判断することが可能となる。

またプロトコル１５０２がわかることにより、受信したデータのどの位置に通信データおよび署名が含まれているかがわかる。プロトコル１５０２は、図１１に例示したフィルタテーブル５０５にも含まれている。プロトコル１５０２は、鍵管理テーブル５０４およびフィルタテーブル５０５のうちのどちらかのテーブルに存在していれば、データＩＤ１５０１またはデータＩＤ１２０１から参照可能である。

鍵データ１５０３は、鍵情報の直値、または、鍵を示す鍵ＩＤもしくはポインタである。鍵データ１５０３が鍵ＩＤの場合、鍵ＩＤを指定し、セキュリティモジュール４０７にデータを送信し署名を確認することも可能である。そのようにすることにより、鍵データを外部に漏洩させずに安全に管理可能であり、またプロセッサに負荷をかけずに認証を行うことが可能になる。

鍵有効期限１５０４には、鍵の有効期限が記載されている。これは鍵を更新するごとに必要に応じて有効期限が更新される。または無期限の場合もある。鍵が未取得の場合には、鍵を未だ取得していないことを示す情報（絶対的な過去時間：ＡＬＬ０等）、を示すことも可能である。そのようにすることにより後述の鍵情報有効フラグ１５０５が不要となる。

鍵情報有効フラグ１５０５は鍵情報が有効か否かを示すフラグである。鍵が有効でないとは、例えば、データＩＤの鍵情報を送信ネットワーク装置と鍵交換をしていないために鍵が有効でない、または不正アクセスや攻撃を受けた等の理由により鍵情報が無効化された、等を示している。

通信データ長１５０６および署名長１５０７は、署名付き通信データフォーマットの通信データ長１４０２および署名長１４０５に記載された通りの内容である。通信データ長１５０６および署名長１５０７が鍵管理テーブル５０４に保持されることにより、通信のたびに署名付き通信データフォーマットの通信データ長１４０２および署名長１４０５を取得する処理が不要となり、処理が軽減できる。

＜バスを介して送信元ＥＣＵから送信先ＥＣＵへ転送中のデータ検出時の処理＞
車両の各種制御を行う送信元ＥＣＵから、同様に車両の各種制御を行う送信先ＥＣＵへ、バスを介して転送中のデータ検出時における、ネットワーク装置（ＥＣＵ３０２、ＧＷ３０３またはＳＷ３０４）のプロセッサ４０１が有する制御部５０１による処理について図１５を用いて説明する。ここでは本発明をＧＷ３０３に適用した例について説明するが、ＥＣＵ３０２またはＳＷ３０４に適用した場合についても同様である。

まずＧＷ３０３においては、ネットワークリンク３０１でバスを介して転送されるデータのうちから、通信インタフェース４０２が、プロセッサ４０１によって指定されたフィルタ情報にしたがって認証対象データを検出する。その後通信インタフェース４０２から、認証対象データ検出を通知された制御部５０１は、フィルタテーブル５０５および鍵管理テーブル５０４を参照し、転送中のデータのデータＩＤが、それらのテーブルのデータＩＤと一致し、かつ認証対象フラグが“Ｙｅｓ”であるデータか否かを確認する（ステップＳ１０１）。なお、上述したように、通信インタフェース４０２がプロセッサ４０１によって指定されたフィルタ情報にしたがって認証対象データを検出するので、ステップＳ１０１では、フィルタテーブル５０５を必ずしも参照しなくても良い上に、鍵管理テーブル５０４のデータＩＤをも必ずしも参照しなくても良い。ステップＳ１０１において、テーブルのデータＩＤに記載が無いまたは認証対象フラグが“Ｎｏ”であるデータに対しては否定判定がなされ、ステップＳ１０２におけるデータ認証処理が行われない。テーブルのデータＩＤに記載があってかつ認証対象フラグが“Ｙｅｓ”であるデータに対しては肯定判定がなされる。制御部５０１は、鍵管理テーブル５０４を参照し、ステップＳ１０１で肯定判定された認証対象データに対応した鍵を基にデータ認証処理を行う（ステップＳ１０２）。上述したように、転送中のデータが送信元ＥＣＵ３０２のなりすましによって転送されているか否かに関する認証処理が行われる。

その後、ステップＳ１０３において、認証結果がＯＫ（成功）である場合には、肯定判定がなされ、制御部５０１は、その認証が行われたデータに対しては特に処理を行わずに、通信インタフェース４０２へ、そのデータを引き渡す。そのデータが引き渡された送信先ＥＣＵ３０２によって、そのデータの中から、暗号化されていない図１３に示した通信データ１４０４が取り出される。ステップＳ１０３において、転送中のデータがなりすましによって転送されたために認証結果がＮＧである場合には、否定判定がなされる。制御部５０１は、転送中のデータは送信元ＥＣＵ３０２のなりすましによって転送されている不正データであると判断し、そのデータを通信インタフェース４０２へ引き渡す際に、そのデータに対して、後述するデータ無効化などの加工処理を行うように、通信インタフェース４０２に指示する（ステップＳ１０４）。

このようにデータの認証結果を確認し、認証結果が失敗の場合にはデータ無効化などの加工処理を行うことにより、送信元装置のなりすましによる不正なデータの転送を防ぐことが可能となる。なお、図１５を用いて上述した制御部５０１による認証処理は、通信インタフェース４０２によって行われることとしてもよい。認証処理が通信インタフェース４０２によって行われることによって、高速処理が可能となる。また、図１５のステップＳ１０４における制御部５０１からの指示に基づいて行われる通信インタフェース４０２によるデータ加工処理が、制御部５０１によって行われることとしてもよい。ＧＷ３０３やＳＷ３０４のように２つのネットワークリンク３０１を跨ったデータ転送を中継する装置に本発明を適用する場合は、後述する加工処理のうち、認証Ａｃｋの値を書き換えるといった上位レイヤ処理は、エラーフレーム生成のような下位レイヤ処理とは異なり、制御部５０１によって行われることが好ましい。

＜データ無効化＞
通信インタフェース４０２は、データ加工処理において、転送中のデータを受信した送信先ＥＣＵ３０２によって認証が失敗したことが検出されるように、そのデータを加工することによって、そのデータを無効化する。データ無効化の例として、ＣＡＮおよびＣＡＮＦＤの場合には、転送中のフレームに連続６ビット以上のドミナントを発生させて、その転送中のフレームをエラーフレームにすることができる。このようにすることにより、転送中のデータを無効化することが可能となる。

また別の方法としては、署名付き通信データフォーマットにおける認証結果情報を示す認証Ａｃｋ１４０７について、送信者がリセッシブで送信していた値を、上書き不可能な値であるドミナントに書き換えて設定する。そのようにすることにより受信側のネットワーク装置が認証Ａｃｋを確認し、データが認証失敗により無効化されたことを確認できる。

また認証Ａｃｋのデータを書き換えることにより、ＣＲＣの演算結果が不正となるため、同様にエラーの含まれたデータとして無効化させることが可能となる。

また別の方法としては、一定期間通信を妨害するために、常時ドミナント（電位０）の値とし、以降の通信を不能化させることによりデータを無効化することも可能である。

Ｅｔｈｅｒｎｅｔの例においても送信者の送信パターンと異なる信号を発生させることにより、受信側での受信エラー（復号エラーや、フレームチェックシーケンスエラー）を発生させ、データを無効化させることが可能となる。

またＣＡＮおよびＣＡＮＦＤと同様に、署名付き通信データフォーマットにおける認証Ａｃｋを認証が失敗したことを示す情報に変更することにより、或いは、バスの電位制御を行って一定期間通信を妨害することにより、無効化することが、Ｅｔｈｅｒｎｅｔにおいても可能である。

上述したように、認証Ａｃｋについては、送信者は上書き可能な値を送信し、認証を行うネットワーク装置は、不正なデータの場合に認証Ａｃｋについて以後の上書きが不可能な値で上書きを行う。このような構成にすることにより、攻撃者は、不正なデータとみなされ上書きされ続けている転送中のデータの残りの部分について、不正な送信元ネットワーク装置にバスの電位制御をさせて、認証を行うネットワーク装置による上書き制御を行わせずに正常なデータで送信させるということができない。したがって、送信先ネットワーク装置によって不正なデータが正常なデータと誤認識されることを防ぐことが可能になる。

このようにデータの無効化を行うことにより、無効化されたデータを受信した送信先ネットワーク装置が、そのデータをエラーとして破棄するため、送信先ネットワーク装置による不正なデータによる処理の実行を防ぐことが可能となる。

以上の様に、ネットワーク装置が送信したデータに対し、他のネットワーク装置が認証処理を行い認証結果が失敗の場合にデータを無効化する加工処理を行うことで、不正なデータ転送を防ぐことが可能となる。特にネットワーク装置がネットワークリンクで転送されているデータに対し認証処理と加工処理を行うことにより、データの受信を行う複数のネットワーク装置での認証処理が不要となる。

−−−第２実施形態−−−
認証処理を行うネットワーク装置が、転送データ検出時に、認証結果が失敗の場合だけでなく、データ形式が想定する形式に一致しない転送データを全て無効化させる例について説明する。本実施形態におけるネットワーク装置が有する制御部５０１による転送データ検出時の処理について図１６を用いて説明する。第１実施形態と異なる点は、ステップＳ２０１におけるデータ形式判定処理が追加された点である。したがって、第１実施形態と異なる点を中心に図１６を用いて説明し、図１６のうちで図１と同一のステップ番号を付した処理内容については、説明を省略する。

データ形式とは、ここではデータＩＤ、データＩＤで特定されるデータが転送されるバスのネットワークリンクＩＤ、上記プロトコルで規定されているそのデータのヘッダの形式、そのデータの順序を表すカウンタ、そのデータが送信されるタイミングを表すタイムスタンプ、鍵の有効期限、そのデータが上述した認証用の署名付き通信データを伴う場合の通信データ長、およびそのデータがその署名付き通信データを伴う場合の署名長などが挙げられる。

ステップＳ２０１において、制御部５０１は、検出された転送中のデータに対するデータ形式判定処理を行い、そのデータのデータ形式が想定しているデータ形式と一致していると判定した場合には、上述した次のステップＳ１０１に処理を進める（ステップＳ２０１においてｙｅｓ）。検出された転送中のデータのデータ形式が想定しているデータ形式と一致しているというのは、具体的には、フィルタテーブル５０５に、転送中のデータのデータＩＤ１２０１および受信元リンクＩＤが記載されていること、転送中のデータが認証対象フラグが“Ｙｅｓ”であるデータであって、かつ鍵管理テーブル５０４に記載されたデータＩＤ１５０１に対応していること、転送中のデータが、鍵管理テーブル５０４に記載されたプロトコル１５０２や鍵データ１５０３に対応していること、転送中のデータに対応する鍵有効期限１５０４が有効な期間であること、転送中のデータに対応する鍵有効フラグ１５０５が有効であること、転送中のデータの通信データ長が通信データ長１５０６と一致すること、転送中のデータの署名長が署名長１５０７と一致すること、などの様々な条件が挙げられる。

また上記以外にも、通信データに含まれる転送中のデータの順序を表すカウンタが連続していること、転送中のデータが送信されるタイミングを表すタイムスタンプが現在時刻から一定値以内であること、といった場合にも、制御部５０１は、データ形式が一致すると判定する。

なお、データ形式が一致と判定される上記条件のうちのいくつかについては、制御部５０１ではなく通信インタフェース４０２によって行われることが好ましい場合、通信インタフェース４０２によって行われた条件判定結果が制御部５０１に通知されることとしてもよい。

データ形式が不一致（データ形式判定結果が失敗）の場合（ステップＳ２０１においてｎｏ）には、第１実施形態および本実施形態における認証ＮＧの場合（ステップＳ１０３においてｎｏ）と同様に、制御部５０１は、その転送中のデータの加工処理を通信インタフェース４０２に指示することによって（ステップＳ１０４）、通信インタフェース４０２にデータの無効化を行わせる。なお、第１実施形態で説明したように、ステップＳ１０４における制御部５０１からの指示に基づいて行われる通信インタフェース４０２によるデータ加工処理が、制御部５０１によって行われることとしてもよい。

本実施形態においては、該当ネットワーク装置が認証対象データの検出を行うネットワークリンクにおいて転送される可能性があるデータを、全てフィルタテーブル５０５および鍵管理テーブル５０４に登録しておく。これらのテーブルがホワイトリスト（全ての安全なデータを記載したリスト）となり、フィルタテーブルに無いデータの転送（不正なデータ転送）を防ぐことが可能となる。

上述したように、制御部５０１は、図１６のステップＳ２０１で、転送中のデータが、バスを介したデータの転送が許可されているか否かを管理するフィルタテーブル５０５、および転送が許可されているデータに対する認証用の鍵を管理する鍵管理テーブル５０４に対応しているか否かを判定する。ステップＳ１０３で認証が失敗した場合に加えてさらに、ステップＳ２０１において、そのデータがフィルタテーブル５０５および鍵管理テーブル５０４の少なくとも一方に対応していない場合に、通信インタフェース４０２は、そのデータ転送中に、そのデータを無効化する。フィルタテーブル５０５および鍵管理テーブル５０４に記載の無いデータＩＤ、または不正な形式のデータ送信を防ぐことが可能となる。なお、ヘッダの情報による判定は、認証処理を行うより処理負荷が小さいため、ヘッダの情報を基に不正なデータを判定することにより処理負荷の低減も可能となる。

−−−第３実施形態−−−
次に、ＧＷ３０３またはＳＷ３０４が、一方のネットワークリンク３０１から他方のネットワークリンク３０１へ、転送データの中継を行う場合に、データが無効化される例について説明する。ここでは本実施の形態におけるネットワーク装置の例として、ＧＷ３０３を例にして説明するが、ＳＷ３０４においても同様である。

ＧＷ３０３が、図２（ａ）に示すように、送信元ネットワーク装置が接続されたネットワークリンク３０１ａから、送信先ネットワーク装置が接続された、ネットワークリンク３０１ａとは異なるネットワークリンク３０１ｂにデータを中継する場合の例について説明する。ＧＷ３０３において、送信元ネットワーク装置が接続されたネットワークリンク３０１ａからのデータが入力され、そのデータのヘッダから送信先を確認し、ネットワークリンク３０１ｂに出力される。この場合、データを低遅延で転送するため、ＧＷ３０３の通信インタフェース４０２または制御部５０１は、ＧＷ３０３の通信インタフェース４０２へ入力中のデータのヘッダを解析し、送信先ネットワーク装置がわかった時点で、そのデータをネットワークリンク３０１ｂへ出力することを開始する。

その後、そのデータの残りの部分がネットワークリンク３０１ａからＧＷ３０３へ引き続き入力され、そのデータが有する署名データがＧＷ３０３へ入力された時点で、図１または図１６に記載のデータ認証処理がＧＷ３０３において実施される。認証結果が失敗（ステップＳ１０３においてＮｏ）またはデータ形式が一致しない（ステップＳ２０１においてＮｏ）と判定された場合には、データ加工処理として、ネットワークリンク３０１ｂへ出力中のデータおよび／またはネットワークリンク３０１ａから入力中のデータに対して上述した加工処理が実施される。

このような処理を実行することにより、ヘッダの確認のみで低遅延なデータ転送を可能にした上で、さらにその後認証結果が失敗と判定した場合に、不正なデータを無効化することが可能となる。

−−−第４実施形態−−−
次に本発明を適用したネットワーク装置が動作していることを確認する例について説明する。まず一つの方法としては、上述した認証Ａｃｋの情報について、送信元ネットワーク装置では、上書き可能な情報（例えばＣＡＮにおけるリセッシブ（１））で制御部５０１が作成し、ＣＲＣ演算の際には認証Ａｃｋの値として上書きされた情報（例えばＣＡＮにおけるドミナント（０））で通信インタフェース４０２が演算を行い、その後、通信インタフェース４０２がそのデータを送信する。図１７を用いて詳細を説明する。図１７は、本実施形態におけるデータ検出時の制御部における処理を表すフローチャートである。第１実施形態におけるデータ検出時の制御部における処理を表す図１５と同一のステップ番号の処理については、説明を省略する。

送信元ネットワーク装置から送信されて、送信先ネットワーク装置へ転送されるデータを検出したネットワーク装置が有する制御部５０１は、ステップＳ１０２において第１実施形態の手順と同様のデータの認証を行い、ステップＳ３０３において認証ＯＫの場合には、ステップＳ３０４において認証Ａｃｋを上書き可能な値（例えばＣＡＮにおけるドミナント（０））で上書きするように、通信インタフェース４０２に指示する（ステップＳ３０３において肯定判定）。認証結果が失敗の場合にはデータの加工は行われない（ステップＳ３０３において否定判定）。すなわち、認証が行われるネットワーク装置の制御部５０１は、転送中のデータの認証Ａｃｋを上書きすることによって、認証を行ったことを示すための加工を、そのデータの転送中に、そのデータに対して行う。

転送されたそのデータを受信した送信先ネットワーク装置は、認証Ａｃｋを確認して上書きされていることを確認し、またはＣＲＣ演算結果がＣＲＣフィールドが示す値と一致していることを確認することによって、そのデータが正しく認証されていることを確認できる。また、送信先ネットワーク装置は、受信したデータの認証Ａｃｋが上書きされているため、認証処理を行うネットワーク装置が正常に動作していることを確認することもできる。認証Ａｃｋを確認して上書きされていないことを確認するか、またはＣＲＣ演算結果がＣＲＣフィールド値と不一致であることを確認した送信先ネットワーク装置は、受信したデータが認証処理を行うネットワーク装置によって正しく認証されていないと判断するとともに、受信したデータは不正なデータであるか、または認証を行うネットワーク装置が動作していない状況のどちらかであると判断し、受信したデータを廃棄する。

このようにすることにより、認証を行うネットワーク装置が正常に動作をしていない、または署名の演算が間に合わないような状況において、不正なデータが送信されていたとしても、受信側で正しいデータと見なされて動作することを防ぐことが可能となる。なお、このような、認証を行うネットワーク装置が正常動作をしていることを認証Ａｃｋによって表示する処理は、例えば通常のデータ転送が行われている期間中に行われてもよいが、メンテナンスのために通常のデータ転送が行われない診断モードにおいて行われることが、より好ましい。

認証を行うネットワーク装置が動作していることを確認する本実施形態の変形例として、認証を行うネットワーク装置が署名データを処理するまでは、図１３に示す署名付き通信データフォーマットのマージン１４０６にドミナントが設定されたデータが送信され、署名データの処理が終了した時点でマージン１４０６にリセッシブが設定されたデータが送信される。そのようにすることにより、認証を行うネットワーク装置が動作していることを確認可能となる。

その際、マージン１４０６に設定された信号の値を含むＣＲＣ計算は、送信元ネットワーク装置においても送信先ネットワーク装置においても実施されず、マージン１４０６に設定された信号の値によらずにＣＲＣが計算される。このようにすることにより、認証を行うネットワーク装置が、マージン１４０６を用いて認証処理を行った場合であっても、そのマージン１４０６を含むデータのＣＲＣを計算することが可能となる。

さらに他の変形例としては、送信元ネットワーク装置から送信先ネットワーク装置へのデータ転送が行われるネットワークリンクとは別の、例えば保守用のネットワークリンクまたは専用線において、認証処理を行うネットワーク装置の制御部５０１が、制御部５０１による認証動作が正常に行われていることを示す情報を、送信元ネットワーク装置や送信先ネットワーク装置へ送ることとしてもよい。この場合、認証処理を行うネットワーク装置が動作していることを示す情報としては、上述したデータ形式の他に、定期的な定型データの送信、上記署名データ、データ認証のタイミングに合わせたデータの送信、などがある。このように複数のネットワークリンクまたは専用線を用いて認証処理を行うネットワーク装置の動作を確認することにより、いずれかの経路が攻撃をされた場合でも、認証処理を行うネットワーク装置が動作していることを各ネットワーク装置が正しく確認可能することができる。

−−−変形例−−−
署名の作成および認証の処理を低減するために、署名の作成における符号化にストリーム暗号を使用する変形例について説明する。ストリーム暗号の例としては、ＭＵＧＩ（登録商標）、ＭＵＬＴＩ−ＳＯ１、ＲＣ４（登録商標）、Ｅｎｏｃｏｒｏ（登録商標）などがある。ストリーム暗号によれば、暗号および復号処理がビット単位で実施でき、高速な処理が実行可能である。その場合の署名作成の例としては、図１２の例において、暗号化および復号化の処理においてストリーム暗号を用い、処理をビット（またはバイト）単位で実施する。作成された署名データは、データと署名をビット単位で結合しても良く、または全ての署名データを出力してから結合してもどちらの形式でも可能である。

ストリーム暗号を用いる場合のハッシュ演算に関しては、実施を行わないか、ビット、またはバイト単位でストリーム暗号を行う単位と同じ単位で実行を行う。特にＭＵＬＴＩ−Ｓ０１など、データの撹拌や改ざん検出の機能が備わっている暗号の場合には、ハッシュ演算処理が不要となる。

このように符号化方式としてストリーム暗号等の逐次処理が可能な暗号を用いることにより高速に判定が可能となり、データの転送期間中に署名の演算を完了させることが容易となる。

上述した実施の形態および変形例におけるネットワーク装置は、車両の各種制御を行う送信元ネットワーク装置および送信先ネットワーク装置とバスで接続されたネットワーク装置であって、制御部５０１と通信インタフェース４０２とを有する。制御部５０１は、バスを介して送信元ネットワーク装置から送信先ネットワーク装置へ転送中のデータに含まれる署名に基づいて、データが送信元ネットワーク装置のなりすましによって転送されているか否かに関する認証を行う。データがなりすましによって転送されたたために認証が失敗した場合は、通信インタフェース４０２は、データの転送中に、データを無効化する。したがって、不正なデータ転送を防ぐことが可能となる。これにより、送信先ネットワーク装置での認証処理や鍵の管理等のセキュリティ対策が不要となる。その結果、個々のネットワーク装置を必要時のみ起動するパーシャルネットワーキングも可能となる。

第２実施形態におけるネットワーク装置は、バスを介したデータの転送が許可されているか否かを管理するフィルタテーブル５０５と、データに対する制御部５０１による認証用の鍵を管理する鍵管理テーブル５０４とを、さらに有する。このネットワーク装置が有する制御部５０１は、データの転送中に、データがフィルタテーブル５０５および鍵管理テーブル５０４に対応しているか否かを判定する。通信インタフェース４０２は、制御部５０１による認証が失敗した場合に加えてさらに、制御部５０１によって、データがフィルタテーブル５０５および鍵管理テーブル５０４の少なくとも一方に対応していない場合に、データの転送中に、データを無効化する。これにより、データ形式が不一致である不正なデータの送信を防ぎ、さらに認証処理を行うより低負荷で不正なデータの送信を防ぐことが可能となる。

第３実施形態におけるネットワーク装置においては、制御部５０１は、さらに、制御部５０１による認証が行われたことを示すための加工を、データの転送中に、データに対して行う。これにより、認証処理を行うネットワーク装置の動作を、他のネットワーク装置が確認することが可能となる。

認証処理における符号化方式についてストリーム暗号を用いた署名を用いることにより、より高速に判定が可能となり、データの送信期間中に署名の演算を完了させることが容易となる。

１ 制御システム
２ ネットワークシステム
３ 無線通信部
４ ネットワークシステム
５ 有線通信部
６ 出力装置
３０１ ネットワークリンク
３０２ ＥＣＵ
３０３ ＧＷ
３０４ ＳＷ
４０１ プロセッサ
４０２ 通信インタフェース
４０３ タイマ
４０４ ＲＯＭ
４０５ ＲＡＭ
４０６ 内部バス
４０７ セキュリティモジュール
５０１ 制御部
５０２ 通信管理部
５０３ 時間管理部
５０４ 鍵管理テーブル
５０５ フィルタテーブル
５０６ バッファ

Claims (9)

1. 複数のネットワーク装置とバスで接続されたネットワーク装置であって、
   前記バスを介して前記複数のネットワーク装置のうちの１つが送信元装置として送信するデータに含まれるメッセージ認証用情報に基づいて、認証を行う認証部と、
   前記認証が失敗した場合は、前記送信元装置が前記複数のネットワーク装置のうちの他のネットワーク装置になりすまして不正データを送信したと判断し、前記データを無効化する加工部とを備えることを特徴とするネットワーク装置。
2. 請求項１に記載のネットワーク装置において、
   前記加工部は、前記認証が失敗した場合、前記データを、エラーを含むように加工することによって、前記データを無効化することを特徴とするネットワーク装置。
3. 請求項１に記載のネットワーク装置において、
   前記データは、前記認証部による前記認証の結果を示す認証結果情報を含み、
   前記加工部は、前記認証が失敗した場合、上書き不可能な値を前記認証結果情報に設定することによって、前記データを無効化することを特徴とするネットワーク装置。
4. 請求項１に記載のネットワーク装置において、
   前記バスを介して前記データが送信されることが許可されているか否かを管理する第１テーブルと、
   前記データに対する前記認証部による前記認証用の鍵を管理する第２テーブルと、
   前記データの送信中に、前記データが前記第１テーブルおよび前記第２テーブルに対応しているか否かを判定するデータ形式判定部とをさらに備え、
   前記加工部は、前記認証部による前記認証が失敗した場合に加えてさらに、前記データ形式判定部によって、前記データが前記第１テーブルおよび前記第２テーブルの少なくとも一方に対応していない場合に、前記データの送信中に、前記データを無効化することを特徴とするネットワーク装置。
5. 請求項４に記載のネットワーク装置において、
   前記データ形式判定部は、前記データが送信される前記バスのリンクＩＤ、前記データのヘッダの形式、前記データの順序を表すカウンタ、前記データが送信されるタイミングを表すタイムスタンプ、前記鍵の有効期限、前記データが前記認証部による前記認証用の署名付き通信データを伴う場合の通信データ長、および前記データが前記署名付き通信データを伴う場合の署名長、のうちの少なくとも一つに基づいて、前記データが前記第１テーブルおよび前記第２テーブルに対応しているか否かを判定することを特徴とするネットワーク装置。
6. 請求項１に記載のネットワーク装置において、
   前記バスは、前記送信元装置が接続された第１リンクと、前記データが送信される第２リンクとを含み、
   前記加工部は、前記認証部による前記認証が失敗した場合は、前記第１リンクから前記第２リンクに送信中の前記データを無効化することを特徴とするネットワーク装置。
7. 請求項１に記載のネットワーク装置において、
   前記加工部は、さらに、前記認証部による前記認証が行われたことを示すための加工を、前記データの送信中に、前記データに対して行うことを特徴とするネットワーク装置。
8. 請求項１に記載のネットワーク装置において、
   前記加工部は、前記認証が成功した場合は、前記認証部による前記認証が行われていることを示す加工を、前記データに対して行うことを特徴とするネットワーク装置。
9. 請求項１に記載のネットワーク装置と、
   前記送信元装置とを備えることを特徴とするネットワークシステム。

Images