JP2017028345A - ゲートウェイ装置およびその制御方法 - Google Patents

Abstract

【課題】
メッセージの改ざん検知符号を生成する鍵の管理負担の低減をする。
【解決手段】
２以上のドメイン間でメッセージを中継するゲートウェイ装置であって、前記２以上のドメインの中の第１のドメインに対応する第１の改ざん検知符号と第１のデータを含む第１のメッセージを前記第１のドメインから受信し、前記２以上のドメインの中の第２のドメインに対応する第２の改ざん検知符号と前記第１のデータを含む第２のメッセージを前記第２のドメインへ送信する。
【選択図】 図２

Description

本発明は、ゲートウェイ装置およびその制御方法に関するものである。

自動車の車載ネットワークにおける代表的な標準プロトコルとしてＣｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（以下、ＣＡＮ）が普及している。このような車載ネットワークでは、ＯＢＤ２（Ｏｎ−Ｂｏａｒｄ−Ｄｉａｇｎｏｓｔｉｃｓ ２）ポートのような車載ネットワークに直接繋がっているインタフェースに不正な機器を接続し、リプレイ攻撃が行なわれる危険性がある。ここで、リプレイ攻撃とは、通信路上を流れるメッセージを盗聴して事前に取得し、取得したメッセージを再送することで不正な動作を引き起こす攻撃である。

他にも、車外のシステムと連携する情報処理装置がマルウェアに感染し、感染した装置が偽メッセージを車載ネットワークに送信し、メッセージを受信した制御装置が誤動作を引き起こすといった危険性もある。

通常、これらの脅威に対しては、各情報処理装置間を流れるメッセージに対して、改ざん検知符号としてＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）を用いたメッセージ認証を実施することが有効とされている。ＭＡＣは暗号化用の鍵を利用し、所定の暗号アルゴリズムを用いて生成されるため、各制御装置において鍵の管理が必要となる。

このような技術に関して、特許文献１には、通信フレーム部分にメッセージ種別の識別子とともにセキュリティ情報（改ざん検知符号）を含ませ、セキュリティ情報は各正規ノードの通信のセッション鍵とする技術が開示されている（要約）。

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

特許文献１に開示された技術を用いれば、正規の通信であることを確認することは可能である。しかしながら、特許文献１には鍵を管理する技術に関する開示はない。車載システムでは各装置の処理能力に制約があるため、鍵の管理においても負担の少ない技術が必要とされている。

そこで、本発明は、以上の問題に鑑みてなされたものであり、メッセージの改ざん検知符号を生成する鍵の管理負担の低減を目的とする。

上記目的を達成するために、本発明に係る代表的なゲートウェイ装置は、２以上のドメイン間でメッセージを中継するゲートウェイ装置であって、前記２以上のドメインの中の第１のドメインに対応する第１の改ざん検知符号と第１のデータを含む第１のメッセージを前記第１のドメインから受信し、前記２以上のドメインの中の第２のドメインに対応する第２の改ざん検知符号と前記第１のデータを含む第２のメッセージを前記第２のドメインへ送信することを特徴とする。

本発明によれば、メッセージの改ざん検知符号を生成する鍵の管理負担を低減することが可能になる。

車載システムの構成の例を示す図である。 ドメイン間通信の処理シーケンスの例を示す図である。 送信制御装置の処理フローの例を示す図である。 ＧＷ装置の処理フローの例を示す図である。 受信制御装置の処理フローの例を示す図である。 鍵情報のテーブル構成の例を示す図である。 ＭＡＣ付け替え判定情報のテーブル構成の例を示す図である。 送信制御装置のドメイン間鍵処理を含む処理フローの例を示す図である。 ＧＷ装置のドメイン間鍵処理を含む処理フローの例を示す図である。 受信制御装置のドメイン間鍵処理を含む処理フローの例を示す図である。 利用鍵情報のテーブル構成の例を示す図である。 ナンスを含むドメイン間通信の処理シーケンスの例を示す図である。

以下、本発明の実施形態について、実施例を用い、図面を参照しながら詳細に説明する。

実施例１では、各制御装置がドメインごとに共有されるドメイン鍵を管理し、メッセージに対して、ドメイン鍵を用いて算出したＭＡＣを付与し、ＧＷ装置は付け替え処理部とＭＡＣ付け替え判定情報を用いて受信したメッセージがＭＡＣの付け替え対象なのかどうかを判定し、付け替え対象のメッセージに対してＭＡＣの付け替えを行い、ルーティング処理部を用いて通信先のドメインにメッセージを送信することを可能とする鍵管理の例を説明する。

ただし、実施例１の構成は、この例に限定されるものではない。なお、各装置で利用する暗号用の鍵は、製品開発時やメンテナンス時などの任意のタイミングで安全に配布、更新されていることが好ましい。

図１は、車載システムの構成の例を示す図である。車両３０に搭載されているＧＷ装置１０は、車内バス４０を介して、制御装置２０と互いに接続されている。なお、車内バス４０−１、４０−２、・・・４０−ｎ（ｎは３以上の自然数）を区別なく代表して表す場合は車内バス４０と記載し、制御装置２０−１ａ、２０−１ｂ、２０−２、・・・２０−ｎを区別なく代表して表す場合は制御装置２０と記載する。

