図面 (/)

技術 ゲートウェイ装置およびその制御方法

出願人 日立オートモティブシステムズ株式会社
発明者 森田伸義萱島信大和田徹伯田恵輔
出願日 2015年7月15日 (5年4ヶ月経過) 出願番号 2015-141509
公開日 2017年2月2日 (3年9ヶ月経過) 公開番号 2017-028345
状態 特許登録済
技術分野 暗号化・復号化装置及び秘密通信 記憶装置の機密保護 広域データ交換
主要キーワード 通信調停 機能安全 制御パラメータ情報 制御系システム センサ機器 車内バス 各入力枠 情報系システム
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年2月2日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (13)

課題

メッセージ改ざん検知符号を生成する鍵の管理負担の低減をする。

解決手段

2以上のドメイン間でメッセージを中継するゲートウェイ装置であって、前記2以上のドメインの中の第1のドメインに対応する第1の改ざん検知符号と第1のデータを含む第1のメッセージを前記第1のドメインから受信し、前記2以上のドメインの中の第2のドメインに対応する第2の改ざん検知符号と前記第1のデータを含む第2のメッセージを前記第2のドメインへ送信する。

概要

背景

自動車車載ネットワークにおける代表的な標準プロトコルとしてController Area Network(以下、CAN)が普及している。このような車載ネットワークでは、OBD2(On−Board−Diagnostics 2)ポートのような車載ネットワークに直接繋がっているインタフェースに不正な機器を接続し、リプレイ攻撃が行なわれる危険性がある。ここで、リプレイ攻撃とは、通信路上を流れるメッセージ盗聴して事前に取得し、取得したメッセージを再送することで不正な動作を引き起こす攻撃である。

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

通常、これらの脅威に対しては、各情報処理装置間を流れるメッセージに対して、改ざん検知符号としてMAC(Message Authentication Code)を用いたメッセージ認証を実施することが有効とされている。MACは暗号化用の鍵を利用し、所定の暗号アルゴリズムを用いて生成されるため、各制御装置において鍵の管理が必要となる。

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

概要

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

目的

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

効果

実績

技術文献被引用数
1件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

2以上のドメイン間でメッセージ中継するゲートウェイ装置であって、前記2以上のドメインの中の第1のドメインに対応する第1の改ざん検知符号と第1のデータを含む第1のメッセージを前記第1のドメインから受信し、前記2以上のドメインの中の第2のドメインに対応する第2の改ざん検知符号と前記第1のデータを含む第2のメッセージを前記第2のドメインへ送信することを特徴とするゲートウェイ装置。

請求項2

前記ゲートウェイ装置は、さらに、前記2以上のドメインの中の第3のドメインに対応する第3の改ざん検知符号と前記第1のデータを含む第3のメッセージを前記第3のドメインへ送信することを特徴とする請求項1に記載のゲートウェイ装置。

請求項3

前記ゲートウェイ装置は、前記第1のドメインと前記第2のドメインのそれぞれに対応するドメイン鍵を管理し、前記第2のドメインに対応するドメイン鍵と前記第1のデータに基づいて前記第2の改ざん検知符号を生成し、前記第1のデータと前記第2の改ざん検知符号を含む前記第2のメッセージを生成し、前記第2のメッセージを前記第2のドメインへ送信することを特徴とする請求項1に記載のゲートウェイ装置。

請求項4

前記ゲートウェイ装置は、前記第1のメッセージに含まれる前記第1のメッセージを識別するID情報に基づいて、前記第2のメッセージを生成するか否かを判定し、前記第2のドメインを特定することを特徴とする請求項3に記載のゲートウェイ装置。

請求項5

前記ゲートウェイ装置は、前記第1のドメインに対応するドメイン鍵と前記第1のデータに基づいて改ざん検知符号を生成し、前記第1のメッセージに含まれる前記第1の改ざん検知符号と比較して一致すると判定した場合、前記第2の改ざん検知符号を生成し、前記第2のメッセージを生成し、前記第2のメッセージを送信することを特徴とする請求項4に記載のゲートウェイ装置。

