(57)【要約】【課題】好適なメッセージ認証を実現する。【解決手段】車載ネットワークシステム１８は、被検査ＥＣＵ１２と監視ＥＣＵ１４を備える。被検査ＥＣＵ１２は、ハッシュチェーンを構成する第１の検査値を含む第１のフレームをＣＡＮ１６へ送信する。監視ＥＣＵ１４は、ＣＡＮ１６から受信した第１のフレームに含まれる第１の検査値を記憶する。被検査ＥＣＵ１２は、第１のフレームの送信後に、ハッシュチェーンを構成する第２の検査値を含む第２のフレームをＣＡＮ１６へ送信する。監視ＥＣＵ１４は、ＣＡＮ１６から受信した第２のフレームに含まれる第２の検査値と、事前に記憶した第１の検査値とがハッシュチェーンを構成する場合に、被検査ＥＣＵ１２の状態を正常と判定する。【選択図】図１
2018133744.tif 000002
【特許請求の範囲】
【請求項１】
バス型ネットワークに接続された第１の電子機器と、
前記バス型ネットワークに接続された電子機器であって、前記第１の電子機器の状態を監視する第２の電子機器と、
を備え、
前記第１の電子機器は、ハッシュチェーンを構成する第１の検査値を含む第１のフレームを前記バス型ネットワークへ送信する送信部を含み、
前記第２の電子機器は、前記バス型ネットワークから受信した前記第１のフレームに含まれる前記第１の検査値を記憶する記憶部を含み、
前記第１の電子機器の送信部は、前記第１のフレームの送信後に、ハッシュチェーンを構成する第２の検査値を含む第２のフレームを前記バス型ネットワークへ送信し、
前記第２の電子機器は、前記バス型ネットワークから受信した前記第２のフレームに含まれる第２の検査値と、前記記憶部に記憶された第１の検査値とがハッシュチェーンを構成する場合に、前記第１の電子機器の状態を正常と判定する判定部をさらに含む、
通信システム。
【請求項２】
前記第１の電子機器の送信部は、ハッシュチェーンのＮ番目（Ｎは２以上の整数）の値を前記第１の検査値として含む第１のフレームを送信し、ハッシュチェーンのＮ−１番目の値を前記第２の検査値として含む第２のフレームを送信し、
前記第２の電子機器の判定部は、前記第２のフレームに含まれる第２の検査値に基づくハッシュ演算の結果が、前記第１の検査値と一致する場合に、前記第１の電子機器の状態を正常と判定する、
請求項１に記載の通信システム。
【請求項３】
前記第２の電子機器の記憶部は、前記第１の電子機器が送信したフレームのうち第３の電子機器により破棄されるフレームの個数に応じた演算回数をさらに記憶し、
前記第２の電子機器の判定部は、前記第２のフレームに含まれる第２の検査値に基づくハッシュ演算を前記演算回数実行した結果が、前記第１の検査値と一致する場合に、前記第１の電子機器の状態を正常と判定する、
請求項１または２に記載の通信システム。
【請求項４】
前記第１の電子機器の送信部は、メッセージ認証コードをさらに含む第２のフレームを送信し、
前記第２の電子機器の判定部は、前記第２のフレームに含まれる第２の検査値を用いた検証結果と、前記第２のフレームに含まれるメッセージ認証コードを用いた検証結果の両方に基づいて前記第１の電子機器の状態を判定する、
請求項１から３のいずれかに記載の通信システム。
【請求項５】
バス型の車載ネットワークに接続された第１の電子機器と、
前記車載ネットワークに接続された電子機器であって、前記第１の電子機器の状態を監視する第２の電子機器と、
を備え、
前記第１の電子機器は、ハッシュチェーンを構成する第１の検査値を含む第１のフレームを前記車載ネットワークへ送信する送信部を含み、
前記第２の電子機器は、前記車載ネットワークから受信した前記第１のフレームに含まれる前記第１の検査値を記憶する記憶部を含み、
前記第１の電子機器の送信部は、前記第１のフレームの送信後に、ハッシュチェーンを構成する第２の検査値を含む第２のフレームを前記車載ネットワークへ送信し、
前記第２の電子機器は、前記車載ネットワークから受信した前記第２のフレームに含まれる第２の検査値と、前記記憶部に記憶された第１の検査値とがハッシュチェーンを構成する場合に、前記第１の電子機器の状態を正常と判定する判定部をさらに含む、
車両。
【請求項６】
バス型の車載ネットワークに接続された第１の電子機器が、ハッシュチェーンを構成する第１の検査値を含む第１のフレームを前記車載ネットワークへ送信し、
前記車載ネットワークに接続された電子機器であって、前記第１の電子機器の状態を監視する第２の電子機器が、前記車載ネットワークから受信した前記第１のフレームに含まれる前記第１の検査値を記憶部に記憶し、
前記第１の電子機器が、前記第１のフレームの送信後に、ハッシュチェーンを構成する第２の検査値を含む第２のフレームを前記車載ネットワークへ送信し、
前記第２の電子機器が、前記車載ネットワークから受信した前記第２のフレームに含まれる第２の検査値と、前記記憶部に記憶された第１の検査値とがハッシュチェーンを構成する場合に、前記第１の電子機器の状態を正常と判定する、
監視方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理技術に関し、特に通信システム、車両、および監視方法に関する。
【背景技術】
【０００２】
近年、自動車には、多数の電子制御ユニット（Electronic Control Unit、以下「ＥＣＵ」と呼ぶ。）が搭載されている。これらのＥＣＵを繋ぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには多数の規格が存在するが、広く普及した規格としてＣＡＮ（Controller Area Network）がある。
【０００３】
ＣＡＮで送受信されるデータをメッセージ認証コード（MessageAuthenticationCode、以下「ＭＡＣ」と呼ぶ。）により保護するＣＡＮ通信システムが提案されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−４８３７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＭＡＣによるメッセージ認証を行うシステムで、不正なメッセージを送信しているＥＣＵを識別するためには、ＥＣＵのペアごとに異なる鍵を設定する必要があり、鍵の管理コストが高いという課題がある。
【０００６】
本発明はこうした状況に鑑みてなされたものであり、１つの目的は、好適なメッセージ認証を実現する技術を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様の通信システムは、バス型ネットワークに接続された第１の電子機器と、バス型ネットワークに接続された電子機器であって、第１の電子機器の状態を監視する第２の電子機器と、を備える。第１の電子機器は、ハッシュチェーンを構成する第１の検査値を含む第１のフレームをバス型ネットワークへ送信する送信部を含む。第２の電子機器は、バス型ネットワークから受信した第１のフレームに含まれる第１の検査値を記憶する記憶部を含む。第１の電子機器の送信部は、第１のフレームの送信後に、ハッシュチェーンを構成する第２の検査値を含む第２のフレームをバス型ネットワークへ送信し、第２の電子機器は、バス型ネットワークから受信した第２のフレームに含まれる第２の検査値と、記憶部に記憶された第１の検査値とがハッシュチェーンを構成する場合に、第１の電子機器の状態を正常と判定する判定部をさらに含む。
【０００８】
本発明の別の態様は、車両である。この車両は、バス型の車載ネットワークに接続された第１の電子機器と、車載ネットワークに接続された電子機器であって、第１の電子機器の状態を監視する第２の電子機器と、を備える。第１の電子機器は、ハッシュチェーンを構成する第１の検査値を含む第１のフレームを車載ネットワークへ送信する送信部を含む。第２の電子機器は、車載ネットワークから受信した第１のフレームに含まれる第１の検査値を記憶する記憶部を含む。第１の電子機器の送信部は、第１のフレームの送信後に、ハッシュチェーンを構成する第２の検査値を含む第２のフレームを車載ネットワークへ送信し、第２の電子機器は、車載ネットワークから受信した第２のフレームに含まれる第２の検査値と、記憶部に記憶された第１の検査値とがハッシュチェーンを構成する場合に、第１の電子機器の状態を正常と判定する判定部をさらに含む。
【０００９】
本発明のさらに別の態様は、監視方法である。この方法は、バス型の車載ネットワークに接続された第１の電子機器が、ハッシュチェーンを構成する第１の検査値を含む第１のフレームを車載ネットワークへ送信し、車載ネットワークに接続された電子機器であって、第１の電子機器の状態を監視する第２の電子機器が、車載ネットワークから受信した第１のフレームに含まれる第１の検査値を記憶部に記憶し、第１の電子機器が、第１のフレームの送信後に、ハッシュチェーンを構成する第２の検査値を含む第２のフレームを車載ネットワークへ送信し、第２の電子機器が、車載ネットワークから受信した第２のフレームに含まれる第２の検査値と、記憶部に記憶された第１の検査値とがハッシュチェーンを構成する場合に、第１の電子機器の状態を正常と判定する。
【００１０】
なお、以上の構成要素の任意の組合せ、本発明の表現を、装置、コンピュータプログラム、コンピュータプログラムを記録した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１１】
本発明によれば、好適なメッセージ認証を実現することができる。
【図面の簡単な説明】
【００１２】
【図１】実施例の車両の構成を示す図である。
【図２】図１の被検査ＥＣＵの機能構成を示すブロック図である。
【図３】認証子生成の過程を示す図である。
【図４】コミットメント記憶部に記憶されるデータを模式的に示す図である。
【図５】図５（ａ）−（ｅ）は、被検査ＥＣＵから出力されるフレームの例を示す図である。
【図６】図１の監視ＥＣＵの機能構成を示すブロック図である。
【図７】コミットメント管理表を示す図である。
【図８】被検査ＥＣＵの動作を示すフローチャートである。
【図９】監視ＥＣＵの動作を示すフローチャートである。
【図１０】被検査ＥＣＵと監視ＥＣＵの相互作用を示すシーケンス図である。
【図１１】変形例１の被検査ＥＣＵから出力される通常フレームの例を示す図である。
【図１２】図１３（ａ）−（ｃ）は、変形例１の監視ＥＣＵによるログの出力例を示す図である。
【図１３】変形例２における認証子生成の過程を示す図である。
【図１４】変形例３におけるコミットメント管理表を示す図である。
【図１５】コミットメント管理表の自動生成処理を示すフローチャートである。
【図１６】ハッシュチェーンの二重化を説明する図である
【発明を実施するための形態】
【００１３】
実施例の構成を説明する前に概要を説明する。上記特許文献１に記載されたＭＡＣを用いたメッセージ認証は、ＥＣＵのペアごとに異なる鍵を設定しなければ、不正なメッセージを送信しているＥＣＵを識別できないという課題がある。また、ＭＡＣを用いたメッセージ認証は比較的軽量であるが、鍵のメンテナンスコストが高いという課題もある。
【００１４】
また、特開２０１４−１４６８６８号公報では、ネットワークを流れるメッセージの周期情報を監視して、不正なメッセージの存在を検出するネットワーク装置が提案されている。しかし、周期情報だけの監視では、正当なメッセージと不正なメッセージを区別して、不正なメッセージを正確に特定することは困難である。
【００１５】
そこで、実施例の監視ＥＣＵは、監視対象である被検査ＥＣＵが送信するメッセージの正当性を、ハッシュチェーンに基づいて認証する。これにより、鍵情報を利用することなく、正常なメッセージと異常なメッセージを高い精度で識別可能にする。
【００１６】
図１は、実施例の車両１０の構成を示す。車両１０は、被検査ＥＣＵ１２ａ、被検査ＥＣＵ１２ｂ、被検査ＥＣＵ１２ｃ、被検査ＥＣＵ１２ｄ（総称する場合「被検査ＥＣＵ１２」と呼ぶ。）、監視ＥＣＵ１４、ＣＧＷ（Central GateWay）１７を備える。図１の各装置は、バス型の車載ネットワークであるＣＡＮ１６を介して接続され、車載ネットワークシステム１８を構成する。
【００１７】
被検査ＥＣＵ１２は、正常性が検査されるＥＣＵである。複数の被検査ＥＣＵ１２は、例えば、エンジンＥＣＵ、ブレーキＥＣＵ、ステアリングＥＣＵ、トランスミッションＥＣＵであってもよい。被検査ＥＣＵ１２のそれぞれは、不図示のセンサに接続され、センサによる検知情報を含むメッセージ（「フレーム」または「パケット」とも言え、以下「フレーム」と呼ぶ。）をＣＡＮ１６のバスへ出力する。または、被検査ＥＣＵ１２のそれぞれは、不図示のアクチュエータに接続され、アクチュエータの制御に関する情報を含むフレームをＣＡＮ１６のバスへ出力する。被検査ＥＣＵ１２の機能の詳細は後述する。
【００１８】
監視ＥＣＵ１４は、所定の監視規則に基づいて、ＣＡＮ１６のバスを流れるフレームの正常性を監視することにより、複数の被検査ＥＣＵ１２それぞれの正常性（言い換えれば正当性）を監視する。監視ＥＣＵ１４は、専用機器として実装されてもよい。また、既存のＥＣＵ（例えば、ＣＧＷのＥＣＵ）に、監視ＥＣＵ１４の機能を含む監視モジュールが組み込まれてもよい。監視ＥＣＵ２６の機能の詳細は後述する。
【００１９】
実施例では、被検査ＥＣＵ１２は、ＣＡＮ１６の第１のバスに接続され、監視ＥＣＵ１４は、ＣＡＮ１６の第２のバスに接続される。ＣＧＷ１７は、第１のバスと第２のバスを含む複数のバス間でフレームを中継する。ＣＧＷ１７は、トラヒック調整のために、所定ＩＤのフレームを所定割合で除去してもよい。例えば、ＣＧＷ１７は、第１のバスにおいて５０ミリ秒周期で流れるフレームを、２回に１回、第２のバスへ中継してもよい。言い換えれば、２回に１回、中継せずに破棄することにより、第２のバスにおいて当該フレームの周期が１００ミリ秒になるようにトラヒックを調整してもよい。なお、第１のバスと第２のバスに分かれていることは必須ではなく、被検査ＥＣＵ１２と監視ＥＣＵ１４は、同一のバスに接続されてもよい。
【００２０】
図２は、図１の被検査ＥＣＵ１２の機能構成を示すブロック図である。被検査ＥＣＵ１２は、通信部２０、乱数生成部２２、認証子生成部２４、コミットメント記憶部２６、フレーム生成部２８を備える。
【００２１】
本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵ・メモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図２の各ブロックに対応するモジュールを含むコンピュータプログラムが、被検査ＥＣＵ１２のメモリに格納されてもよい。被検査ＥＣＵ１２のＣＰＵは、そのコンピュータプログラムを適宜実行することにより、各ブロックの機能を発揮してもよい。図６に関連して後述する監視ＥＣＵ１４も同様である。
【００２２】
通信部２０は、ＣＡＮプロトコルにしたがって、ＣＡＮ１６のバスからフレームを受信する。また、通信部２０は、フレーム生成部２８により生成されたフレームをＣＡＮ１６のバスへ出力する。
【００２３】
乱数生成部２２は、ハッシュチェーンの元データとなる乱数列を生成する。乱数生成部２２は、ハードウェア乱数生成器を用いて乱数列を生成してもよい。また、乱数生成部２２は、ソフトウェアの計算による擬似乱数列を生成してもよい。乱数生成部２２は、乱数のシードをストレージに保存しておくことで精度を確保できる。また、乱数生成部２２は、複数の乱数列を個別に生成し、それら複数の乱数列に基づいて新たな乱数列を生成してもよい。これによりエントロピーを増加させることができる。
【００２４】
認証子生成部２４は、通信部２０により受信されたフレームが、コミットメント要求フレームである場合（コミットメント要求フレームのＩＤが付与されたフレームである場合）、乱数生成部２２により生成された乱数列に基づいて、ハッシュチェーン認証のための認証子を生成する。また、認証子生成部２４は、コミットメントの更新タイミングに達した場合、乱数生成部２２により生成された新たな乱数列に基づいて新たな認証子を生成する。認証子生成部２４は、生成した認証子のデータをコミットメント記憶部２６へ格納する。
【００２５】
図３は、認証子生成の過程を示す。まず、認証子生成部２４は、時間値（Ｔｉｍｅ）、ＩＤ、乱数列を結合したデータを予め定められたハッシュ関数へ入力して、ハッシュ関数から出力されたハッシュ値１を取得する。認証子生成部２４は、予め定められた規則に基づいてハッシュ値１を切り詰める（truncate）ことにより、認証子１を取得する。
【００２６】
図３の時間値として、認証子生成部２４は、コミットメントの登録が監視ＥＣＵ１４から要求された場合、監視ＥＣＵ１４から通知された時間値を使用する。その一方、自発的にコミットメントを更新する場合、認証子生成部２４は、現在時刻を示す時間値を被検査ＥＣＵ１２のＯＳ（Operating System）等から取得して使用する。なお、認証子生成のパラメータとして時間値を用いる理由は、再送攻撃を防止するためである。したがって、カウンタ値が変動する（例えば増加する）特性のあるデータであれば、時間値以外のデータを用いることができる。また、図３のＩＤとして、認証子生成部２４は、検査対象となる通常フレームに設定されるフレームＩＤ（メッセージＩＤとも言える）を使用する。また、切り詰めの規則は、ハッシュ値の上位または下位のＮビット（例えば８ビット、１２ビット、１６ビット等）を抽出することでもよい。
【００２７】
続いて、認証子生成部２４は、ハッシュ値１生成時と同じ時間値とＩＤに認証子１を結合したデータを上記ハッシュ関数へ入力してハッシュ値２を取得する。認証子生成部２４は、上記規則に基づいてハッシュ値２を切り詰めて認証子２を取得する。実施例では、乱数または認証子にＩＤと時間値を合成して、その合成データのハッシュ値を取得し、そのハッシュ値を切り詰めて次の段階の認証子を得ることが１回のハッシュ演算となる。認証子生成部２４は、ハッシュ演算を所定回数（例えば９９９回）繰り返してハッシュチェーンを構築し、その中で複数の認証子（例えば認証子１、認証子２、・・・、認証子９９９）を生成する。
【００２８】
なお、複数の被検査ＥＣＵ１２間で途中のハッシュ値が同一になる可能性がある。しかし、各回のハッシュ演算においてパラメータの１つにＩＤを含むため、一旦ハッシュ値が同一になっても、以降のハッシュ値は高い確率で異なるものになる。なお、変形例として、図３における時間値およびＩＤの部分は、被検査ＥＣＵ１２と監視ＥＣＵ１４間で予め定められた固定のパディング文字列であってもよい。
【００２９】
図２に戻り、コミットメント記憶部２６は、認証子生成部２４により生成された認証子を記憶する。図４は、コミットメント記憶部２６に記憶されるデータを模式的に示す。コミットメント記憶部２６は、認証子生成部２４による複数回のハッシュ演算により生成された複数の認証子を記憶し、すなわち、認証子（０）〜認証子（９９９）を記憶する。図４の認証子（０）は、乱数生成部２２により生成された乱数列である。また、図４の認証子（９９９）は、９９９回のハッシュ演算を経て、最後に生成された認証子であり、コミットメントとして監視ＥＣＵ１４に登録される。
【００３０】
まず、フレーム生成部２８は、コミットメント記憶部２６に記憶されたコミットメント（図４では認証子（９９９））のデータを含むコミットメント登録フレームを生成する。フレーム生成部２８は、コミットメント登録フレームを通信部２０へ出力し、通信部２０は、コミットメント登録フレームを監視ＥＣＵ１４へ送信する。
【００３１】
続いて、フレーム生成部２８は、コミットメント記憶部２６に記憶された認証子のうち、使用済みの認証子の識別情報（位置等）を記憶する。使用済みの認証子は、例えば、コミットメント登録フレームまたは通常フレームに設定済の認証子である。変形例として、フレーム生成部２８は、未使用の認証子の識別情報を記憶してもよい。未使用の認証子は、例えば、フレームに未設定の認証子である。実施例では、フレーム生成部２８は、最後に使用した認証子の識別情報（ここではＮとする。）を記憶する。
【００３２】
フレーム生成部２８は、外部機器（他のＥＣＵ等）へ渡すべきデータ、例えば、センサの検知情報またはアクチュエータの制御情報等が発生すると、そのデータを含むフレーム（以下、「通常フレーム」とも呼ぶ。）を生成する。フレーム生成部２８は、通常フレームに、認証子（Ｎ−１）を設定する。認証子（Ｎ−１）は、未使用の認証子のうち最後に使用した認証子（認証子（Ｎ））に隣接する認証子である。フレーム生成部２８は、生成した通常フレームを通信部２０へ出力し、通信部２０は、通常フレームをＣＡＮ１６へブロードキャスト送信する。
【００３３】
図５（ａ）−（ｅ）は、被検査ＥＣＵ１２から出力されるフレームの例を示す。ここでは、被検査ＥＣＵ１２は、認証子（０）〜認証子（９９９）を生成し、そのうち認証子（１０）まで使用すると、新たなハッシュチェーンに基づくコミットメントを監視ＥＣＵ１４へ再登録する。
【００３４】
図５（ａ）は、コミットメント登録フレームを示す。コミットメント登録フレームは、登録するコミットメントを用いて検査すべきフレームのフレームＩＤ、時間値、それまでのハッシュチェーンによる認証子（旧認証子（９））、および、新たなハッシュチェーンによる認証子（認証子（９９９））を含む。なお、初回のコミットメント登録時は、それまでのハッシュチェーンによる認証子の欄には、デフォルト値（例えば「００００・・・」）を設定する。
【００３５】
図５（ｂ）、（ｃ）、（ｄ）は、通常フレームを示す。通常フレームは、当該フレームのフレームＩＤ、認証子、メッセージ本文（単に「データ」と表記）を含む。図５（ｂ）は、コミットメント登録フレームの次に送信される通常フレームを示しており、認証子（９９８）を含む。図５（ｃ）は、図５（ｂ）の通常フレームの次に送信される通常フレームを示しており、認証子（９９７）を含む。図５（ｄ）は、９９０番目に送信される通常フレームを示しており、認証子（１０）を含む。
【００３６】
図５（ｅ）は、コミットメント登録フレームを示す。このコミットメント登録フレームは、図５（ｄ）の通常フレームの次に送信され、新たなハッシュチェーンに基づく新たなコミットメント（新認証子（９９９））を登録するためのフレームである。また、図５（ｅ）のコミットメント登録フレームは、図５（ａ）と同じＩＤ、図５（ａ）とは異なる時間値、旧認証子（Ｎ−１）である旧認証子（９）を含む。
【００３７】
図６は、図１の監視ＥＣＵ１４の機能構成を示すブロック図である。監視ＥＣＵ１４は、通信部３０、コミットメント登録部３２、コミットメント記憶部３４、監視部３６、異常処理部４２を備える。監視部３６は、判定部３８とコミットメント更新部４０を含む。
【００３８】
通信部２０は、ＣＡＮプロトコルにしたがって、ＣＡＮ１６のバスからフレームを受信する。また、通信部３０は、監視ＥＣＵ１４にて生成されたフレームをＣＡＮ１６のバスへ出力する。
【００３９】
コミットメント登録部３２は、監視ＥＣＵ１４の電源がオンに切り替わった等、所定の条件が満たされた場合に、コミットメントの登録を要求するフレームであるコミットメント要求フレームを生成する。コミットメント登録部３２は、コミットメント要求フレームを通信部３０へ出力し、通信部３０は、コミットメント要求フレームをＣＡＮ１６へブロードキャスト送信する。
【００４０】
また、コミットメント登録部３２は、通信部３０により受信されたフレームが、コミットメント登録フレームである場合（コミットメント登録フレームのＩＤが付与されたフレームである場合）、コミットメント登録フレームに含まれるデータ（例えば認証子（９９９）等）をコミットメント記憶部３４へ保存する。
【００４１】
コミットメント記憶部３４は、コミットメント管理表を記憶する。図７は、コミットメント管理表を示す。コミットメント管理表は、テーブルであってもよく、複数のパラメータとして、フレームＩＤ、ＥＣＵ−ＩＤ、周期、演算回数、タイムスタンプ、ビット長、コミットメント、認証アルゴリズムを含む。フレームＩＤは、検査対象となる通常フレームのＩＤ（メッセージＩＤ）を示す。ＥＣＵ−ＩＤは、通常フレームの送信元である被検査ＥＣＵ１２のＩＤを示す。周期は、振る舞い検知のためのパラメータであり、フレームの受信周期を示す。演算回数は、ハッシュチェーン認証時におけるハッシュ演算の回数を示す。
【００４２】
タイムスタンプは、コミットメント登録フレームを用いた再送攻撃への対策のためのパラメータである。ビット長は、コミットメントのビット長を示す。認証アルゴリズムは、通常フレームを認証するためのアルゴリズムを示す。認証アルゴリズムは、例えば、バックワードハッシュ、フォワードハッシュ、ＭＡＣの単体または組み合わせを含む。複数の被検査ＥＣＵ１２の計算リソース量は様々であり、計算リソース量に応じた認証アルゴリズムを適用することができる。また、後述するように、ハッシュチェーン認証とＭＡＣ認証とを組み合わせることで、被検査ＥＣＵ１２の異常の態様を詳細に把握することができる。
【００４３】
コミットメント管理表のパラメータのうちフレームＩＤ、ＥＣＵ−ＩＤ、周期、演算回数、認証アルゴリズムは、車両１０の製造時に予め設定される。また、これらのパラメータ値が設定されたコミットメント管理表が、クラウド上のサーバから車両１０へ提供されてもよい。サーバから提供されるコミットメント管理表には、製造者による電子署名が付与され、認証に成功した管理表のみを受け入れる形態とすることが望ましい。コミットメント登録部３２は、コミットメント登録フレームに設定された通常フレームのフレームＩＤに対応するコミットメント管理表のレコード（以下「対応規則」と呼ぶ。）を特定し、対応規則のタイムスタンプ欄に、コミットメント登録フレームに含まれる時間値を設定する。また、コミットメント登録部３２は、対応規則のコミットメント欄に、コミットメント登録フレームに含まれるコミットメント値（例えば認証子（９９９））を設定するとともに、コミットメントの長さをビット長欄に設定する。
【００４４】
コミットメント登録部３２は、コミットメント登録フレームに含まれる時間値が、コミットメント管理表における対応規則のタイムスタンプより古いまたは同じである場合、再送攻撃と判定して、そのコミットメント登録フレームを破棄する。すなわち、コミットメント登録部３２は、コミットメント登録フレームの内容を対応規則へ反映させることを抑制する。
【００４５】
また、コミットメント登録部３２は、コミットメント登録フレームに含まれる旧認証子の値（例えば図５（ａ）の旧認証子（９））に基づくハッシュ演算の結果が、対応規則のコミットメント値（更新前の値）に一致する場合に、コミットメント登録フレームの内容を対応規則へ反映させる。すなわち、コミットメント登録部３２は、当該コミットメント登録フレームに含まれるコミットメント値を、対応規則の新たなコミットメント値として保存する。これにより、コミットメント値の不正な更新を防止する。
【００４６】
図６に戻り、監視部３６は、コミットメント記憶部３４に記憶されたコミットメント管理表に基づいて、通信部３０により受信されたフレームの正当性を監視する。具体的には、判定部３８は、受信されたフレームのＩＤがコミットメント記憶部３４のコミットメント管理表に記録されている場合、受信されたフレームを検査対象フレームとして識別し、検査対象フレームが示すフレームＩＤに一致するコミットメント管理表のレコードを対応規則として識別する。判定部３８は、検査対象フレームに含まれる認証子と、対応規則のコミットメント値とがハッシュチェーンを構成するか否かを確認する。両者がハッシュチェーンを構成する場合、判定部３８は、当該検査対象フレームを正常と判定し、また、当該フレームの送信元である被検査ＥＣＵ１２の状態を正常と判定する。
【００４７】
バックワードハッシュによる認証を説明する。バックワードハッシュの場合、ハッシュチェーンにおけるＮ番目（Ｎは２以上の整数）の認証子がコミットメント値としてコミットメント管理表に予め記録され、上記ハッシュチェーンにおけるＮ−１番目の認証子が検査対象フレームで指定される。判定部３８は、検査対象フレームに含まれる認証子と、対応規則におけるフレームＩＤおよびタイムスタンプの合成データをハッシュ関数へ入力してハッシュ値を取得する。判定部３８は、所定の切り詰め規則にしたがってハッシュ値を切り詰めた値を検証値として取得する。なお、ハッシュ関数および切り詰め規則は、被検査ＥＣＵ１２と監視ＥＣＵ１４間で共通である。
【００４８】
すなわち、判定部３８は、検査対象フレームに含まれる認証子（認証子（α）とする）に基づいて、認証子（α＋1）を検証値として生成する。検査対象フレームの送信元が正当な被検査ＥＣＵ１２であれば、検証値は、コミットメント管理表に予め記録されたコミットメント値と一致する。そこで、判定部３８は、検証値が対応規則のコミットメント値と一致する場合に、検査対象フレームを正常と判定し、また、検査対象フレームの送信元である被検査ＥＣＵ１２の状態を正常と判定する。言い換えれば、判定部３８は、検証値が対応規則のコミットメント値と不一致である場合、検査対象フレームを異常と判定し、また、検査対象フレームの送信元である被検査ＥＣＵ１２の状態を異常と判定する。
【００４９】
次に、フォワードハッシュによる認証を説明する。フォワードハッシュの場合、ハッシュチェーンにおけるＮ番目（Ｍは１以上の整数）の認証子がコミットメント値としてコミットメント管理表に予め記録され、上記ハッシュチェーンにおけるＮ＋１番目の認証子が検査対象フレームで指定される。判定部３８は、対応規則におけるフレームＩＤ、タイムスタンプ、コミットメント値の合成データをハッシュ関数へ入力してハッシュ値を取得する。判定部３８は、所定の切り詰め規則にしたがってハッシュ値を切り詰めた値を検証値として取得する。
【００５０】
すなわち、判定部３８は、予め記録されたコミットメント値である認証子（α）に基づいて、認証子（α＋1）を検証値として生成する。判定部３８は、検証値が検査対象フレームに含まれる認証子と一致する場合に、検査対象フレームを正常と判定し、また、検査対象フレームの送信元である被検査ＥＣＵ１２の状態を正常と判定する。フォワードハッシュは、バックワードハッシュと比較するとセキュリティの強度は低いが、被検査ＥＣＵ１２における計算量は少なくなるため、被検査ＥＣＵ１２の計算リソースが寡少である場合に好適である。例えば、正当な被検査ＥＣＵ１２ａが、監視ＥＣＵ１４へコミットメントを登録し、それにしたがってフォワードハッシュのチェーンを監視ＥＣＵ１４へ送り続けることとする。この場合、不正な被検査ＥＣＵ１２ｂが被検査ＥＣＵ１２ａになりすましてフレームを送信しても、監視ＥＣＵ１４は、同じチェーンで２つのＥＣＵが送信し続けていることがわかるので、不正の発生を検出することができる。なお、ハッシュチェーン認証とＭＡＣ認証との組み合わせは変形例にて後述する。
【００５１】
また、判定部３８は、コミットメント管理表に定められた複数のフレームＩＤのそれぞれについて、各フレームＩＤが付与されたフレームの受信周期を計測する。判定部３８は、振る舞い検知として、計測した受信周期とコミットメント管理表の周期との差が所定範囲を超過したフレームを異常と判定し、また、当該フレームの送信元である被検査ＥＣＵ１２の状態を異常と判定する。この振る舞い検知により、ＥＣＵの乗っ取りを検出することができる。
【００５２】
コミットメント管理表における演算回数には、被検査ＥＣＵ１２が送信したフレームのうちＣＧＷ１７により破棄されるフレームの個数（例えば、ＣＡＮ１６のバス間で中継されないフレームの割合）に応じた回数が設定される。例えば、図７のコミットメント管理表において、ＩＤ「１０」「４０」「５０」のフレームはＣＧＷ１７により破棄されないため、演算回数１回（すなわち繰り返し無し）が設定されている。その一方、ＩＤ「２０」のフレームはＣＧＷ１７により２回に１回破棄される（言い換えれば５０％が破棄される）ため、演算回数２回が設定されている。
【００５３】
判定部３８は、バックワードハッシュの場合、検査対象フレームに含まれる認証子に基づくハッシュ演算を、対応規則が定める演算回数実行した結果が、対応規則が定めるコミットメント値と一致する場合に、検査対象フレームの送信元である被検査ＥＣＵ１２の状態を正常と判定する。その一方、フォワードハッシュの場合、判定部３８は、対応規則のコミットメント値に基づくハッシュ演算を、対応規則が定める演算回数実行した結果が、検査対象フレームが含む認証子と一致する場合に、検査対象フレームの送信元である被検査ＥＣＵ１２の状態を正常と判定する。
【００５４】
図７のコミットメント管理表の例では、判定部３８は、ＩＤ「２０」のフレームに含まれる認証子に基づくハッシュ演算を２回繰り返し実行した結果を検証値として取得する。判定部３８は、その検証値がコミットメント値と一致する場合に、ＩＤ「２０」のフレームの送信元である被検査ＥＣＵ１２（ＥＣＵ−２）の状態を正常と判定する。これにより、ＣＧＷ１７が、フレームの削除、言い換えれば、帯域削減を行う場合も、監視ＥＣＵ１４は、フレームの正常性、言い換えれば、フレーム送信元の被検査ＥＣＵ１２の正常性を精度よく判定することができる。
【００５５】
なお、判定部３８は、検査対象フレームに含まれる認証子に基づくハッシュ演算を、対応規則が定める演算回数（ここではＸ回とする）実行した結果が、対応規則が定めるコミットメント値と不一致である場合、判定部３８は、ハッシュ演算を繰り返し実行し、各回のハッシュ演算の結果とコミットメント値を照合してもよい。また、ハッシュ演算のリトライ回数が予め定められ、フレーム生成部２８は、そのリトライ回数を上限として、ハッシュ演算を繰り返してもよい。判定部３８は、或る回数（ここではＹ回とする）繰り返したハッシュ演算の結果とコミットメント値が一致する場合、（Ｙ−Ｘ）個のフレームがＣＡＮ１６で伝送エラーになったことを検出してもよい。
【００５６】
例えば、図７のＩＤ「１０」のフレームについて、ハッシュ演算を３回繰り返した結果がコミットメント値と一致する場合、判定部３８は、ＩＤ「１０」のフレームが２個ロスしたと判定してもよい。また、図７のＩＤ「２０」のフレームについて、ハッシュ演算を３回繰り返した結果がコミットメント値と一致する場合、判定部３８は、ＩＤ「２０」のフレームが１個ロスしたと判定してもよい。この態様によると、ＣＧＷ１７によるフレームの削除と、伝送エラーによるフレームのロスとを区別して検出することができる。
【００５７】
コミットメント更新部４０は、検査対象フレームが正常か否かを判定部３８が判定した後に、検査対象フレームに含まれる認証子を新たなコミットメント値として対応規則のコミットメント欄に記録する。
【００５８】
判定部３８は、異常と判定したフレームＩＤおよび／またはＥＣＵ−ＩＤ、異常の内容等を含む判定結果を異常処理部４２へ出力する。異常処理部４２は、判定部３８による判定結果に応じた後処理を実行する。
【００５９】
例えば、異常処理部４２は、判定部３８による判定結果を示す情報を所定のログファイルへ記録してもよい。また、異常処理部４２は、判定部３８による判定結果を示す情報を、車両１０の表示部（カーナビゲーション装置またはダッシュボードのランプ等）に表示させてもよい。また、異常処理部４２は、判定部３８による判定結果を示す情報を、クラウド上のサーバ等、所定の外部装置へ送信してもよい。判定部３８による判定結果を示す情報は、特定のＩＤのフレームが正常か否かを示す情報を含んでもよく、および／または、特定のＩＤのＥＣＵが正常か否かを示す情報を含んでもよい。また、周期に基づく振る舞い検知の結果を含んでもよく、再送攻撃の検知有無を含んでもよい。
【００６０】
以上の構成による車載ネットワークシステム１８の動作を説明する。
図８は、被検査ＥＣＵ１２の動作を示すフローチャートである。被検査ＥＣＵ１２は、コミットメントの更新タイミングに達したことを検出すると（Ｓ１０のＹ）、コミットメントの新規生成および登録の処理を実行する。コミットメントの更新タイミングは、実施例では、（１）監視ＥＣＵ１４からのコミットメント要求フレームを受信したとき、（２）それまでのハッシュチェーンに基づく認証子が所定個数使用されたとき（例えば認証子（９９９）から認証子（１０）まで使用された場合）である。変形例として、電源がオフからオンに切り替わったとき等、他の事象を契機としてコミットメントの新規生成および登録の処理を実行してもよい。
【００６１】
乱数生成部２２は乱数を生成し、認証子生成部２４はカウンタＣを最大値Ｘ（ここでは「９９９」とする）に設定する（Ｓ１２）。認証子生成部２４は、乱数をもとにハッシュ演算をＣ回繰り返して、認証子（１）〜認証子（９９９）を順次生成し、これらの認証子をコミットメント記憶部２６へ保存する（Ｓ１４）。フレーム生成部２８は、認証子（９９９）をコミットメント値として設定したコミットメント登録フレームを生成し、通信部２０は、コミットメント登録フレームをＣＡＮ１６へ出力して、監視ＥＣＵ１４へ送信する（Ｓ１６）。フレーム生成部２８は、カウンタＣをデクリメントする（Ｓ１８）。コミットメント登録フレーム送信直後のカウンタＣは「９９８」となる。コミットメント更新タイミングでなければ（Ｓ１０のＮ）、Ｓ１２〜Ｓ１８をスキップする。
【００６２】
外部装置（他のＥＣＵ等）へ送信すべきデータが発生すると（Ｓ２０のＹ）、フレーム生成部２８は、コミットメント記憶部２６から認証子（Ｃ）（例えば認証子（９９８））を取得する（Ｓ２２）。フレーム生成部２８は、認証子（Ｃ）を設定した通常フレームを生成し、通信部２０は、その通常フレームをＣＡＮ１６へブロードキャストする（Ｓ２４）。フレーム生成部２８は、カウンタＣをデクリメントする（Ｓ２６）。カウンタＣが所定の閾値（例えば「９」）以下になった場合（Ｓ２８のＹ）、Ｓ１２に戻り、コミットメントの新規生成および再登録の処理を実行する。カウンタＣが閾値より大きく（Ｓ２８のＮ）、かつ、送信すべきデータが残っていれば（Ｓ３０のＹ）、Ｓ２２に戻る。データの送信が完了すれば（Ｓ３０のＮ）、本図のフローを終了する。外部装置へ送信すべきデータがなければ（Ｓ２０のＮ）、Ｓ２２〜Ｓ３０をスキップする。なお、図８のフローは、被検査ＥＣＵ１２の起動中に繰り返し実行される。
【００６３】
図９は、監視ＥＣＵ１４の動作を示すフローチャートである。電源がオフからオンに切り替わった等、コミットメント要求のタイミングに達すると（Ｓ４０のＹ）、コミットメント登録部３２は、コミットメント要求フレームを生成し、通信部３０は、コミットメント要求フレームをＣＡＮ１６へ出力して、被検査ＥＣＵ１２へ送信する（Ｓ４２）。コミットメント要求のタイミングでなければ（Ｓ４０のＮ）、Ｓ４２をスキップする。通信部２０がフレームを受信し（Ｓ４４のＹ）、受信されたフレームがコミットメント登録フレームであれば（Ｓ４６のＹ）、コミットメント登録部３２は、当該フレームで指定されたコミットメント値を、当該フレームで指定された通常フレームのＩＤに対応づけてコミットメント記憶部３４に保存する（Ｓ４８）。
【００６４】
受信されたフレームがコミットメント登録フレームでなく（Ｓ４６のＮ）、コミットメント管理表にＩＤが登録された検査対象フレームであれば（Ｓ５０のＹ）、判定部３８は、検査対象フレームに含まれる認証子（ここでは認証子Ａとする）を取得する（Ｓ５２）。判定部３８は、認証子Ａに基づくハッシュ演算の結果（ここでは検証値Ａ’とする）を取得する（Ｓ５４）。判定部３８は、対応規則が定めるコミットメント値と検証値Ａ’を比較することにより、検証値Ａ’の正当性を検証する（Ｓ５６）。検証値Ａ’が正しい場合、すなわち、検証値Ａ’がコミットメント値に一致する場合（Ｓ５８のＹ）、判定部３８は、検査対象フレームが正常であり、すなわち、送信元の被検査ＥＣＵ１２の状態が正常と判定する。判定部３８は、対応規則の新たなコミットメント値として検証値Ａ’を保存する（Ｓ６０）。
【００６５】
検証値Ａ’が不正の場合、すなわち、検証値Ａ’がコミットメント値に不一致の場合（Ｓ５８のＮ）、判定部３８は、検査対象フレームが異常であり、すなわち、送信元の被検査ＥＣＵ１２の状態が異常と判定する。異常処理部４２は、被検査ＥＣＵ１２の状態が異常である場合の異常時処理（例えばログ出力等）を実行する（Ｓ６２）。受信したフレームが検査対象フレームでなければ（Ｓ５０のＮ）、Ｓ５２〜Ｓ６２をスキップし、ＣＡＮ１６からフレームを未受信であれば（Ｓ４４のＮ）、Ｓ４６〜Ｓ６２をスキップする。電源がオンからオフに切り替わった等、所定の終了条件が満たされると（Ｓ６４のＹ）、監視ＥＣＵ１４はＣＡＮ１６の監視処理を終了し（Ｓ６６）、本図のフローを終了する。終了条件が満たされなければ（Ｓ６４のＮ）、Ｓ４０に戻る。
【００６６】
図１０は、被検査ＥＣＵ１２と監視ＥＣＵ１４の相互作用を示すシーケンス図である。監視ＥＣＵ１４は、ＣＡＮ１６のバスの監視を開始し（Ｓ１００）、現在時刻を示す時間値を含むコミットメント要求フレームを被検査ＥＣＵ１２へ送信する（Ｓ１０２）。被検査ＥＣＵ１２は、サーバから通知された時間値と、動的に生成した乱数に基づいて、コミットメント１（認証子（９９９））を生成する（Ｓ１０４）。被検査ＥＣＵ１２は、コミットメント１を含むコミットメント登録フレームをＣＡＮ１６へブロードキャストすることにより監視ＥＣＵ１４へ送信する（Ｓ１０６）。監視ＥＣＵ１４は、被検査ＥＣＵ１２が送信する通常フレームのＩＤに対応づけてコミットメント１を記憶する（Ｓ１０８）。
【００６７】
被検査ＥＣＵ１２は、外部装置へ送信すべきメッセージと認証子（９９８）を含む通常フレームをＣＡＮ１６へブロードキャストする（Ｓ１１０）。監視ＥＣＵ１４は、ブロードキャストされた上記通常フレームを検査対象フレームとして受信する。監視ＥＣＵ１４は、認証子（９９８）を検証することにより検査対象フレームの正常性を確認し（Ｓ１１２）、正常であれば、コミットメント１の値を認証子（９９８）に更新する（Ｓ１１４）。続いて、被検査ＥＣＵ１２は、外部装置へ送信すべきメッセージと認証子（９９７）を含む通常フレームをＣＡＮ１６へブロードキャストする（Ｓ１１６）。監視ＥＣＵ１４は、ブロードキャストされた上記通常フレームを検査対象フレームとして受信する。監視ＥＣＵ１４は、認証子（９９７）を検証することにより検査対象フレームの正常性を確認し（Ｓ１１８）、正常であれば、コミットメント１の値を認証子（９９７）に更新する（Ｓ１２０）。
【００６８】
以降、被検査ＥＣＵ１２は、コミットメント更新タイミングに達するまで、認証子（９９６）〜認証子（１０）を順次使用して、通常フレームをブロードキャストし、監視ＥＣＵ１４は、それぞれの認証子を検証する。被検査ＥＣＵ１２は、認証子（１０）を使用した場合、コミットメント更新タイミングに達したことを検出し、新たなハッシュチェーンに基づく新たなコミットメント２（認証子（９９９））を生成する（Ｓ１２２）。被検査ＥＣＵ１２は、コミットメント２を含むコミットメント登録フレームをＣＡＮ１６へブロードキャストすることにより監視ＥＣＵ１４へ送信する（Ｓ１２４）。監視ＥＣＵ１４は、被検査ＥＣＵ１２が送信する通常フレームのＩＤに対応づけてコミットメント２を記憶する（Ｓ１２６）。
【００６９】
実施例の車載ネットワークシステム１８では、被検査ＥＣＵ１２から送信されるフレームの正当性を、監視ＥＣＵ１４がハッシュチェーンに基づいて検証する。これにより、鍵情報を利用することなく、ＣＡＮ１６を流れるフレームが正常なフレームか、異常なフレームかを高い精度で識別することができる。
【００７０】
ハッシュ関数は一方向関数であり、逆方向の計算にはブルートフォース攻撃が必要になる。仮に監視ＥＣＵ１４に登録されたコミットメント（ここでは認証子（Ｎ）とする）を不正者が取得しても、その不正者が認証子（Ｎ−１）を得ることは非常に困難である。したがって、検査対象フレームに含まれる認証子（Ｎ−１）の検証に成功した場合、その検査対象フレームは正当な被検査ＥＣＵ１２から送信されたことが保証される。
【００７１】
また、攻撃者は、コミットメント（認証子（Ｎ））に対する正しい入力値（認証子（Ｎ−１））を知らないため、攻撃者により乗っ取られたＥＣＵが被検査ＥＣＵ１２になりすましても、ハッシュチェーン認証がＮＧとなってなりすましを検知できる。また、攻撃者がコミットメントを偽造しても、監視ＥＣＵ１４は、同じＩＤに対するコミットメント登録フレームを２重に受け付けることになり、偽造を検知できる。
【００７２】
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素あるいは各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００７３】
（変形例１）
変形例１では、ハッシュチェーン認証とＭＡＣ認証とを併用する。通常のＭＡＣ認証では、所定のＩＶ（Initial Value：初期値）、ＭＡＣ用の共通鍵、データ（メッセージ本文）の合成値をＭＡＣ用のハッシュ関数へ入力し、そのハッシュ関数から出力されたハッシュ値をＭＡＣとして使用する。変形例１では、実施例に記載の認証子をＩＶとして使用する。すなわち、変形例１では、認証子、所定の共通鍵、データ（メッセージ本文）の合成値に基づくハッシュ値をＭＡＣとして使用する。所定の共通鍵は、車両単位の鍵であってよく、車両１０内の複数のＥＣＵ間で共用される鍵であってよい。
【００７４】
図１１は、変形例１の被検査ＥＣＵ１２から出力される通常フレームの例を示す。変形例１の通常フレームは、ＭＡＣをさらに含む。被検査ＥＣＵ１２のフレーム生成部２８は、通常フレームの生成時に、認証子、ＭＡＣ用の共通鍵、データ（メッセージ本文）の合成値に基づくハッシュ値をＭＡＣとして取得し、取得したＭＡＣを通常フレームに設定する。なお、コミットメント登録フレームにもＭＡＣが付加されてよい。
【００７５】
監視ＥＣＵ１４の判定部３８は、被検査ＥＣＵ１２から送信された通常フレームを検査対象フレームとして受信すると、検査対象フレームに含まれる認証子（言い換えればＭＡＣのＩＶ）を実施例と同様に検証する。それとともに、判定部３８は、検査対象フレームに含まれるＭＡＣを公知の手法で検証する。例えば、判定部３８は、検査対象フレームに含まれる認証子およびデータ（メッセージ本文）と、所定の共通鍵とに基づいて、照合値を生成してもよい。判定部３８は、生成した照合値と、検査対象フレームに含まれるＭＡＣとが一致する場合、ＭＡＣの検証に成功したと判定してもよい。
【００７６】
判定部３８は、認証子による検証と、ＭＡＣによる検証の少なくとも一方に失敗した場合、認証子による検証成否と、ＭＡＣによる検証成否の組み合わせに応じて不正の状態を特定する。ここでは、以下の３ケースを説明する。
ケース１：第１ＥＣＵから送信された（すなわち第１ＥＣＵに対応するＩＤが設定された）検査対象フレームについて、認証子による検証に失敗し、ＭＡＣによる検証に成功した場合。
ケース２：上記検査対象フレームについて、認証子による検証に失敗し、ＭＡＣによる検証にも失敗した場合。
ケース３：上記検査対象フレームについて、認証子による検証に成功し、ＭＡＣによる検証に失敗した場合。
【００７７】
ケース１は、不正者に乗っ取られた第２ＥＣＵが、第１ＥＣＵに対応するＩＤを付与したフレームを送信したケースである。この場合、判定部３８は、第２ＥＣＵが第１ＥＣＵになりすましてフレームを注入したと判定する。また、ケース２では、判定部３８は、車両１０の外部から不正なフレーム（コマンド）が注入されたと判定する。また、ケース３では、判定部３８は、サードパーティＥＣＵが物理的に追加されたと判定する。異常処理部４２は、判定部３８による判定結果を示すログを所定の記憶領域へ出力する。
【００７８】
図１２（ａ）−（ｃ）は、変形例１の監視ＥＣＵ１４によるログの出力例を示す。図１２（ａ）は、起動時における正常状態を示すログを示している。図１２（ｂ）は、起動時における異常状態を示すログを示している。図１２（ａ）と図１２（ｂ）は、エンジンオン時に被検査ＥＣＵ１２のそれぞれが監視ＥＣＵ１４にコミットメントを登録したことを契機に、監視ＥＣＵ１４が出力したログを示している。具体的には、本来全てのフレームにＭＡＣが付加されるべきところ、ＥＣＵ４からのフレームにはＭＡＣが付加されていないため、異常と判定されたことを示している。
【００７９】
図１２（ｃ）は、走行時の異常状態を示すログを示している。ログ５０は、実施例で記載したフレームのロスを検出したことを示している。ログ５２は、認証子による検証に失敗し、ＭＡＣによる認証に成功したことにより、あるＥＣＵが別のＥＣＵになりすましていることを検出したことを示している。ログ５４は、認証子による検証に失敗し、ＭＡＣによる認証にも失敗したことにより、外部から不正なフレームが注入されたことを検出したことを示している。
【００８０】
変形例１によると、ハッシュチェーン認証とＭＡＣ認証との併用により、異常状態を詳細に把握できる。また、ＭＡＣ鍵が車両単位の鍵であっても、ハッシュチェーン認証により送信元を識別可能になる。また、送信元を識別するために、ＥＣＵのペアごとに鍵を用意する必要がなくなる。なお、図１２（ａ）と図１２（ｂ）で示したように、変形例１では、正当なＥＣＵはＭＡＣ付きのフレームを送信する。一方、上記実施例では、フレームにＭＡＣが付加されない場合でも、監視ＥＣＵ１４は、予め定められた数以上のＥＣＵ（被検査ＥＣＵ１２）がコミットメント登録することを異常として検知することができる。
【００８１】
（変形例２）
変形例２では、ハッシュに代えて、暗号化を利用する。データ暗号化方式に制約はないが、ここでは、ＡＥＳ（Advanced Encryption Standard）を使用する例を示す。図１３は、変形例２における認証子生成の過程を示す。実施例の認証子生成（図３）では、時間値、ＩＤ、乱数（または認証子）の合成データをハッシュ関数へ入力していたところ、変形例２では、被検査ＥＣＵ１２と監視ＥＣＵ１４で共通の固定鍵を使用して、上記合成データをＡＥＳ暗号化する。
【００８２】
暗号文を切り詰めて認証子を抽出するため、実質的に一方向性関数となる。例えば、図１３の認証子２から認証子１を推測することは困難である。ただし、認証子のビット数が小さすぎると、逆方向の総当たり攻撃が容易になる。そのため、認証子のサイズは、切り詰め前の暗号文のサイズの半分以上とすることが望ましい。なお、図１３の時間値およびＩＤは、被検査ＥＣＵ１２と監視ＥＣＵ１４間で共通のパディングデータ（例えばオール０のデータ）であってもよい。
【００８３】
監視ＥＣＵ１４の判定部３８は、検査対象フレームに含まれる認証子に、所定の時間値とＩＤを合成したデータを、被検査ＥＣＵ１２との共通鍵に基づいてＡＥＳ暗号化し、暗号文を取得する。判定部３８は、被検査ＥＣＵ１２と共通の切り詰め規則にしたがって暗号文から検証値を抽出する。以降、実施例と同様に、判定部３８は、検証値とコミットメント値が一致するか否かに応じて、検査対象フレームの正常性を検証する。
【００８４】
（変形例３）
実施例では言及していないが、１つの被検査ＥＣＵ１２が、互いにフレームＩＤが異なる複数種類の通常フレームを送信してもよい。この場合、被検査ＥＣＵ１２は、認証子を生成する際に、フレームＩＤに代えて、自装置で一意のＥＣＵ−ＩＤを使用してもよい。すなわち、被検査ＥＣＵ１２は、上記複数種類の通常フレームに、同一のハッシュチェーンに基づく認証子を設定してもよい。例えば、被検査ＥＣＵ１２は、第１のフレームＩＤを含む通常フレームに、認証子（９９８）を設定し、第２のフレームＩＤを含む通常フレームに、上記認証子（９９８）の基になった認証子（９９７）を設定してもよい。
【００８５】
変形例３では、コミットメント登録フレームに、通常フレームのフレームＩＤに代えて、ＥＣＵ−ＩＤが設定される。また、監視ＥＣＵ１４のコミットメント管理表のレコードは、ＥＣＵ−ＩＤ単位に生成される。また、監視ＥＣＵ１４は、１つのＥＣＵ−ＩＤと、１つ以上のフレームＩＤとの対応関係が定めたＩＤ管理表（テーブル）をさらに記憶する。なお、ＩＤ管理表は、コミットメント管理表に含まれてもよい。図１４は、変形例３におけるコミットメント管理表を示す。同図の表では、１つのＥＣＵ−ＩＤと、複数のフレームＩＤが対応付けられ、また、ＥＣＵ単位にコミットメント値が管理される。
【００８６】
ＩＤ管理表の作成方法を説明する。方法１として、ＩＤ管理表は、監視ＥＣＵ１４の製造時に、監視ＥＣＵ１４のストレージに格納されてもよく、クラウド上のサーバから監視ＥＣＵ１４へ提供されてもよい。方法２として、被検査ＥＣＵ１２は、コミットメント登録フレームに、ＥＣＵ−ＩＤとフレームＩＤとの対応関係を含めてもよい。また、被検査ＥＣＵ１２は、コミットメント登録時に、ＥＣＵ−ＩＤとフレームＩＤとの対応関係を示す専用のフレームを監視ＥＣＵ１４へ送信してもよい。
【００８７】
方法３として、監視ＥＣＵ１４は、動作モードの１つとして学習モードを備えてもよい。被検査ＥＣＵ１２は、フレームＩＤが異なる複数種類の通常フレームに、同一のハッシュチェーンに基づく認証子を設定し、複数種類の通常フレームを監視ＥＣＵ１４へ送信してもよい。監視ＥＣＵ１４は、学習モードにおいて受信した複数種類の通常フレームが含む認証子にハッシュ演算を実行し、同一のハッシュチェーンに基づく認証子が設定された複数種類の通常フレームを特定してもよい。監視ＥＣＵ１４は、特定した複数種類の通常フレームに設定された複数のフレームＩＤを対応付けてＩＤ管理表へ記録してもよい。これにより自動的にＩＤ管理表を生成することができる。
【００８８】
図１５は、コミットメント管理表の自動生成処理を示すフローチャートである。監視ＥＣＵ１４は、エンジンオンまたは電源オン等、所定の条件が満たされた場合に学習モードを開始する（Ｓ１３０）。被検査ＥＣＵ１２は、自装置のＥＣＵ−ＩＤとコミットメント（コミットメントｘとする）とを対応付けたコミットメント登録フレームをＣＡＮ１６へ送信する。監視ＥＣＵ１４は、上記コミットメント登録フレームを受信し、上記コミットメント登録フレームに設定されたＥＣＵ−ＩＤとコミットメントｘとをコミットメント管理表に記録する（Ｓ１３２）。
【００８９】
続いて、被検査ＥＣＵ１２は、ＣＡＮ−ＩＤ（ここでは「ａ」とする）と認証子（ここではコミットメントｘの元になった認証子ａ）を含む通常フレームをＣＡＮ１６へ送信する。監視ＥＣＵ１４は、上記通常フレームを受信し、その通常フレームに設定されたＣＡＮ−ＩＤ＿ａと認証子ａを取得する（Ｓ１３４）。監視ＥＣＵ１４は、認証子ａに対するハッシュ演算を実行して検証値を得る（Ｓ１３６）。監視ＥＣＵ１４は、検証値と一致するコミットメント（ここではコミットメントｘ）と、ＣＡＮ−ＩＤ＿ａを紐付けるようにコミットメント管理表を更新する（Ｓ１３８）。また、監視ＥＣＵ１４は、コミットメントｘを認証子ａの値に更新する。
【００９０】
続いて、被検査ＥＣＵ１２は、ＣＡＮ−ＩＤ（ここでは「ｂ」とする）と認証子（ここでは認証子ａの元になった認証子ｂ）を含む通常フレームをＣＡＮ１６へ送信する。監視ＥＣＵ１４は、上記通常フレームを受信し、その通常フレームに設定されたＣＡＮ−ＩＤ＿ｂと認証子ｂを取得する（Ｓ１４０）。監視ＥＣＵ１４は、認証子ｂに対するハッシュ演算を実行して検証値を得る（Ｓ１４２）。監視ＥＣＵ１４は、検証値と一致するコミットメント（ここではコミットメントｘ）と、ＣＡＮ−ＩＤ＿ｂを紐付けるようにコミットメント管理表を更新する（Ｓ１４４）。また、監視ＥＣＵ１４は、コミットメントｘを認証子ｂの値に更新する。
【００９１】
以上の結果、コミットメント管理表では、１つのＥＣＵ−ＩＤと、ＣＡＮ−ＩＤ＿ａおよびＣＡＮ−ＩＤ＿ｂとが対応付けられる。監視ＥＣＵ１４は、学習モードにおいてコミットメント登録フレームを受信する都度、Ｓ１３２を繰り返し、通常フレームを受信する都度、Ｓ１３４〜Ｓ１３８（またはＳ１４０〜Ｓ１４４）を繰り返す。学習モードは、学習モードの開始から所定時間が経過したこと、または、明示的な終了指示が入力されたことを契機に終了してもよい。
【００９２】
（変形例４）
図１６は、ハッシュチェーンの二重化を説明する図である。ハッシュチェーン６０は、図４に対応するハッシュチェーンであり、現在使用中の認証子を含むハッシュチェーンである。ハッシュチェーン６２は、ハッシュチェーン６０の認証子の後に使用される認証子を含むハッシュチェーンである。被検査ＥＣＵ１２のフレーム生成部２８が、ハッシュチェーン６０のある認証子を通常フレームで使用した場合、認証子生成部２４は、使用された認証子が記憶された領域（コミットメント記憶部２６の一部領域）に、ハッシュチェーン６２の認証子を新たに格納する。
【００９３】
具体的には、認証子生成部２４は、ハッシュチェーン６０の認証子（９９９）が使用されると、その記憶領域に、ハッシュチェーン６２の認証子（０）’を新たに格納する。続いて、ハッシュチェーン６０の認証子（９９８）が使用されると、フレーム生成部２８は、その記憶領域に、ハッシュチェーン６２の認証子（１）’を新たに格納する。すなわち、認証子生成部２４は、ハッシュチェーン６０の認証子が使用される都度、ハッシュチェーン６２の認証子を徐々に生成し、コミットメント記憶部２６に記録していく。この変形例によると、被検査ＥＣＵ１２でハッシュチェーンを二重化する場合でも、認証子（０）〜認証子（９９９）の記憶領域が確保されればよく、必要となる記憶容量を低減できる。
【００９４】
（変形例５）
実施例の被検査ＥＣＵ１２は、ハッシュチェーンにおける複数の認証子を全てコミットメント記憶部２６に記憶した。変形例として、被検査ＥＣＵ１２の認証子生成部２４は、被検査ＥＣＵ１２から監視ＥＣＵ１４へフレームを送信する都度、認証子を生成してもよい。例えば、認証子生成部２４は、コミットメント登録フレームを送信すべきタイミングで認証子（９９９）を生成してもよい。また、認証子生成部２４は、次に通常フレームを送信すべきタイミングで認証子（９９８）を新たに生成してもよい。
【００９５】
別の態様として、コミットメント記憶部２６は、ハッシュチェーンにおける複数の認証子のうち所定の規則に応じて一部を記憶してもよい。例えば、コミットメント記憶部２６は、認証子（０）、認証子（９９）、認証子（１９９）、・・・、認証子（８９９）、認証子（９９９）のように、１００番おきに認証子を記憶してもよい。認証子生成部２４は、使用すべき認証子より順番が小さい記憶済認証子の中から、使用すべき認証子に最も近い記憶済認証子を取得し、その記憶済認証子からハッシュ演算を開始して、使用すべき認証子を生成してもよい。なお、計算コストと、ストレージの記憶容量とを勘案して、実施例の方式、または、変形例５に記載の２つの方式の中からいずれかが選択されてもよい。
【００９６】
（その他の変形例）
車載ネットワークシステム１８内の複数のノード（ＥＣＵ等）が、実施例の監視ＥＣＵ１４の機能を備え、ＣＡＮ１６のバスから受信したフレームの正常性を並行して確認してもよい。
監視ＥＣＵ１４は、専用ＥＣＵに実装されてもよく、ソフトウェアモジュールとして実装されてもよい。
【００９７】
コミットメント管理表のビット長は、被検査ＥＣＵ１２の送信周期から見積もりを行ってもよい。以下例を示す。Ｎビットのハッシュを総当たりによって破るには、平均で２＾（Ｎ−１）回の演算が必要である。下記の見積もりにより、想定する攻撃ＥＣＵの演算能力を勘案してビット長を決定する。
［８ビット，１０ｍｓ］    ＝＞  ２＾７×１００＝１２７００回／秒
［１２ビット，２０ｍｓ］  ＝＞  ２＾１１×５０＝１０２４００回／秒
［１６ビット，１０ｍｓ］  ＝＞  ２＾１５×１００＝３２７６８００回／秒
【００９８】
ハッシュチェーン認証とＭＡＣ認証とを併用する場合、ＭＡＣ値を短くして、認証子を長くすることもできる。そこで、フレーム（メッセージ）の重要度（致命度）に応じてＭＡＣ値の長さを決定してもよい。ＮビットのＭＡＣ値は、鍵を知られない限り、１／２＾Ｎでのみ認証が成功する。また、ハッシュチェーン認証により、異常状態の検出は容易である。また、ＭＡＣ値を短くしても。鍵の漏洩のリスクは高くならない。
監視ＥＣＵ１４の判定部３８は、フレームの衝突によるエラー確率を閾値として予め記憶し、ハッシュチェーン認証がエラーになった確率が上記閾値を上回る場合に異常と判定してもよい。
【００９９】
被検査ＥＣＵ１２は、コミットメント登録フレームに、ＭＡＣおよび／または署名を付加してもよい。これにより、なりすましを防止できる。
被検査ＥＣＵ１２と監視ＥＣＵ１４それぞれの製造時に、同じ乱数列が両者に保存されてもよい。被検査ＥＣＵ１２から監視ＥＣＵ１４への初回のコミットメント登録時には、旧認証子の値として上記乱数列を設定してもよい。これにより、デフォルト値「００００・・・」の使用を抑制できる。
【０１００】
乱数生成能力が低い環境では、暗号またはハッシュを使用して擬似乱数を生成してもよい。
監視ＥＣＵ１４のコミットメント登録部３２は、コミットメント管理表への新たなレコードの追加が要求された場合、当該要求に付加された署名を検証し、その検証に成功したことを条件としてコミット管理表を更新してもよい。
【０１０１】
監視ＥＣＵ１４のコミットメント管理表には、現在のハッシュチェーンに基づくコミットメント値（「新コミットメント値」）と、１世代前のハッシュチェーンに基づくコミットメント値（「旧コミットメント値」）の両方が記憶されてもよい。監視ＥＣＵ１４の判定部３８は、コミットメントの更新の同期が確認できるまで、新旧両方のコミットメント値を使用して認証子を検証してもよい。
【０１０２】
例えば、監視ＥＣＵ１４のコミットメント登録部３２は、或るフレームＩＤ（もしくはＥＣＵ−ＩＤ）に対するコミットメントの再登録を要求するコミットメント登録フレームを受信した場合、それまでの新コミットメント値を旧コミットメント値に変更するとともに、コミットメント登録フレームが示すコミットメント値を新コミットメント値として保存してもよい。コミットメント登録部３２は、コミットメント値の更新完了を示すＡＣＫデータを被検査ＥＣＵ１２へ送信してもよい。
【０１０３】
被検査ＥＣＵ１２は、上記ＡＣＫデータの受信前は、１世代前のハッシュチェーンに基づく認証子を通常フレームに設定し、上記ＡＣＫデータの受信後は、現在のハッシュチェーンに基づく認証子を通常フレームに設定してもよい。監視ＥＣＵ１４の判定部３８は、上記ＡＣＫデータの送信後、新コミットメント値と旧コミットメント値の両方を使用して、通常フレームの認証子を検証してもよい。判定部３８は、新コミットメント値に基づいて認証子の検証に成功した場合、以降の検証では、新コミットメント値のみを使用してもよい。
【０１０４】
上記実施例および変形例に記載の技術は、ＣＡＮ以外の通信方式にも適用可能であり、例えば、イーサネット（登録商標）、ＭＯＳＴ（Media Oriented Systems Transport）（登録商標）、ＦｌｅｘＲａｙ（登録商標）にも適用可能である。
【０１０５】
なお、実施例および変形例に記載の技術は、以下の項目によって特定されてもよい。
［項目１］
バス型ネットワークに接続された第１の電子機器と、バス型ネットワークに接続された電子機器であって、第１の電子機器の状態を監視する第２の電子機器と、を備える通信システム。第１の電子機器は、ハッシュチェーンを構成する第１の検査値を含む第１のフレームをバス型ネットワークへ送信する送信部を含む。第２の電子機器は、バス型ネットワークから受信した第１のフレームに含まれる第１の検査値を記憶する記憶部を含む。第１の電子機器の送信部は、第１のフレームの送信後に、ハッシュチェーンを構成する第２の検査値を含む第２のフレームをバス型ネットワークへ送信し、第２の電子機器は、バス型ネットワークから受信した第２のフレームに含まれる第２の検査値と、記憶部に記憶された第１の検査値とがハッシュチェーンを構成する場合に、第１の電子機器の状態を正常と判定する判定部をさらに含む。
この通信システムによると、第１の電子機器が送信するフレームの正当性を、第２の電子機器がハッシュチェーンに基づいて認証する。これにより、鍵情報を利用することなく、バス型ネットワークを流れるフレームが正常なフレームか、異常なフレームかを高い精度で識別することができる。
［項目２］
第１の電子機器の送信部は、ハッシュチェーンのＮ番目（Ｎは２以上の整数）の値を第１の検査値として含む第１のフレームを送信し、ハッシュチェーンのＮ−１番目の値を第２の検査値として含む第２のフレームを送信してもよい。第２の電子機器の判定部は、第２のフレームに含まれる第２の検査値に基づくハッシュ演算の結果が、第１の検査値と一致する場合に、第１の電子機器の状態を正常と判定してもよい。
この態様によると、正しい第２の検査値を送信できる電子機器は、ハッシュチェーンを構築した第１の電子機器だけであり、不正な電子機器が第１の電子機器になりすましても、そのことを検出できる。すなわち、第２のフレームの送信元の正当性を認証することができる。
［項目３］
第２の電子機器の記憶部は、第１の電子機器が送信したフレームのうち第３の電子機器により破棄されるフレームの個数に応じた演算回数をさらに記憶してもよい。第２の電子機器の判定部は、第２のフレームに含まれる第２の検査値に基づくハッシュ演算を演算回数実行した結果が、第１の検査値と一致する場合に、第１の電子機器の状態を正常と判定してもよい。
この態様によると、バス型ネットワークの異なるバス間でフレームを中継するゲートウェイ等の第３の電子機器が、第１の電子機器が送信したフレームの一部を削除する場合も、第１の電子機器の正当性を精度よく判定することができる。
［項目４］
第１の電子機器の送信部は、メッセージ認証コードをさらに含む第２のフレームを送信し、第２の電子機器の判定部は、第２のフレームに含まれる第２の検査値を用いた検証結果と、第２のフレームに含まれるメッセージ認証コードを用いた検証結果の両方に基づいて第１の電子機器の状態を判定する。
この態様によると、ハッシュチェーンに基づく認証と、メッセージ認証コードに基づく認証とを併用することにより、鍵の管理コストの増加を抑えつつ、セキュリティ強度を一層高めることができる。
［項目５］
バス型の車載ネットワークに接続された第１の電子機器と、車載ネットワークに接続された電子機器であって、第１の電子機器の状態を監視する第２の電子機器と、を備える車両。第１の電子機器は、ハッシュチェーンを構成する第１の検査値を含む第１のフレームを車載ネットワークへ送信する送信部を含む。第２の電子機器は、車載ネットワークから受信した第１のフレームに含まれる第１の検査値を記憶する記憶部を含む。第１の電子機器の送信部は、第１のフレームの送信後に、ハッシュチェーンを構成する第２の検査値を含む第２のフレームを車載ネットワークへ送信し、第２の電子機器は、車載ネットワークから受信した第２のフレームに含まれる第２の検査値と、記憶部に記憶された第１の検査値とがハッシュチェーンを構成する場合に、第１の電子機器の状態を正常と判定する判定部をさらに含む。
この車両によると、第１の電子機器が送信するフレームの正当性を、第２の電子機器がハッシュチェーンに基づいて認証する。これにより、鍵情報を利用することなく、バス型ネットワークを流れるフレームが正常なフレームか、異常なフレームかを高い精度で識別することができる。
［項目６］
バス型の車載ネットワークに接続された第１の電子機器が、ハッシュチェーンを構成する第１の検査値を含む第１のフレームを車載ネットワークへ送信し、車載ネットワークに接続された電子機器であって、第１の電子機器の状態を監視する第２の電子機器が、車載ネットワークから受信した第１のフレームに含まれる第１の検査値を記憶部に記憶し、第１の電子機器が、第１のフレームの送信後に、ハッシュチェーンを構成する第２の検査値を含む第２のフレームを車載ネットワークへ送信し、第２の電子機器が、車載ネットワークから受信した第２のフレームに含まれる第２の検査値と、記憶部に記憶された第１の検査値とがハッシュチェーンを構成する場合に、第１の電子機器の状態を正常と判定する監視方法。
この監視方法によると、第１の電子機器が送信するフレームの正当性を、第２の電子機器がハッシュチェーンに基づいて認証する。これにより、鍵情報を利用することなく、バス型ネットワークを流れるフレームが正常なフレームか、異常なフレームかを高い精度で識別することができる。
【０１０６】
上述した実施例および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施例および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施例および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。
【符号の説明】
【０１０７】
１０  車両、  １２  被検査ＥＣＵ、  １４  監視ＥＣＵ、  １７  ＣＧＷ、  １８  車載ネットワークシステム、  ２０  通信部、  ２８  フレーム生成部、  ３０  通信部、  ３４  コミットメント記憶部、  ３８  判定部。
【図１】
2018133744.tif 000003
【図２】
2018133744.tif 000004
【図３】
2018133744.tif 000005
【図４】
2018133744.tif 000006
【図５】
2018133744.tif 000007
【図６】
2018133744.tif 000008
【図７】
2018133744.tif 000009
【図８】
2018133744.tif 000010
【図９】
2018133744.tif 000011
【図１０】
2018133744.tif 000012
【図１１】
2018133744.tif 000013
【図１２】
2018133744.tif 000014
【図１３】
2018133744.tif 000015
【図１４】
2018133744.tif 000016
【図１５】
2018133744.tif 000017
【図１６】
2018133744.tif 000018