ここで、車内バス４０としては、例えば、ＣＡＮやＣＡＮ ＦＤ（Ｆｌｅｘｉｂｌｅ Ｄａｔａ−Ｒａｔｅ）であってもよい。また、車内バス４０の個数は２であってもよく、ドメインの個数も２であってもよい。

ＧＷ装置１０は、車外通信部１１、付け替え処理部１２、ルーティング処理部１３、車内通信部１４、鍵関連情報記憶部１５から成る。車外通信部１１はネットワーク（有線、無線）５０を介して車両３０の外の装置、或いはセンタ等と接続し、車外とのメッセージの送受信を行なう。付け替え処理部１２は受信したメッセージがＭＡＣの付け替え対象なのかどうかを判定する。

ルーティング処理部１３は付け替え処理部１２の判定結果に基づいて通信先の制御装置２０を特定し、送信するメッセージを作成する。車内通信部１４はルーティング処理部１３が生成したメッセージを該当するドメインの車内バス４０に送信する。鍵関連情報記憶部１５はＭＡＣ付け替え判定情報１５１と鍵情報１５２を保持する。

ＭＡＣ付け替え判定情報１５１は付け替え処理部１２の受信したメッセージが付け替え対象であるのか否かを判定するために利用される情報である。鍵情報１５２はＧＷ装置１０によって分割された各ドメインの鍵情報であり、付け替え処理部１２は鍵情報１５２から取得したドメイン鍵を用いて通信先のドメインに対応するＭＡＣを算出する。

制御装置２０は、車内通信部２１、鍵利用部２２、メッセージ生成部２３、鍵関連情報記憶部２４から成る。車内通信部２１は車内バス４０にメッセージを送信する、或いは車内バス４０からメッセージを受信する。鍵利用部２２は制御装置２０が接続されているドメインに設定されたドメイン鍵を選択し、例えばＭＡＣの生成および検証を行なう。

メッセージ生成部２３は、鍵利用部２２が選択したドメイン鍵を用いて算出したＭＡＣを付与してメッセージを生成する。鍵関連情報記憶部２４は利用鍵情報２４１を保持する。利用鍵情報２４１はメッセージに付与するドメイン鍵の情報であり、メッセージ生成部２３は利用鍵情報２４１から取得したドメイン鍵を用いてＭＡＣを算出する。

なお、制御装置２０は、車両３０を制御するための図示を省略したセンサ機器やアクチュエータ等と接続されてもよく、それらを備えてもよい。また、制御装置２０−１ａと制御装置２０−１ｂが車内バス４０−１に接続されているように、複数の制御装置２０が１つの車内バス４０に接続され、１つのドメインに属してもよい。

また、利用鍵情報２４１、ＭＡＣ付け替え判定情報１５１、鍵情報１５２のそれぞれの情報は、図示を省略した入力装置から予め設定されてもよいし、ネットワーク５０経由で予め設定されてもよい。

図２は、制御装置２０がＧＷ装置１０を介して異なるドメインの制御装置２０に対してメッセージを送信する、すなわちドメイン間通信における概要処理シーケンスの例を示す図である。なお、送信制御装置２０−３と受信制御装置２０−４は、複数の制御装置２０の中から送信する制御装置２０と受信する制御装置２０の例として挙げたものであり、制御装置２０と同じ構成を有している。

以下のステップ２１０１からステップ２１０４は送信制御装置２０−３の処理である。ステップ２１０１では、メッセージ生成部２３が、車両３０の走行制御に用いる制御パラメータ情報を、例えば送信制御装置２０−３に備わるセンサ機器等から取得する。

ステップ２１０２では、鍵利用部２２が、利用鍵情報２４１から送信制御装置２０−３が接続されたドメインのドメイン鍵を取得し、取得したドメイン鍵を用いてＭＡＣを算出する。例えば、取得した制御パラメータ情報をメッセージのデータとし、メッセージのＩＤ情報等の送受信に必要な情報をメッセージのヘッダとして、データとヘッダへドメイン鍵を適用することによりＭＡＣを算出してもよい。また、データのみにドメイン鍵を適用することによりＭＡＣを算出してもよい。

ステップ２１０３では、メッセージ生成部２３が、メッセージのデータとなるステップ２１０１で取得した制御パラメータ情報と、ステップ２１０２で算出したＭＡＣをもとに、通信用のメッセージを生成する。なお、メッセージはヘッダや図示を省略したフッタ等を含んでもよい。ステップ２１０４では、メッセージ生成部２３が、車内通信部２１を用いてステップ２１０３で生成したメッセージを車内バス４０に送信する。

ステップ１０１では、付け替え処理部１２は、車内通信部１４から受信したメッセージのＩＤ情報がＭＡＣの付け替え対象であるのか否かを、ＭＡＣ付け替え判定情報１５１をもとに判定する。受信したメッセージがＭＡＣの付け替え対象と判定した場合はステップ１０２に進み、ＭＡＣの付け替え対象ではないと判定した場合は処理を終了し、エラー処理に移行する。

図７に、ステップ１０１で参照されるＭＡＣ付け替え判定情報１５１のテーブル構成の例を示す。ＣＡＮ−ＩＤ欄１５１１は、メッセージを識別する情報すなわちメッセージのＩＤ情報を示す。図７では、ＣＡＮ−ＩＤを情報の例とし、ＣＡＮ−ＩＤ欄１５１１としたが、メッセージを識別可能な情報であればＣＡＮ−ＩＤ以外の情報を用いてもよい。