請求項6

前記ゲートウェイ装置は、使い捨て番号を生成し、前記第1のメッセージに含まれる使い捨て番号と比較して一致すると判定した場合、前記第2の改ざん検知符号を生成し、前記第2のメッセージを生成し、前記第2のメッセージを送信することを特徴とする請求項4に記載のゲートウェイ装置。

請求項7

前記ゲートウェイ装置は、メッセージを識別するID情報に対して送受信される複数のドメインを管理し、前記第1のメッセージを識別するID情報に基づいて、前記第1のメッセージの送受信される複数のドメインを特定し、前記特定された複数のドメインの中の前記第1のドメインを除くドメインを送信先のドメインとして特定することを特徴とする請求項5に記載のゲートウェイ装置。

請求項8

前記ゲートウェイ装置は、前記2以上のドメインの中の第4のドメインと前記第1のドメインに共通のドメイン間鍵を管理し、前記ID情報に基づいて、前記第2のメッセージを生成しないと判定した場合、前記ドメイン間鍵の対象であると判定すると、前記第1のメッセージを前記第4のドメインへ送信することを特徴とする請求項7に記載のゲートウェイ装置。

請求項9

1以上の制御装置を含む1以上の第1のドメインと2以上の制御装置を含む1以上の第2のドメインを含む複数のドメイン間でメッセージを中継し、ドメイン鍵に基づく改ざん検知符号を前記メッセージに付与するゲートウェイ装置へ情報を設定する入力装置であって、前記複数のドメインの個数入力枠を表示し、前記入力枠に入力された前記ドメイン鍵を前記ゲートウェイ装置へ設定することを特徴とする入力装置。

請求項10

2以上のドメイン間でメッセージを中継し、前記2以上のドメインの中の第1のドメインと前記第2のドメインのそれぞれに対応するドメイン鍵を管理するゲートウェイ装置の制御方法であって、前記第1のドメインに対応する第1の改ざん検知符号と第1のデータを含む第1のメッセージを前記第1のドメインから受信し、前記第2のドメインに対応する第2の改ざん検知符号と前記第1のデータを含む第2のメッセージを前記第2のドメインへ送信することを特徴とするゲートウェイ装置の制御方法。

請求項11

前記第2のメッセージを前記第2のドメインへ送信するために、前記第2のドメインに対応するドメイン鍵と前記第1のデータに基づいて前記第2の改ざん検知符号を生成し、前記第1のデータと前記第2の改ざん検知符号を含む前記第2のメッセージを生成することを特徴とする請求項10に記載のゲートウェイ装置の制御方法。

請求項12

前記第1のメッセージに含まれる前記第1のメッセージを識別するID情報に基づいて、前記第2のメッセージを生成するか否かを判定し、前記第2のドメインを特定することを特徴とする請求項11に記載のゲートウェイ装置の制御方法。

技術分野

0001

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

背景技術

0002

自動車車載ネットワークにおける代表的な標準プロトコルとしてController Area Network(以下、CAN)が普及している。このような車載ネットワークでは、OBD2(On−Board−Diagnostics 2)ポートのような車載ネットワークに直接繋がっているインタフェースに不正な機器を接続し、リプレイ攻撃が行なわれる危険性がある。ここで、リプレイ攻撃とは、通信路上を流れるメッセージ盗聴して事前に取得し、取得したメッセージを再送することで不正な動作を引き起こす攻撃である。

0003

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

0004

通常、これらの脅威に対しては、各情報処理装置間を流れるメッセージに対して、改ざん検知符号としてMAC(Message Authentication Code)を用いたメッセージ認証を実施することが有効とされている。MACは暗号化用の鍵を利用し、所定の暗号アルゴリズムを用いて生成されるため、各制御装置において鍵の管理が必要となる。

0005

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

先行技術

0006

特開2014−183395号公報

発明が解決しようとする課題