通信関係ドメイン欄１５１２は、ＣＡＮ−ＩＤ欄１５１１の値を使用するメッセージで通信関係のあるドメインを示す。ＭＡＣ付け替え要否欄１５１３は、ＣＡＮ−ＩＤ欄１５１１の値を使用するメッセージがＭＡＣの付け替え対象なのか、非対象なのかを示す。ＭＡＣ付け替え要否欄１５１３の値が「要」の場合はメッセージに付与されたＭＡＣは付け替えの対象となり、「否」の場合はメッセージに付与されたＭＡＣは付け替えの対象とならない。

ドメイン間鍵対象欄１５１４は、ＣＡＮ−ＩＤ欄１５１１の値を使用するメッセージがドメイン間鍵の対象であるのか、非対象であるのかを示す。ドメイン間鍵対象欄１５１４の値が「該当」の場合はドメイン間鍵を用いてＭＡＣを算出する対象であることを示し、「非該当」の場合はドメイン間鍵を用いないことを示す。

ここで、ドメイン間鍵は、周期の短い（高周期の）メッセージ、或いは複数のドメインに送信されるメッセージ、通信調停において優先されるメッセージ、或いはセキュリティや機能安全の観点で重要度の高いドメインと通信されるメッセージ等に対して個々に設定してもよいが、この例に限らないものである。なお、ドメイン間鍵対象欄１５１４は実施例２で用いられる。

ステップ１０２では、付け替え処理部１２は、受信したメッセージ（ヘッダとデータ）と鍵情報１５２から取得したドメイン鍵を用いてＭＡＣを算出し、受信したメッセージに付与されたＭＡＣと、算出したＭＡＣを比較し、ＭＡＣの値が一致している場合はステップ１０３に進み、ＭＡＣの値が一致していない場合は本処理を終了して、エラー処理に移行する。

図６に、ステップ１０２で参照される鍵情報１５２のテーブル構成の例を示す。ドメイン欄１５２１は、ＧＷ装置１０によって分割される車載ネットワーク（車内バス４０）のドメインを示す。ドメイン鍵欄１５２２は、ドメイン欄１５２１のドメインごとに設定されるドメイン鍵を示す。

鍵情報１５２のテーブルのドメインとドメイン鍵の設定は、図示を省略した入力画面を表示して、それぞれドメインとドメイン鍵との組合せが入力されることによる設定であってもよい。また、予め設定されたドメインを入力画面に表示し、各ドメインに対応するドメイン鍵の入力枠を表示して、各入力枠にドメイン鍵が入力されることによる設定であってもよい。ここで、図１に示すようにドメイン１には制御装置２０−１ａと制御装置２０−１ｂの２つが属する場合もあるため、ドメイン鍵の入力枠の表示の個数は、制御装置２０の個数よりも少ない個数であってもよい。

ステップ１０３では、付け替え処理部１２が、受信したメッセージが送られてきた車内バス４０のドメインと、通信関係ドメイン欄１５１２をもとに、通信先のドメインを特定し、特定した通信先のドメインをもとに鍵情報１５２から取得したドメイン鍵を用いてＭＡＣを算出する。ステップ１０４では、付け替え処理部１２が、受信したメッセージのＭＡＣをステップ１０３で生成したＭＡＣに付け替える。

ステップ１０５では、ルーティング処理部１３が、ステップ１０３で特定した通信先となるドメインの情報を取得する。ここで、ステップ１０３において付け替え処理部１２が、図示を省略した一時的なメモリ上に通信先のドメインの情報を格納しておいてもよい。ステップ１０６では、ルーティング処理部１３が、ステップ１０４で生成したメッセージを、ステップ１０５で取得した通信先となるドメインの車内バス４０に送信する。

なお、ステップ１０３からステップ１０６までの処理を、通信先のドメインの数だけ繰り返し実施する。

以下のステップ２２０１からステップ２２０２は受信制御装置２０−４の処理である。ステップ２２０１では、鍵利用部２２が、利用鍵情報２４１から受信制御装置２０−４が接続されているドメインのドメイン鍵を取得し、受信したメッセージ（ヘッダ、データ）をもとにＭＡＣを算出し、算出したＭＡＣと受信したメッセージに付与されたＭＡＣを比較する。

ＭＡＣの値が一致している場合はステップ２２０２に進み、ＭＡＣの値が一致していない場合は本処理を終了し、エラー処理に移行する。ステップ２２０２では、受信制御装置２０−４が受信したメッセージのデータである制御パラメータ情報をもとに走行制御を実施する。

以上のステップにより、制御装置２０はＧＷ装置１０を介したドメイン間通信において、異なるドメインの制御装置２０にメッセージを送信できる。なお、ＧＷ装置１０の処理負荷を低減するために、ステップ１０２におけるＭＡＣの検証処理を省略してもよい。

また、ＭＡＣは暗号化用の鍵を利用して所定の暗号アルゴリズムにより生成されるため、ＭＡＣの生成の代わりに暗号化されたデータを生成してメッセージに含め、暗号化のもととなったデータはメッセージに含めず、メッセージを送信してもよい。このように暗号化されたデータがメッセージに含められて送信される場合は、ＭＡＣの値が一致するかを比較して判定するＭＡＣ検証処理を省略してもよい。

図３は、図２のステップ２１０１からステップ２１０４までの、送信制御装置２０−３の詳細な処理フローの例を示す図である。ステップ２１００１では、メッセージ生成部２３が、車両の走行制御に用いる制御パラメータ情報を、例えば送信制御装置２０−３に備わるセンサ機器等から取得する。

ステップ２１００２では、メッセージ生成部２３が、ステップ２１００１で取得した制御パラメータ情報に対応するＣＡＮ−ＩＤを取得する。なお、予め制御パラメータ情報の種類に応じてＣＡＮ−ＩＤが設定され、図示を省略したメモリ等に記憶されている。

ステップ２１００３では、鍵利用部２２が、ステップ２１００２で取得したＣＡＮ−ＩＤがメッセージ認証の対象であるのか否かを判定する。メッセージ認証の対象となる場合はステップ２１００４に進み、メッセージ認証の対象とならない場合はステップ２１００６に進む。なお、予めメッセージ認証の対象となるＣＡＮ−ＩＤのリストが設定され、図示を省略したメモリ等に記憶されている。

ステップ２１００４では、鍵利用部２２が、利用鍵情報２４１から送信制御装置２０−３の接続されたドメインのドメイン鍵を取得する。ステップ２１００５では、鍵利用部２２が、ステップ２１００４で取得したドメイン鍵を用いてＭＡＣを算出する。

ステップ２１００６では、メッセージ生成部２３が、ステップ２１００３においてメッセージ認証の対象外となった場合は、ステップ２１００１で取得した制御パラメータ情報をもとに通信用メッセージを生成する。一方、ステップ２１００３においてメッセージ認証の対象となった場合は、ステップ２１００１で取得した制御パラメータ情報と、ステップ２１００５で算出したＭＡＣをもとに、通信用のメッセージを生成する。

ステップ２１００７では、メッセージ生成部２３が、車内通信部２１を用いて、ステップ２１００６で生成したメッセージを車内バス４０に送信する。

以上のステップ２１００１からステップ２１００７により、送信制御装置２０−３は、ドメイン鍵を用いて算出したＭＡＣを付与したメッセージを車内バス４０に送信できる。

図４は、図２のステップ１０１からステップ１０６までの、ＧＷ装置１０の詳細な処理フローの例を示す図である。ステップ１００１では、付け替え処理部１２が、受信したメッセージに付与されたＣＡＮ−ＩＤを取得する。

ステップ１００２では、付け替え処理部１２が、ＭＡＣ付け替え判定情報１５１を参照し、ステップ１００１で取得したＣＡＮ−ＩＤと一致するＣＡＮ−ＩＤ欄１５１１のＣＡＮ−ＩＤに対応するＭＡＣ付け替え要否１５１３欄の情報を取得し、取得したＭＡＣ付け替え要否欄１５１３の情報が「要」の場合はステップ１００３に進み、「否」の場合は本処理を終了する。

ステップ１００３では、付け替え処理部１２が、受信したメッセージが送られてきた車内バス４０のドメインすなわち通信元のドメインを取得し、取得したドメインと一致するドメイン欄１５２１のドメインに対応するドメイン鍵欄１５２２のドメイン鍵を取得する。

ここで、図１に示した例のように車内通信部１４へドメイン１の車内バス４０−１、ドメイン２の車内バス４０−２、ドメインｎの車内バス４０−ｎが独立して接続され、どの接続の車内バス４０から受信したかに応じて、受信したメッセージが送られてきた車内バス４０のドメインを取得してもよいし、メッセージにドメインを特定する情報が含まれて、その情報からドメインを取得してもよい。

ステップ１００４では、付け替え処理部１２が、受信したメッセージとステップ１００３で取得したドメイン鍵を用いてＭＡＣを算出し、受信したメッセージに付与されているＭＡＣと算出したＭＡＣを比較して検証する。ここで、２つのＭＡＣの値が一致した場合は正しく、一致しなかった場合は正しくないとする。

ステップ１００５では、付け替え処理部１２が、ステップ１００４におけるＭＡＣの比較の結果、ＭＡＣが一致して正しかった場合はステップ１００７に進み、一致せずにＭＡＣが正しくなかった場合はステップ１００６に進む。ステップ１００６では、付け替え処理部１２が、例えばエラーが発生したことを車内バス４０経由で各制御装置等に通知し、本処理を終了する。

ステップ１００７では、付け替え処理部１２が、ステップ１００１で取得したＣＡＮ−ＩＤと一致するＣＡＮ−ＩＤ欄１５１１のＣＡＮ−ＩＤに対応する通信関係欄ドメイン１５１２のドメインを取得する。この通信関係ドメイン欄１５１２から取得したドメインの中で、ステップ１００３で取得した通信元のドメイン以外のドメインを通信先のドメインとして取得する。そして、取得した通信先のドメインと一致するドメイン欄１５２１のドメインに対応するドメイン鍵１５２２のドメイン鍵を鍵情報１５２から取得する。