0007

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

0008

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

課題を解決するための手段

0009

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

発明の効果

0010

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

図面の簡単な説明

0011

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

0012

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

0013

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

0014

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

0015

図1は、車載システムの構成の例を示す図である。車両30に搭載されているGW装置10は、車内バス40を介して、制御装置20と互いに接続されている。なお、車内バス40−1、40−2、・・・40−n(nは3以上の自然数)を区別なく代表して表す場合は車内バス40と記載し、制御装置20−1a、20−1b、20−2、・・・20−nを区別なく代表して表す場合は制御装置20と記載する。

0016

ここで、車内バス40としては、例えば、CANやCANFD(Flexible Data−Rate)であってもよい。また、車内バス40の個数は2であってもよく、ドメインの個数も2であってもよい。

0017

GW装置10は、車外通信部11、付け替え処理部12、ルーティング処理部13、車内通信部14、鍵関連情報記憶部15から成る。車外通信部11はネットワーク有線無線)50を介して車両30の外の装置、或いはセンタ等と接続し、車外とのメッセージの送受信を行なう。付け替え処理部12は受信したメッセージがMACの付け替え対象なのかどうかを判定する。

0018

ルーティング処理部13は付け替え処理部12の判定結果に基づいて通信先の制御装置20を特定し、送信するメッセージを作成する。車内通信部14はルーティング処理部13が生成したメッセージを該当するドメインの車内バス40に送信する。鍵関連情報記憶部15はMAC付け替え判定情報151と鍵情報152を保持する。

0019

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

0020

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

0021

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

0022

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

0023

また、利用鍵情報241、MAC付け替え判定情報151、鍵情報152のそれぞれの情報は、図示を省略した入力装置から予め設定されてもよいし、ネットワーク50経由で予め設定されてもよい。

0024

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

0025

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

0026

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

0027

ステップ2103では、メッセージ生成部23が、メッセージのデータとなるステップ2101で取得した制御パラメータ情報と、ステップ2102で算出したMACをもとに、通信用のメッセージを生成する。なお、メッセージはヘッダや図示を省略したフッタ等を含んでもよい。ステップ2104では、メッセージ生成部23が、車内通信部21を用いてステップ2103で生成したメッセージを車内バス40に送信する。

0028

ステップ101では、付け替え処理部12は、車内通信部14から受信したメッセージのID情報がMACの付け替え対象であるのか否かを、MAC付け替え判定情報151をもとに判定する。受信したメッセージがMACの付け替え対象と判定した場合はステップ102に進み、MACの付け替え対象ではないと判定した場合は処理を終了し、エラー処理移行する。

0029

図7に、ステップ101で参照されるMAC付け替え判定情報151のテーブル構成の例を示す。CAN−ID欄1511は、メッセージを識別する情報すなわちメッセージのID情報を示す。図7では、CAN−IDを情報の例とし、CAN−ID欄1511としたが、メッセージを識別可能な情報であればCAN−ID以外の情報を用いてもよい。

0030

通信関係ドメイン欄1512は、CAN−ID欄1511の値を使用するメッセージで通信関係のあるドメインを示す。MAC付け替え要否欄1513は、CAN−ID欄1511の値を使用するメッセージがMACの付け替え対象なのか、非対象なのかを示す。MAC付け替え要否欄1513の値が「要」の場合はメッセージに付与されたMACは付け替えの対象となり、「否」の場合はメッセージに付与されたMACは付け替えの対象とならない。

0031

ドメイン間鍵対象欄1514は、CAN−ID欄1511の値を使用するメッセージがドメイン間鍵の対象であるのか、非対象であるのかを示す。ドメイン間鍵対象欄1514の値が「該当」の場合はドメイン間鍵を用いてMACを算出する対象であることを示し、「非該当」の場合はドメイン間鍵を用いないことを示す。

0032

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

0033

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

0034