ステップ１００８では、付け替え処理部１２が、受信したメッセージとステップ１００７で取得した通信先のドメインのドメイン鍵を用いてＭＡＣを算出する。ステップ１００９では、付け替え処理部１２は、受信したメッセージに付与されたＭＡＣの代わりに、ステップ１００８で算出したＭＡＣを付与し、メッセージを再生成する。

ステップ１０１０では、ルーティング処理部１３が、ステップ１００９で生成したメッセージをステップ１００７で取得した通信先となるドメインの車内バス４０に送信する。

ステップ１０１１では、ルーティング処理部１３が、対象となる全ての通信先のドメインに対して、ステップ１００９で生成したメッセージを送信した場合は本処理を終了し、対象となる全ての通信先のドメインに対してメッセージを送信できていない場合は、ステップ１００８に戻る。

ステップ１０１１の判定として、例えば、ステップ１００７で取得した通信先となるドメインの総数と送信したメッセージ数を管理し、メッセージを送信するたびにメッセージ数をカウントアップし、通信先となるドメインの総数と送信したメッセージ数を比較することで判定してもよい。

以上のステップ１００１からステップ１０１１により、ＧＷ装置１０はＭＡＣの付け替えが必要なメッセージに対して、ＭＡＣを付け替えた上で、通信先となるドメインにメッセージを転送できる。

図５は、図２のステップ２２０１からステップ２２０２までの、受信制御装置２０−４の詳細な処理フローの例を示す図である。ステップ２２００１では、鍵利用部２２が、受信したメッセージに付与されたＣＡＮ−ＩＤを取得する。

ステップ２２００２では、鍵利用部２２が、ステップ２２００２で取得したＣＡＮ−ＩＤがメッセージ認証の対象であるのか否かを判定する。メッセージ認証の対象となる場合はステップ２２００３に進み、メッセージ認証の対象とならない場合はステップ２２００７に進む。なお、予めメッセージ認証の対象となるＣＡＮ−ＩＤのリストが設定され、図示を省略したメモリ等に記憶されている。

ステップ２２００３では、鍵利用部２２が、受信制御装置２０−４の接続された車内バス４０のドメインに該当するドメイン鍵を利用鍵情報２４１から取得する。ステップ２２００４では、鍵利用部２２が、受信したメッセージとステップ２２００３で取得したドメイン鍵を用いてＭＡＣを算出し、受信したメッセージに付与されたＭＡＣと算出したＭＡＣを比較して検証する。ここで、ＭＡＣの値が一致した場合は正しく、一致しなかった場合は正しくないとする。

ステップ２２００５では、鍵利用部２２が、ステップ２２００４におけるＭＡＣの比較の結果、ＭＡＣが一致して正しかった場合はステップ２２００７に進み、ＭＡＣが一致せずに正しくなかった場合はステップ２２００６に進む。ステップ２２００６では、鍵利用部２２が、例えばエラーが発生したことを車内バス４０経由で各制御装置等に通知し、本処理を終了する。ステップ２２００７では、受信制御装置２０−４が、受信したメッセージをもとに走行制御を実施する。

以上のステップ２２００１からステップ２２００７により、受信制御装置２０−４は、車内バス４０を介して受信したメッセージに対してドメイン鍵を用いてＭＡＣを検証し、走行制御を実施できる。

以上、実施例１によれば、各制御装置２０はドメインごとに共有されるドメイン鍵を管理し、ＧＷ装置１０は受信したメッセージがＭＡＣの付け替え対象であるのか否かを判定し、付け替え対象のメッセージに対してＭＡＣの付け替えを行い、通信先のドメインにメッセージを送信することが可能となる。

これにより、ドメイン鍵を管理すればよいので、制御装置２０毎に鍵を管理する構成と比較して、管理する鍵数を減らすことができ、鍵の更新負荷も減らすことができる。そして、車載システムのようにＧＷ装置１０の処理能力に制限のあるシステムにおいても鍵を管理することが可能になる。また、１つの鍵が漏洩しても車載システムとしての影響を抑えることができる。

なお、実施例１では車載ネットワークを対象にした例を説明したが、これに限定するものではなく、他の制御系システムや情報系システムにおける装置にも適用可能である。

実施例２として、各制御装置がドメインごとに共有されるドメイン鍵に加えて、ドメイン間で共有されるドメイン間鍵も管理し、メッセージに対して、メッセージのＩＤ情報に基づいてドメイン鍵、或いはドメイン間鍵を用いて算出したＭＡＣを付与し、ＧＷ装置は付け替え処理部とＭＡＣ付け替え判定情報を用いて受信したメッセージがＭＡＣの付け替え対象なのかどうかを判定するとともに、ＭＡＣの算出に用いた鍵がドメイン鍵なのか、ドメイン間鍵なのかを判定し、ドメイン鍵を用いたメッセージに対してはＭＡＣの付け替えを行い、ドメイン間鍵を用いたメッセージに対してはＭＡＣの付け替えを行なわず、ルーティング処理部を用いて通信先のドメインにメッセージを送信し、ＧＷ装置における処理負荷を低減することを可能とする鍵管理の例を説明する。

車載システムの構成は、制御装置２０の利用鍵情報２４１が利用鍵情報２１４１であることを除き、実施例１の図１を用いて説明した構成と同じであり、各部の動作が以下で説明するように実施例１とは異なる。

図８は、図３のステップ２１００３とステップ２１００５の間に、ＭＡＣの算出に用いる鍵の種類を判定する送信制御装置２０−３の詳細な処理フローの例を示す図である。ステップ２１００１からステップ２１００３までの各ステップは、実施例１の図３を用いて説明したステップ２１００１からステップ２１００３までの各ステップと同様である。

ステップ２１００８では、鍵利用部２２が、図１１を用いて説明する利用鍵情報２１４１を参照し、ステップ２１００２で取得したＣＡＮ−ＩＤがドメイン鍵の対象であるのか否かを判定し、ドメイン鍵の対象である場合はステップ２１００４に進み、ドメイン鍵の対象ではない場合はステップ２１００９に進む。

図１１に、ステップ２１００８で参照される利用鍵情報２１４１のテーブル構成の例を示す。ＣＡＮ−ＩＤ欄２１４１１は、メッセージを識別する情報を示す。メッセージを識別可能な情報であればＣＡＮ−ＩＤ以外の情報を用いてもよい。利用鍵欄２１４１２は、ＣＡＮ−ＩＤ欄２１４１１のＣＡＮ−ＩＤに応じてＭＡＣの生成に用いる鍵情報を示す。ドメイン鍵対象欄２１４１３はＣＡＮ−ＩＤ欄２１４１１のＣＡＮ−ＩＤで識別されるメッセージが、ドメイン鍵の対象であるのか否かを示す。

例えば、ステップ２１００８において、鍵利用部２２は、ステップ２１００２で取得したＣＡＮ−ＩＤと一致するＣＡＮ−ＩＤ欄２１４１１のＣＡＮ−ＩＤに対応するドメイン鍵対象２１４１３の情報を取得し、ドメイン鍵対象２１４１３の情報が「該当」の場合は、ＭＡＣの生成においてドメイン鍵を利用し、「非該当」の場合は、ＭＡＣの生成においてドメイン間鍵を利用する。

このため、ステップ２１００９では、鍵利用部２２が、ステップ２１００２で取得したＣＡＮ−ＩＤと一致するＣＡＮ−ＩＤ欄２１４１１のＣＡＮ−ＩＤに対応する利用鍵欄２１４１２のドメイン間鍵を取得する。

ステップ２１００４からステップ２１００７までの各ステップは、実施例１の図３を用いて説明したテップ２１００４からステップ２１００７までの各ステップと同様である。

以上のステップ２１００１からステップ２１００９により、送信制御装置２０−３は、メッセージのＣＡＮ−ＩＤに応じてドメイン鍵、或いはドメイン間鍵を用いたＭＡＣを生成できるようになる。

図９は、図４のステップ１００２において、ＭＡＣ付け替え対象ではないと判定された場合に、ドメイン間鍵の対象メッセージであるのか否かを判定するＧＷ装置１０の詳細な処理フローの例を示す図である。ステップ１００１、およびステップ１００３からステップ１０１１までの各ステップは、実施例１の図４を用いて説明したステップ１００１、およびステップ１００３からステップ１０１１までの各ステップと同様である。

ステップ１００２では、付け替え処理部１２が、ＭＡＣ付け替え判定情報１５１を参照し、ステップ１００１で取得したＣＡＮ−ＩＤと一致するＣＡＮ−ＩＤ欄１５１１のＣＡＮ−ＩＤに対応するＭＡＣ付け替え要否欄１５１３の情報を取得し、取得したＭＡＣ付け替え要否欄１５１３の情報が「要」の場合はステップ１００３に進み、「否」の場合はステップ１０１２に進む。

ステップ１０１２では、付け替え処理部１２が、ＭＡＣ付け替え判定情報１５１を参照し、ステップ１００１で取得したＣＡＮ−ＩＤと一致するＣＡＮ−ＩＤ欄１５１１のＣＡＮ−ＩＤに対応するドメイン間鍵対応欄１５１４の情報を取得し、取得したドメイン間鍵対応欄１５１４の情報が「該当」の場合はステップ１０１３に進み、「非該当」の場合は本処理を終了する。

ステップ１０１３では、付け替え処理部１２が、受信したメッセージが送られてきた車内バス４０のドメインすなわち通信元のドメインを取得する。そして、ステップ１００１で取得したＣＡＮ−ＩＤと一致する通信関係ドメイン欄１５１２のドメインを取得し、この通信関係ドメイン欄１５１２から取得したドメインの中で、通信元のドメイン以外のドメインを通信先のドメインとして取得する。

ステップ１０１４では、ルーティング処理部１３が、受信したメッセージをステップ１０１３で取得した通信先となる全てのドメインの車内バス４０に送信する。

以上のステップ１００１からステップ１０１４により、ＧＷ装置１０は、ＣＡＮ−ＩＤに応じて、ドメイン鍵を用いたＭＡＣが付与されたメッセージのＭＡＣを付け替え、ドメイン間鍵を用いたＭＡＣが付与されたメッセージのＭＡＣを付け替えずに、通信先となるドメインにメッセージを送信できる。ＭＡＣを付け替えない場合は、ＧＷ装置１０の処理負荷を低減できる。