図6に、ステップ102で参照される鍵情報152のテーブル構成の例を示す。ドメイン欄1521は、GW装置10によって分割される車載ネットワーク(車内バス40)のドメインを示す。ドメイン鍵欄1522は、ドメイン欄1521のドメインごとに設定されるドメイン鍵を示す。

0035

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

0036

ステップ103では、付け替え処理部12が、受信したメッセージが送られてきた車内バス40のドメインと、通信関係ドメイン欄1512をもとに、通信先のドメインを特定し、特定した通信先のドメインをもとに鍵情報152から取得したドメイン鍵を用いてMACを算出する。ステップ104では、付け替え処理部12が、受信したメッセージのMACをステップ103で生成したMACに付け替える。

0037

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

0038

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

0039

以下のステップ2201からステップ2202は受信制御装置20−4の処理である。ステップ2201では、鍵利用部22が、利用鍵情報241から受信制御装置20−4が接続されているドメインのドメイン鍵を取得し、受信したメッセージ(ヘッダ、データ)をもとにMACを算出し、算出したMACと受信したメッセージに付与されたMACを比較する。

0040

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

0041

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

0042

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

0043

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

0044

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

0045

ステップ21003では、鍵利用部22が、ステップ21002で取得したCAN−IDがメッセージ認証の対象であるのか否かを判定する。メッセージ認証の対象となる場合はステップ21004に進み、メッセージ認証の対象とならない場合はステップ21006に進む。なお、予めメッセージ認証の対象となるCAN−IDのリストが設定され、図示を省略したメモリ等に記憶されている。

0046

ステップ21004では、鍵利用部22が、利用鍵情報241から送信制御装置20−3の接続されたドメインのドメイン鍵を取得する。ステップ21005では、鍵利用部22が、ステップ21004で取得したドメイン鍵を用いてMACを算出する。

0047

ステップ21006では、メッセージ生成部23が、ステップ21003においてメッセージ認証の対象外となった場合は、ステップ21001で取得した制御パラメータ情報をもとに通信用メッセージを生成する。一方、ステップ21003においてメッセージ認証の対象となった場合は、ステップ21001で取得した制御パラメータ情報と、ステップ21005で算出したMACをもとに、通信用のメッセージを生成する。

0048

ステップ21007では、メッセージ生成部23が、車内通信部21を用いて、ステップ21006で生成したメッセージを車内バス40に送信する。

0049

以上のステップ21001からステップ21007により、送信制御装置20−3は、ドメイン鍵を用いて算出したMACを付与したメッセージを車内バス40に送信できる。

0050

図4は、図2のステップ101からステップ106までの、GW装置10の詳細な処理フローの例を示す図である。ステップ1001では、付け替え処理部12が、受信したメッセージに付与されたCAN−IDを取得する。

0051

ステップ1002では、付け替え処理部12が、MAC付け替え判定情報151を参照し、ステップ1001で取得したCAN−IDと一致するCAN−ID欄1511のCAN−IDに対応するMAC付け替え要否1513欄の情報を取得し、取得したMAC付け替え要否欄1513の情報が「要」の場合はステップ1003に進み、「否」の場合は本処理を終了する。

0052

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

0053

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

0054

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

0055

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

0056

ステップ1007では、付け替え処理部12が、ステップ1001で取得したCAN−IDと一致するCAN−ID欄1511のCAN−IDに対応する通信関係欄ドメイン1512のドメインを取得する。この通信関係ドメイン欄1512から取得したドメインの中で、ステップ1003で取得した通信元のドメイン以外のドメインを通信先のドメインとして取得する。そして、取得した通信先のドメインと一致するドメイン欄1521のドメインに対応するドメイン鍵1522のドメイン鍵を鍵情報152から取得する。

0057

ステップ1008では、付け替え処理部12が、受信したメッセージとステップ1007で取得した通信先のドメインのドメイン鍵を用いてMACを算出する。ステップ1009では、付け替え処理部12は、受信したメッセージに付与されたMACの代わりに、ステップ1008で算出したMACを付与し、メッセージを再生成する。

0058

ステップ1010では、ルーティング処理部13が、ステップ1009で生成したメッセージをステップ1007で取得した通信先となるドメインの車内バス40に送信する。

0059

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

0060

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

0061

以上のステップ1001からステップ1011により、GW装置10はMACの付け替えが必要なメッセージに対して、MACを付け替えた上で、通信先となるドメインにメッセージを転送できる。

0062

図5は、図2のステップ2201からステップ2202までの、受信制御装置20−4の詳細な処理フローの例を示す図である。ステップ22001では、鍵利用部22が、受信したメッセージに付与されたCAN−IDを取得する。

0063

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

0064

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

0065

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

0066

以上のステップ22001からステップ22007により、受信制御装置20−4は、車内バス40を介して受信したメッセージに対してドメイン鍵を用いてMACを検証し、走行制御を実施できる。

0067

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

0068

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

0069

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

0070

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

0071

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

0072

図8は、図3のステップ21003とステップ21005の間に、MACの算出に用いる鍵の種類を判定する送信制御装置20−3の詳細な処理フローの例を示す図である。ステップ21001からステップ21003までの各ステップは、実施例1の図3を用いて説明したステップ21001からステップ21003までの各ステップと同様である。

0073

ステップ21008では、鍵利用部22が、図11を用いて説明する利用鍵情報2141を参照し、ステップ21002で取得したCAN−IDがドメイン鍵の対象であるのか否かを判定し、ドメイン鍵の対象である場合はステップ21004に進み、ドメイン鍵の対象ではない場合はステップ21009に進む。

0074

図11に、ステップ21008で参照される利用鍵情報2141のテーブル構成の例を示す。CAN−ID欄21411は、メッセージを識別する情報を示す。メッセージを識別可能な情報であればCAN−ID以外の情報を用いてもよい。利用鍵欄21412は、CAN−ID欄21411のCAN−IDに応じてMACの生成に用いる鍵情報を示す。ドメイン鍵対象欄21413はCAN−ID欄21411のCAN−IDで識別されるメッセージが、ドメイン鍵の対象であるのか否かを示す。

0075

例えば、ステップ21008において、鍵利用部22は、ステップ21002で取得したCAN−IDと一致するCAN−ID欄21411のCAN−IDに対応するドメイン鍵対象21413の情報を取得し、ドメイン鍵対象21413の情報が「該当」の場合は、MACの生成においてドメイン鍵を利用し、「非該当」の場合は、MACの生成においてドメイン間鍵を利用する。

0076

このため、ステップ21009では、鍵利用部22が、ステップ21002で取得したCAN−IDと一致するCAN−ID欄21411のCAN−IDに対応する利用鍵欄21412のドメイン間鍵を取得する。

0077

ステップ21004からステップ21007までの各ステップは、実施例1の図3を用いて説明したテップ21004からステップ21007までの各ステップと同様である。

0078

以上のステップ21001からステップ21009により、送信制御装置20−3は、メッセージのCAN−IDに応じてドメイン鍵、或いはドメイン間鍵を用いたMACを生成できるようになる。

0079

図9は、図4のステップ1002において、MAC付け替え対象ではないと判定された場合に、ドメイン間鍵の対象メッセージであるのか否かを判定するGW装置10の詳細な処理フローの例を示す図である。ステップ1001、およびステップ1003からステップ1011までの各ステップは、実施例1の図4を用いて説明したステップ1001、およびステップ1003からステップ1011までの各ステップと同様である。

0080

ステップ1002では、付け替え処理部12が、MAC付け替え判定情報151を参照し、ステップ1001で取得したCAN−IDと一致するCAN−ID欄1511のCAN−IDに対応するMAC付け替え要否欄1513の情報を取得し、取得したMAC付け替え要否欄1513の情報が「要」の場合はステップ1003に進み、「否」の場合はステップ1012に進む。

0081