図１０は、図５のステップ２２００２とステップ２２００４の間に、ＭＡＣの検証に用いる鍵の種類を判定する受信制御装置２０−４の詳細な処理フローの例を示す図である。ステップ２２００１とステップ２２００２の各ステップは、実施例１の図５を用いて説明したステップ２２００１とステップ２２００２の各ステップと同様である。

ステップ２２００８では、鍵利用部２２が、利用鍵情報２１４１を参照し、ステップ２２００１で取得したＣＡＮ−ＩＤと一致するＣＡＮ−ＩＤ欄２１４１１のＣＡＮ−ＩＤに対応するドメイン鍵対象欄２１４１３の情報を取得し、ドメイン鍵対象欄２１４１３の情報が「該当」の場合は、ステップ２２００３に進み、「非該当」の場合は、ステップ２２００９に進む。

ステップ２２００９では、鍵利用部２２が、利用鍵情報２１４１を参照し、ステップ２２００１で取得したＣＡＮ−ＩＤと一致するＣＡＮ−ＩＤ欄２１４１１のＣＡＮ−ＩＤに対応する利用鍵欄２１４１２のドメイン間鍵を取得する。

ステップ２２００３からステップ２２００７までの各ステップは、実施例１の図５を用いて説明したステップ２２００３からステップ２２００７までの各ステップと同様である。

以上のステップ２２００１からステップ２２００９により、受信制御装置２０−４は、ＣＡＮ−ＩＤに応じてドメイン鍵、或いはドメイン間鍵を用いたＭＡＣの検証を実施できるようになる。

以上、実施例２によれば、各制御装置２０はドメインごとに共有されるドメイン鍵に加えて、ドメイン間で共有されるドメイン間鍵を管理し、ＧＷ装置１０はＣＡＮ−ＩＤに応じて、ドメイン鍵を用いたＭＡＣが付与されたメッセージのＭＡＣを付け替え、ドメイン間鍵を用いたＭＡＣが付与されたメッセージのＭＡＣを付け替えずに、通信先となるドメインにメッセージを送信することで、ＧＷ装置１０の処理負荷を低減できる。

実施例３として、各制御装置がメッセージに対してナンス（ｎｏｎｃｅ：使い捨て番号）を付与し、ＧＷ装置は受信したメッセージに付与されたナンスが正しいかを判定し、通信先のドメインにメッセージを送信し、ＧＷ装置における処理負荷を低減することを可能とする鍵管理の例を説明する。車載システムの構成は、実施例１の図１を用いて説明した構成であってもよい。

図１２は、図２のステップ２１０３、ステップ１０２、ステップ１０４にナンスの処理を加えたドメイン間通信における概要処理シーケンスの例を示す図である。送信制御装置２０−３のステップ２１０１とステップ２１０２の各ステップは、実施例１の図２を用いて説明したステップ２１０１とステップ２１０２の各ステップと同様である。

ステップ２１０５では、メッセージ生成部２３が、ナンスの値を生成し、メッセージのデータとなる制御パラメータ情報とＭＡＣとナンスをもとに、通信用のメッセージを作成する。ここで、メッセージはヘッダや図示を省略したフッタ等を含んでもよい。ステップ２１０６では、メッセージ生成部２３が、車内通信部２１を用いてステップ２１０５で生成したナンスを含むメッセージを車内バス４０に送信する。

ナンスの値は、例えば通信のシーケンス番号であってもよいし、乱数等であってもよい。送信制御装置２０−３とＧＷ装置１０とが同じナンスの値を得るために、ステップ２１０６より前の任意の時点で送信制御装置２０−３とＧＷ装置１０がナンスの値を通信してもよいし、送信制御装置２０−３とＧＷ装置１０とが同じアルゴリズムを実現する生成回路をそれぞれ備え、それぞれの生成回路でナンスの同じ値を生成してもよいし、送信制御装置２０−３とＧＷ装置１０の同じアルゴリズムを実現する生成回路間でナンスの値を同期する通信を行ってもよい。

ＧＷ装置１０のステップ１０１、ステップ１０３からステップ１０５の各ステップは、実施例１の図２を用いて説明したステップ１０１、ステップ１０３からステップ１０５の各ステップと同様である。ステップ１０７では、付け替え処理部１２が、ナンスの値を生成し、受信したメッセージのナンスの値と生成したナンスの値を比較し、ナンスの値が一致している場合はステップ１０３に進み、ナンスの値が一致していない場合は本処理を終了して、エラー処理に移行する。

ステップ１０８では、ルーティング処理部１３が、ステップ１０４で生成したナンスを含むメッセージを、ステップ１０５で取得した通信先となるドメインの車内バス４０に送信する。この例では、メッセージのフォーマットを統一するためにナンスを含むメッセージとしている。

受信制御装置２０−４のステップ２２０１とステップ２２０２の各ステップは、実施例１の図２を用いて説明したステップ２２０１とステップ２２０２の各ステップと同様である。

なお、ステップ２２０１ではナンスの値が検証されないため、ステップ１０８ではメッセージにナンスを含めずに送信してもよい。逆に、受信制御装置２０−４もナンスの値を生成し、ステップ２２０１で鍵利用部２２が、ＭＡＣの値の一致を比較しての検証に加えて、ナンスの値の一致を比較しての検証を行ってもよい。