ステップ1012では、付け替え処理部12が、MAC付け替え判定情報151を参照し、ステップ1001で取得したCAN−IDと一致するCAN−ID欄1511のCAN−IDに対応するドメイン間鍵対応欄1514の情報を取得し、取得したドメイン間鍵対応欄1514の情報が「該当」の場合はステップ1013に進み、「非該当」の場合は本処理を終了する。

0082

ステップ1013では、付け替え処理部12が、受信したメッセージが送られてきた車内バス40のドメインすなわち通信元のドメインを取得する。そして、ステップ1001で取得したCAN−IDと一致する通信関係ドメイン欄1512のドメインを取得し、この通信関係ドメイン欄1512から取得したドメインの中で、通信元のドメイン以外のドメインを通信先のドメインとして取得する。

0083

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

0084

以上のステップ1001からステップ1014により、GW装置10は、CAN−IDに応じて、ドメイン鍵を用いたMACが付与されたメッセージのMACを付け替え、ドメイン間鍵を用いたMACが付与されたメッセージのMACを付け替えずに、通信先となるドメインにメッセージを送信できる。MACを付け替えない場合は、GW装置10の処理負荷を低減できる。

0085

図10は、図5のステップ22002とステップ22004の間に、MACの検証に用いる鍵の種類を判定する受信制御装置20−4の詳細な処理フローの例を示す図である。ステップ22001とステップ22002の各ステップは、実施例1の図5を用いて説明したステップ22001とステップ22002の各ステップと同様である。

0086

ステップ22008では、鍵利用部22が、利用鍵情報2141を参照し、ステップ22001で取得したCAN−IDと一致するCAN−ID欄21411のCAN−IDに対応するドメイン鍵対象欄21413の情報を取得し、ドメイン鍵対象欄21413の情報が「該当」の場合は、ステップ22003に進み、「非該当」の場合は、ステップ22009に進む。

0087

ステップ22009では、鍵利用部22が、利用鍵情報2141を参照し、ステップ22001で取得したCAN−IDと一致するCAN−ID欄21411のCAN−IDに対応する利用鍵欄21412のドメイン間鍵を取得する。

0088

ステップ22003からステップ22007までの各ステップは、実施例1の図5を用いて説明したステップ22003からステップ22007までの各ステップと同様である。

0089

以上のステップ22001からステップ22009により、受信制御装置20−4は、CAN−IDに応じてドメイン鍵、或いはドメイン間鍵を用いたMACの検証を実施できるようになる。

0090

以上、実施例2によれば、各制御装置20はドメインごとに共有されるドメイン鍵に加えて、ドメイン間で共有されるドメイン間鍵を管理し、GW装置10はCAN−IDに応じて、ドメイン鍵を用いたMACが付与されたメッセージのMACを付け替え、ドメイン間鍵を用いたMACが付与されたメッセージのMACを付け替えずに、通信先となるドメインにメッセージを送信することで、GW装置10の処理負荷を低減できる。

0091

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

0092

図12は、図2のステップ2103、ステップ102、ステップ104にナンスの処理を加えたドメイン間通信における概要処理シーケンスの例を示す図である。送信制御装置20−3のステップ2101とステップ2102の各ステップは、実施例1の図2を用いて説明したステップ2101とステップ2102の各ステップと同様である。

0093

ステップ2105では、メッセージ生成部23が、ナンスの値を生成し、メッセージのデータとなる制御パラメータ情報とMACとナンスをもとに、通信用のメッセージを作成する。ここで、メッセージはヘッダや図示を省略したフッタ等を含んでもよい。ステップ2106では、メッセージ生成部23が、車内通信部21を用いてステップ2105で生成したナンスを含むメッセージを車内バス40に送信する。

0094

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

0095

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

0096

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

0097

受信制御装置20−4のステップ2201とステップ2202の各ステップは、実施例1の図2を用いて説明したステップ2201とステップ2202の各ステップと同様である。

0098

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

実施例

0099

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

0100

10GW装置
20制御装置
30 車両
40 車内バス

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