以上、実施例３によれば、各制御装置２０はナンスを付与してメッセージを送信し、ＧＷ装置１０は受信したメッセージをナンスで検証可能となり、ＧＷ装置１０の処理負荷を低減できる。

１０ ＧＷ装置
２０ 制御装置
３０ 車両
４０ 車内バス

Claims (12)

1. ２以上のドメイン間でメッセージを中継するゲートウェイ装置であって、
   前記２以上のドメインの中の第１のドメインに対応する第１の改ざん検知符号と第１のデータを含む第１のメッセージを前記第１のドメインから受信し、
   前記２以上のドメインの中の第２のドメインに対応する第２の改ざん検知符号と前記第１のデータを含む第２のメッセージを前記第２のドメインへ送信すること
   を特徴とするゲートウェイ装置。
2. 前記ゲートウェイ装置は、
   さらに、前記２以上のドメインの中の第３のドメインに対応する第３の改ざん検知符号と前記第１のデータを含む第３のメッセージを前記第３のドメインへ送信すること
   を特徴とする請求項１に記載のゲートウェイ装置。
3. 前記ゲートウェイ装置は、
   前記第１のドメインと前記第２のドメインのそれぞれに対応するドメイン鍵を管理し、
   前記第２のドメインに対応するドメイン鍵と前記第１のデータに基づいて前記第２の改ざん検知符号を生成し、
   前記第１のデータと前記第２の改ざん検知符号を含む前記第２のメッセージを生成し、
   前記第２のメッセージを前記第２のドメインへ送信すること
   を特徴とする請求項１に記載のゲートウェイ装置。
4. 前記ゲートウェイ装置は、
   前記第１のメッセージに含まれる前記第１のメッセージを識別するＩＤ情報に基づいて、前記第２のメッセージを生成するか否かを判定し、
   前記第２のドメインを特定すること
   を特徴とする請求項３に記載のゲートウェイ装置。
5. 前記ゲートウェイ装置は、
   前記第１のドメインに対応するドメイン鍵と前記第１のデータに基づいて改ざん検知符号を生成し、
   前記第１のメッセージに含まれる前記第１の改ざん検知符号と比較して一致すると判定した場合、前記第２の改ざん検知符号を生成し、前記第２のメッセージを生成し、前記第２のメッセージを送信すること
   を特徴とする請求項４に記載のゲートウェイ装置。
6. 前記ゲートウェイ装置は、
   使い捨て番号を生成し、
   前記第１のメッセージに含まれる使い捨て番号と比較して一致すると判定した場合、前記第２の改ざん検知符号を生成し、前記第２のメッセージを生成し、前記第２のメッセージを送信すること
   を特徴とする請求項４に記載のゲートウェイ装置。
7. 前記ゲートウェイ装置は、
   メッセージを識別するＩＤ情報に対して送受信される複数のドメインを管理し、
   前記第１のメッセージを識別するＩＤ情報に基づいて、前記第１のメッセージの送受信される複数のドメインを特定し、
   前記特定された複数のドメインの中の前記第１のドメインを除くドメインを送信先のドメインとして特定すること
   を特徴とする請求項５に記載のゲートウェイ装置。
8. 前記ゲートウェイ装置は、
   前記２以上のドメインの中の第４のドメインと前記第１のドメインに共通のドメイン間鍵を管理し、
   前記ＩＤ情報に基づいて、前記第２のメッセージを生成しないと判定した場合、前記ドメイン間鍵の対象であると判定すると、前記第１のメッセージを前記第４のドメインへ送信すること
   を特徴とする請求項７に記載のゲートウェイ装置。
9. １以上の制御装置を含む１以上の第１のドメインと２以上の制御装置を含む１以上の第２のドメインを含む複数のドメイン間でメッセージを中継し、ドメイン鍵に基づく改ざん検知符号を前記メッセージに付与するゲートウェイ装置へ情報を設定する入力装置であって、
   前記複数のドメインの個数の入力枠を表示し、
   前記入力枠に入力された前記ドメイン鍵を前記ゲートウェイ装置へ設定すること
   を特徴とする入力装置。
10. ２以上のドメイン間でメッセージを中継し、前記２以上のドメインの中の第１のドメインと前記第２のドメインのそれぞれに対応するドメイン鍵を管理するゲートウェイ装置の制御方法であって、
    前記第１のドメインに対応する第１の改ざん検知符号と第１のデータを含む第１のメッセージを前記第１のドメインから受信し、
    前記第２のドメインに対応する第２の改ざん検知符号と前記第１のデータを含む第２のメッセージを前記第２のドメインへ送信すること
    を特徴とするゲートウェイ装置の制御方法。
11. 前記第２のメッセージを前記第２のドメインへ送信するために、
    前記第２のドメインに対応するドメイン鍵と前記第１のデータに基づいて前記第２の改ざん検知符号を生成し、
    前記第１のデータと前記第２の改ざん検知符号を含む前記第２のメッセージを生成すること
    を特徴とする請求項１０に記載のゲートウェイ装置の制御方法。
12. 前記第１のメッセージに含まれる前記第１のメッセージを識別するＩＤ情報に基づいて、前記第２のメッセージを生成するか否かを判定し、前記第２のドメインを特定すること
    を特徴とする請求項１１に記載のゲートウェイ装置の制御方法。

Images