(57)【要約】【課題】ネットワークにおいて共通に使用される鍵に異常が発生したとき、効率的に鍵を再配布する。【解決手段】鍵配布部１３は、ネットワークに接続された通信装置間において共通に使用される通信鍵を、ネットワークを介して当該ネットワークに接続された通信装置に配布する。鍵状態管理部１４は、配布された通信鍵の状態を管理する。鍵配布部１３は、通信鍵の状態に異常が発生したとき、通信鍵を正常に保持していない通信装置に通信鍵を個別に再配布するか、ネットワークに接続された通信装置に新たな通信鍵を一斉に配布するかを所定の条件に応じて選択する。【選択図】図２
2016092716.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された通信装置間において共通に使用される通信鍵を、前記ネットワークを介して当該ネットワークに接続された通信装置に配布する鍵配布部と、
前記通信装置に配布された通信鍵の状態を管理する鍵状態管理部と、を備え、
前記鍵配布部は、前記通信鍵の状態に異常が発生したとき、前記通信鍵を正常に保持していない前記通信装置に前記通信鍵を個別に再配布するか、前記ネットワークに接続された通信装置に新たな通信鍵を一斉に配布するかを所定の条件に応じて選択することを特徴とする鍵管理通信装置。
【請求項２】
前記鍵状態管理部は、前記ネットワークに接続された通信装置の内、配布された通信鍵を正常に保持していない通信装置の数を検出し、
前記鍵配布部は、前記通信鍵を正常に保持していない通信装置の数が設定数未満のとき前記通信鍵を正常に保持していない通信装置に前記通信鍵を個別に再配布し、当該設定数以上のとき前記ネットワークに接続された通信装置に新たな通信鍵を一斉に配布することを特徴とする請求項１に記載の鍵管理通信装置。
【請求項３】
前記鍵状態管理部は、メッセージの送出を停止した通信装置、異常なメッセージ認証コードを付加したメッセージを送出した通信装置を、配布された通信鍵を正常に保持していない通信装置であると検出することを特徴とする請求項２に記載の鍵管理通信装置。
【請求項４】
前記鍵配布部は、個別に再配布する場合、個別配布であること示すフラグ又は再配布の回数を示すカウント値が付加された通信鍵をブロードキャストし、通信鍵を一斉に配布する場合、前記フラグ又は前記カウント値が付加されない通信鍵をブロードキャストすることを特徴とする請求項１から３のいずれかに記載の鍵管理通信装置。
【請求項５】
ネットワークに接続された通信装置間において共通に使用される通信鍵を、当該ネットワークを介して当該ネットワークに接続された通信装置に配布する鍵配布ステップと、
配布された通信鍵の状態を管理する鍵状態管理ステップと、を備え、
前記鍵配布ステップは、前記通信鍵の状態に異常が発生したとき、前記通信鍵を正常に保持していない通信装置に前記通信鍵を個別に再配布するか、前記ネットワークに接続された通信装置に新たな通信鍵を一斉に配布するかを所定の条件に応じて選択することを特徴とする鍵配布方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムにおいて使用する通信鍵を配布する鍵管理通信装置および鍵配布方法に関する。
【背景技術】
【０００２】
近年、車両の電装化が進み、車載ネットワークにおけるセキュリティ確保の重要性が増してきている。車載ネットワークとしてＣＡＮ（Controller Area Network）が普及している。ＣＡＮにおいて、送信メッセージにメッセージ認証コード（Message Authentication Code;ＭＡＣ）を付加して、通信データのセキュリティを向上させることが提案されている。ＭＡＣは送信側のノードで生成され、受信側のノードで検証される。ＭＡＣの生成および検証には送信側のノードと受信側のノードとの間で同じ鍵を共有している必要がある。
【０００３】
車載ネットワークではイグニッションオン時に、鍵管理用のＥＣＵ（Electronic Control Unit)が鍵を生成して、車載ネットワーク内のＥＣＵに配布する手法が一般的である（例えば特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−３４１５２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
鍵の配布を受けたＥＣＵにおいて、ファームウェアのアップデート等により再起動されると、揮発性のメモリに保持されている鍵が消去される。またＥＣＵは、配布された鍵を正常に受信できない場合もある。それらの場合、鍵管理用のＥＣＵは鍵を再配布する必要が発生する。
【０００６】
本発明はこうした状況に鑑みなされたものであり、その目的は、ネットワークにおいて共通に使用される鍵に異常が発生したとき、鍵を効率的に再配布する技術を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様の鍵管理通信装置は、ネットワークに接続された通信装置間において共通に使用される通信鍵を、前記ネットワークを介して当該ネットワークに接続された通信装置に配布する鍵配布部と、前記通信装置に配布された通信鍵の状態を管理する鍵状態管理部と、を備える。前記鍵配布部は、前記通信鍵の状態に異常が発生したとき、前記通信鍵を正常に保持していない通信装置に前記通信鍵を個別に再配布するか、前記ネットワークに接続された通信装置に新たな通信鍵を一斉に配布するかを所定の条件に応じて選択する。
【０００８】
なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システム、コンピュータプログラム、コンピュータプログラムを記録した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００９】
本発明によれば、ネットワークにおいて共通に使用される鍵を再配布する際、鍵を効率的に再配布できる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施の形態に係るＣＡＮシステムの構成の一例を示す図である。
【図２】本発明の実施の形態に係る鍵管理用のＥＣＵの構成例を示す図である。
【図３】本発明の実施の形態に係る一般のＥＣＵの構成例を示す図である。
【図４】セッション鍵の一斉配布を説明するためのシーケンスチャートである。
【図５】セッション鍵の状態を判定する処理、及び個別配布と一斉配布の選択処理を説明するためのフローチャートである。
【図６】図５のステップＳ２０のサブルーチンを示すフローチャートである。
【図７】セッション鍵の個別配布を説明するためのシーケンスチャートである。
【図８】変形例１に係る個別配布と一斉配布の選択処理を説明するためのフローチャートである。
【図９】変形例２に係る個別配布と一斉配布の選択処理を説明するためのフローチャートである。
【図１０】図５の個別配布と一斉配布の選択処理と図８の個別配布と一斉配布の選択処理を組み合わせた処理を説明するためのフローチャートである。
【発明を実施するための形態】
【００１１】
本発明の実施の形態は、車両内に搭載される複数のＥＣＵがノードとして接続された車載ネットワークに関する。以下、このようなネットワークとしてのＣＡＮシステムを例示して本発明の実施の形態を説明する。ＣＡＮはバス型ネットワークを採用しており、バスに接続される各ＥＣＵからのメッセージは、バスに接続される全てのＥＣＵにブロードキャストされる。
【００１２】
図１は、本発明の実施の形態に係るＣＡＮシステム１の構成の一例を示す図である。当該ＣＡＮシステム１ではＣＡＮバス３０に、鍵管理用のＥＣＵ１０と一般のＥＣＵ２０ａ−２０ｃが接続されている。以下の説明において、一般のＥＣＵの全て、または複数の一般のＥＣＵのうちの任意のものを「一般のＥＣＵ２０」と称することがある。ＣＡＮでは、ＣＳＭＡ／ＣＡ(Carrier Sense Multiple Access with Collision Avoidance)と呼ばれるアクセス制御方式が採用されており、ＣＡＮバス３０に対して最初に送信を開始したＥＣＵが送信権を取得する。なお同時に複数のＥＣＵが送信した場合は、通信調停（bus arbitration）が行われる。
【００１３】
図２は、本発明の実施の形態に係る鍵管理用のＥＣＵ１０の構成例を示す図である。鍵管理用のＥＣＵ１０はアプリケーション処理部１１、暗号処理部１２、鍵配布部１３、鍵状態管理部１４、車両状態検出部１５、配布履歴記憶部１６及びメッセージ処理部１７を備える。これらはハードウェア資源とソフトウェア資源の協働、又はハードウェア資源単体により実現できる。ハードウェア資源としてプロセッサ、ＲＯＭ、ＲＡＭ、ＣＡＮコントローラ、レシーバ、その他のＬＳＩを利用できる。ソフトウェア資源としてオペレーティングシステム、アプリケーション等のプログラムを利用できる。
【００１４】
アプリケーション処理部１１はアプリケーション層の処理を実行する。即ち送信するメッセージに含めるデータを生成し、受信したメッセージに含まれるデータを解釈する。暗号処理部１２はメッセージのセキュリティに関する処理を実行する。鍵管理用のＥＣＵ１０から一般のＥＣＵ２０へメッセージが送信される時、暗号処理部１２はアプリケーション処理部１１から受け取ったデータに対して暗号化および／または署名の付加を実行する。本実施の形態では署名としてＭＡＣを使用する。またメッセージが受信される時、暗号処理部１２はメッセージ処理部１７から受け取った暗号化データに対する復号および／または署名の検証を実行する。
【００１５】
暗号処理部１２はマスタ鍵保持部１２１、鍵生成部１２２、セッション鍵保持部１２３、暗号・復号部１２４及びＭＡＣ生成・検証部１２５を含む。暗号処理部１２は専用のハードウェアエンジンで構成されてもよい。
【００１６】
マスタ鍵保持部１２１は、ＣＡＮシステム１に接続された全てのＥＣＵに共通の１つのマスタ鍵（共通鍵）を保持する。このマスタ鍵は不揮発性のメモリに保持され、車両がイグニッションオフの状態でも保持され続ける。鍵生成部１２２はセッション鍵、暗号鍵およびＭＡＣ鍵を生成する。各鍵の生成方法は後述する。
【００１７】
セッション鍵保持部１２３は鍵生成部１２２により生成されたセッション鍵を保持する。セッション鍵は、ＣＡＮシステム１に接続されたＥＣＵ間において共通に使用される通信鍵である。セッション鍵は車両のイグニッションオン時に生成され、イグニッションオフ時に消滅する有効期限がある鍵である。なおセッション鍵に使用回数の制限および／または使用期間の制限を設けてもよい。例えば生成から４８時間経過で自動的に消滅するようにしてもよい。セッション鍵は短期間で消滅する性質の鍵であり、基本的に揮発性のメモリに保持される。
【００１８】
暗号・復号部１２４は鍵生成部１２２により生成された暗号鍵を用いて、送信するメッセージに含める暗号対象とすべきデータ部分を暗号化する。また当該暗号鍵を用いて、受信されたメッセージに含まれる暗号化されたデータ部分を復号する。この暗号化には例えば、ＡＥＳ暗号アルゴリズムを使用できる。
【００１９】
ＭＡＣ生成・検証部１２５は鍵生成部１２２により生成されたＭＡＣ鍵を用いて、送信されるメッセージに含める署名対象とするデータ部分のＭＡＣを生成し、当該メッセージに付加する。また当該ＭＡＣ鍵を用いて、受信されたメッセージに含まれる署名対象となっているデータ部分のＭＡＣを生成し、当該メッセージに付加されたＭＡＣと比較して、両者が一致するか否か検証する。一致すれば検証が成功、一致しなければ検証が失敗となる。ＭＡＣの生成にはＭＡＣ生成アルゴリズムを使用する。ＭＡＣ生成アルゴリズムにはハッシュ関数を使う方式（ＨＭＡＣ）や、ブロック暗号アルゴリズムを使う方式（ＣＭＡＣ）等がある。
【００２０】
鍵配布部１３は暗号処理部１２により生成されたセッション鍵を、ＣＡＮバス３０を介して、ＣＡＮバス３０に接続された一般のＥＣＵ２０に配布する。車両がイグニッションオンされると、鍵配布部１３はセッション鍵の生成を暗号処理部１２に依頼（指示）し、暗号処理部１２により生成されたセッション鍵を取得する。鍵配布部１３は取得したセッション鍵を、ＣＡＮバス３０に接続されたＥＣＵ２０に一斉に配布する。
【００２１】
鍵状態管理部１４は、自装置から一般のＥＣＵ２０へ配布したセッション鍵の状態を管理する。車両状態検出部１５はＥＣＵ２０から車両の状態に関する情報を取得する。例えばイグニッションスイッチの状態、パーキングブレーキの状態などの情報を担当のＥＣＵ２０から取得する。車両状態検出部１５は取得した情報を鍵状態管理部１４に渡す。
【００２２】
配布履歴記憶部１６はセッション鍵の配布履歴を記憶する。また配布履歴記憶部１６は、セッション鍵の保持状態に異常が発生したＥＣＵ２０の履歴を記憶する。その際、ＥＣＵ２０ごとにセッション鍵の保持状態に異常が発生した回数を記憶する。この回数は、不揮発性のメモリで管理される累積値である。
【００２３】
メッセージ処理部１７は送信時、アプリケーション処理部１１から受け取った平文のアプリケーションデータ、又は暗号処理部１２から受け取った暗号化された及び／又は署名が付加されたアプリケーションデータを受け取る。鍵配布部１３及び鍵状態管理部１４からは、セッション鍵などを含む管理データを受け取る。メッセージ処理部１７は受け取ったデータと、メッセージＩＤを含むメッセージを生成し、生成したメッセージをＣＡＮバス３０にブロードキャストする。なお本実施の形態では説明を単純化するため、メッセージＩＤとＥＣＵのＩＤが一意に対応しているシステムを想定する。従ってメッセージを受信したＥＣＵは、メッセージＩＤを検出することにより送信元のＥＣＵを特定できるものとする。
【００２４】
メッセージ処理部１７は、一般のＥＣＵ２０からメッセージを受信した時、メッセージからデータを取り出し、アプリケーション処理部１１、鍵状態管理部１４又は車両状態検出部１５に渡す。データが暗号化されている場合および／またはデータに署名が付加されている場合は、暗号処理部１２に渡す。
【００２５】
図３は、本発明の実施の形態に係る一般のＥＣＵ２０の構成例を示す図である。ＥＣＵ２０はアプリケーション処理部２１、暗号処理部２２、鍵状態管理部２４及びメッセージ処理部２７を備える。ＥＣＵ２０の構成は基本的に、鍵管理用のＥＣＵ１０から鍵配布部１３、車両状態検出部１５及び配布履歴記憶部１６を取り除いた構成である。
【００２６】
本実施の形態ではＥＣＵ１０の鍵配布部１３はセッション鍵を、ＣＡＮバス３０に接続された全てのＥＣＵ２０に一斉に配布するか（一斉配布）、特定のＥＣＵ２０に個別に配布するか（個別配布）を使い分けることができる。
【００２７】
図４は、セッション鍵の一斉配布を説明するためのシーケンスチャートである。上述のように、セッション鍵を生成するトリガの一例としての車両のイグニッションオン時には、鍵配布部１３は一斉配布を選択する。鍵管理用のＥＣＵ１０において鍵配布部１３から暗号処理部１２に、セッション鍵の生成指示がなされると、鍵生成部１２２はセッション鍵ＳＫを生成する（Ｓ１０）。本実施の形態では鍵生成部１２２は乱数を発生させて、当該乱数に基づきセッション鍵ＳＫを生成する。鍵生成部１２２は生成したセッション鍵ＳＫをセッション鍵保持部１２３に格納する。なお、暗号鍵を生成するためのマスタ鍵と、ＭＡＣを生成するためのマスタ鍵の二種類を予め用意しておいてもよい。
【００２８】
鍵生成部１２２は、マスタ鍵保持部１２１に保持されるマスタ鍵ＣＫに所定の暗号鍵生成関数ＫＧＦｅを適用して暗号鍵ＥＫを生成する。また鍵生成部１２２は当該マスタ鍵ＣＫに所定のＭＡＣ鍵生成関数ＫＧＦｍを適用してＭＡＣ鍵ＭＫを生成する（Ｓ１１）。暗号・復号部１２４はセッション鍵ＳＫを暗号鍵ＥＫを用いて暗号化して暗号化セッション鍵ＣＴを生成する。ＭＡＣ生成・検証部１２５はＭＡＣ鍵ＭＫを用いて、暗号化セッション鍵ＣＴを対象とした署名Ｓｉｇ（ＭＡＣ）を生成する（Ｓ１２）。ＭＡＣ生成・検証部１２５はＭＡＣ鍵ＭＫを用いて、暗号化セッション鍵ＣＴを対象とした署名Ｓｉｇ（ＭＡＣ）を生成する。なお、ＭＡＣ生成・検証部１２５がＭＡＣ鍵ＭＫを用いてセッション鍵ＳＫを対象とした署名Ｓｉｇ（ＭＡＣ）を生成し、当該署名Ｓｉｇ（ＭＡＣ）が付加されたセッション鍵ＳＫを、暗号・復号部１２４が暗号鍵ＥＫを用いて暗号化する方式を採用してもよい。
【００２９】
鍵配布部１３は、生成された暗号化セッション鍵ＣＴに署名Ｓｉｇ（ＭＡＣ）を連結したデータ列をメッセージ処理部１７に渡す。メッセージ処理部１７は、当該データ列とメッセージＩＤを含むメッセージを生成してＣＡＮバス３０にブロードキャストする（Ｓ１３）。
【００３０】
一般のＥＣＵ２０のメッセージ処理部２７は、鍵管理用のＥＣＵ１０からブロードキャストされたメッセージを受信する。メッセージ処理部２７は受信したメッセージ内のメッセージＩＤを検出することにより、鍵管理用のＥＣＵ１０からのメッセージであることを認識できる。メッセージ処理部２７はメッセージから取り出したデータ列を暗号処理部２２に渡し、鍵管理用のＥＣＵ１０からメッセージを受信したことを鍵状態管理部２４に通知する。
【００３１】
メッセージ処理部２７からデータ列を渡されると、鍵生成部２２２は、マスタ鍵保持部２２１に保持されるマスタ鍵ＣＫに所定の暗号鍵生成関数ＫＧＦｅを適用して暗号鍵ＥＫを生成する。また鍵生成部２２２は当該マスタ鍵ＣＫに所定のＭＡＣ鍵生成関数ＫＧＦｍを適用してＭＡＣ鍵ＣＫを生成する（Ｓ２０）。暗号鍵生成関数ＫＧＦｅ及びＭＡＣ鍵生成関数ＫＧＦｍは、鍵管理用のＥＣＵ１０で使用されるものと同じものである。
【００３２】
本実施の形態において、ＣＡＮシステム１では全ＥＣＵ間でカウント値による同期がとられている。即ち定期的に同期メッセージがブロードキャストされ、各ＥＣＵが当該同期メッセージに応じてカウント値を更新している。上記の暗号鍵生成関数ＫＧＦｅ及びＭＡＣ鍵生成関数ＫＧＦｍには、当該カウント値をパラメータとして含む項があり、同期がずれたＥＣＵでは有効な暗号鍵ＥＫ及びＭＡＣ鍵ＭＫを生成できない処理が行われる。
【００３３】
暗号処理部２２は、メッセージ処理部２７から渡されたデータ列に含まれる暗号化セッション鍵ＣＴと署名Ｓｉｇ（ＭＡＣ）を分離する。ＭＡＣ生成・検証部２２５はＭＡＣ鍵ＭＫを用いて、分離された暗号化セッション鍵ＣＴを対象とした署名Ｓｉｇ（ＭＡＣ）を生成する（Ｓ２１）。ＭＡＣ生成・検証部２２５は生成した署名Ｓｉｇ（ＭＡＣ）と、データ列から分離した署名Ｓｉｇ（ＭＡＣ）とを比較する（Ｓ２２）。
【００３４】
両者が一致する場合（Ｓ２２のＹ）、暗号・復号部２２４は、メッセージ処理部２７から渡されたデータ列に含まれる暗号化セッション鍵ＣＴを暗号鍵ＥＫを用いて復号する（Ｓ２３）。これによりメッセージから平文のセッション鍵ＳＫを取り出す。暗号・復号部２２４は、取り出したセッション鍵ＳＫをセッション鍵保持部２２３に格納すると共に、セッション鍵ＳＫの取り出しに成功したことを鍵状態管理部２４に通知する。メッセージ処理部２７は、セッション鍵ＳＫの取り出しに成功したことを示す情報とメッセージＩＤを含むメッセージを生成し、ＣＡＮバス３０にブロードキャストする（Ｓ２４）。鍵管理用のＥＣＵ１０は当該メッセージを受信して、送信先のＥＣＵ２０がセッション鍵ＳＫを正常に取得したことを認識する。
【００３５】
ステップＳ２２において、ＭＡＣ生成・検証部２２５が生成した署名Ｓｉｇ（ＭＡＣ）と、データ列から分離した署名Ｓｉｇ（ＭＡＣ）とが一致しない場合（Ｓ２２のＮ）、ステップＳ２３の処理、及びステップＳ２４の処理をスキップする。なお、セッション鍵ＳＫの取得に失敗したことをＥＣＵ１０に通知するための通知処理を行ってもよい。また鍵管理用のＥＣＵ１０が暗号化セッション鍵ＣＴを配布してから、設定された期間内にセッション鍵ＳＫの取得に成功したことを示す通知を受信できなかった場合、セッション鍵ＳＫの取得に失敗したとみなす（鍵ロストなど、セッション鍵の状態に異常が発生したとみなす）運用でもよい。
【００３６】
本実施の形態では、鍵管理用のＥＣＵ１０の鍵配布部１３は、セッション鍵の状態に異常が発生したとき、セッション鍵を正常に保持していないＥＣＵ２０に当該セッション鍵を個別に再配布するか（個別配布）、新たなセッション鍵ＳＫを一斉に配布するか（一斉配布）を所定の条件に応じて選択する。セッション鍵ＳＫを正常に保持していない原因には、ネットワーク要因などによるセッション鍵ＳＫの受信失敗、ＥＣＵ２０のリセットやファームウェアアップデート等によるセッション鍵ＳＫの喪失（ロスト）、同期ずれや再送攻撃などによるセッション鍵ＳＫのバージョン違い、メモリの異常によるセッション鍵ＳＫの破壊などがある。以下、セッション鍵ＳＫの状態を判定する処理、及び個別配布と一斉配布の選択処理の具体例を説明する。
【００３７】
図５は、セッション鍵の状態を判定する処理、及び個別配布と一斉配布の選択処理を説明するためのフローチャートである。鍵管理用のＥＣＵ１０の鍵状態管理部１４は、ＣＡＮシステム１に接続されたＥＣＵ２０の内、配布されたセッション鍵ＳＫを正常に保持していないと推定されるＥＣＵ２０の数をカウントする（Ｓ２０）。
【００３８】
図６は、図５のステップＳ２０のサブルーチンを示すフローチャートである。鍵状態管理部１４は、メッセージの送出を停止したと推定されるＥＣＵ２０を検出する（Ｓ２０１）。当該ＥＣＵ２０を検出した場合（Ｓ２０１のＹ）、鍵状態管理部１４は、セッション鍵ＳＫが異常な可能性があるＥＣＵ２０をカウントするためのカウント値をインクリメントする（Ｓ２０４）。
【００３９】
例えば周期的にメッセージを送出するＥＣＵ２０の場合は次の検出方法を使用できる。周期的にメッセージを送出するＥＣＵ２０から最後に送出されたメッセージを受信してから、設定期間（例えば、周期期間＋マージン期間）を超えて当該ＥＣＵ２０からメッセージを受信できなかった場合、当該ＥＣＵ２０をメッセージの送出を停止したＥＣＵ２０と推定する。例えばエンジンを管理するＥＣＵ２０は、周期的（例えば１０ｍｓごと）にエンジンの回転数を含むメッセージを送出するが、そのメッセージを鍵管理用のＥＣＵ１０が上記の設定期間を超えても受信できない場合、メッセージの送出を停止したＥＣＵ２０と推定する。
【００４０】
また非周期的にメッセージを送出するＥＣＵ２０の場合は次の検出方法を使用できる。非周期的にメッセージを送出するＥＣＵ２０ごとに、過去履歴やシミュレーションデータに基づく送出頻度、イベント発生確率などに応じた判定期間を設定する。鍵管理用のＥＣＵ１０は、設定された判定期間内にメッセージを受信できなかったＥＣＵ２０をメッセージの送出を停止したＥＣＵ２０と推定する。以上の説明において鍵状態管理部１４は、各メッセージのメッセージＩＤを監視することにより、どのＥＣＵ２０のメッセージの状態が想定と異なるかを検出する。
【００４１】
メッセージの送出を停止したＥＣＵ２０を検出するために、鍵管理用のＥＣＵ１０から定期確認メッセージを送信することも考えられるが、ＣＡＮバス３０のトラフィック量を増加させる。この点、上記の検出方法では定期確認メッセージを送信しないため、ＣＡＮバス３０のトラフィック量の増加を抑えることができる。
【００４２】
鍵状態管理部１４は、ＭＡＣが一致しないメッセージを送出したＥＣＵ２０を検出する（Ｓ２０２）。当該ＥＣＵ２０を検出した場合（Ｓ２０２のＹ）、鍵状態管理部１４は上記カウント値をインクリメントする（Ｓ２０４）。上述のように本実施の形態に係るＣＡＮシステム１では、署名としてＭＡＣをメッセージに付加しているが、メッセージを受信したＥＣＵ１０における署名検証でＭＡＣが一致しない場合、送信元のＥＣＵ２０に保持されるセッション鍵ＳＫが正常でないと推定できる。
【００４３】
鍵状態管理部１４は、自己診断に基づき異常を検出したＥＣＵ２０を検出する（Ｓ２０３）。当該ＥＣＵ２０を検出した場合（Ｓ２０３のＹ）、鍵状態管理部１４は上記カウント値をインクリメントする（Ｓ２０４）。ＥＣＵ２０の鍵状態管理部２４は、セッション鍵ＳＫのチェックサムの不一致、通信の瞬断、リセットやファームウェア更新などによるセッション鍵ＳＫの喪失が発生した場合、セッション鍵の異常を知らせるメッセージを通知する。なお鍵管理用のＥＣＵ１０から定期的に一般のＥＣＵ２０に、セッション鍵ＳＫの状態が正常であるかの確認を求めるメッセージを送信してもよい。このように一般のＥＣＵ２０が自己診断機能を備えている場合、鍵管理用のＥＣＵ１０が当該自己診断機能をコールする方式も採用できる。
【００４４】
以上のステップＳ２０１〜ステップＳ２０４の処理が設定期間が経過するまで（Ｓ２０５のＮ）継続される。当該設定期間が経過すると（Ｓ２０５のＹ）、図５のステップＳ２１に遷移する。
【００４５】
鍵状態管理部１４は、上記カウント値で示されるセッション鍵が異常な可能性があるＥＣＵ２０の数がゼロより大きいか判定する（Ｓ２１）。当該ＥＣＵ２０の数がゼロの場合（Ｓ２１のＮ）ステップＳ２０に遷移する。当該ＥＣＵ２０の数が１以上の場合（Ｓ２１のＹ）、鍵状態管理部１４は当該ＥＣＵ２０の数が閾値を超えるか否か判定する（Ｓ２２）。この閾値は例えば、ＣＡＮシステム１に接続されたＥＣＵの数の５％相当の値に設定される。ただし、この閾値は５％相当の値に固執される必要は無く、ＥＣＵが搭載される車両ごとに適宜設定されても良く、あるいは、ＥＣＵの重要度に応じて重みづけをするなど、適宜設定されて良い。
【００４６】
当該ＥＣＵ２０の数が当該閾値を超える場合（Ｓ２２のＹ）、鍵配布部１３はセッション鍵の一斉配布を選択する（Ｓ２３）。超えない場合（Ｓ２２のＮ）、セッション鍵の個別配布を選択する（Ｓ２４）。
【００４７】
図７は、セッション鍵の個別配布を説明するためのシーケンスチャートである。鍵管理用のＥＣＵ１０において鍵配布部１３から暗号処理部１２に、セッション鍵ＳＫの個別の再配布指示がなされると、暗号・復号部１２４はセッション鍵ＳＫにカウンタＲＣを連結したデータ列を暗号鍵ＥＫを用いて暗号化する。これにより暗号化カウンタ付きセッション鍵ＣＴ’を生成する。ＭＡＣ生成・検証部１２５はＭＡＣ鍵ＭＫを用いて暗号化カウンタ付きセッション鍵ＣＴ’を対象とした署名Ｓｉｇ’（ＭＡＣ）を生成する（Ｓ１２’）。
【００４８】
セッション鍵ＳＫ、暗号鍵ＥＫ、ＭＡＣ鍵ＭＫは、前回の一斉配布時のセッション鍵ＳＫ、暗号鍵ＥＫ、ＭＡＣ鍵ＭＫと同じであるため新たに生成する必要はない。カウンタＲＣはセッション鍵ＳＫの再配布の回数を示すカウンタである。最初のセッション鍵ＳＫの再配布時にはカウントＲＣ＝１となり、２回目の再配布時にはカウントＲＣ＝２となる。
【００４９】
カウンタＲＣは一斉配布の暗号化セッション鍵ＣＴには付加されない。従ってカウンタＲＣの有無は、個別配布か一斉配布かを示すフラグとしても機能している。即ちカウンタＲＣが付加されたメッセージはセッション鍵ＳＫの個別配布のメッセージを示し、カウンタＲＣが付加されていないメッセージはセッション鍵ＳＫの一斉配布のメッセージを示すことになる。従ってセッション鍵ＳＫを正常に保持しているＥＣＵ２０は、カウンタＲＣを検出した時点でそのメッセージを無視または破棄する。
【００５０】
なおカウンタＲＣは暗号文の領域ではなく平文の領域に付与してもよい。その場合、復号する前にカウンタＲＣを検出できる。カウンタＲＣを暗号文の領域に含める方式では鍵配布のセキュリティを高めることができ、カウンタＲＣを平文の領域に含める方式ではセッション鍵ＳＫを正常に保持しているＥＣＵ２０の演算量を低減できる。図７に示す例ではカウンタＲＣを暗号文の領域に含める方式を採用している。なお、カウンタＲＣを平文の領域に含める方式でも、カウンタＲＣをＭＡＣの対象に含めることによりセキュリティを確保できる。
【００５１】
鍵配布部１３は、生成された暗号化カウンタ付きセッション鍵ＣＴ’に署名Ｓｉｇ’（ＭＡＣ）を連結したデータ列をメッセージ処理部１７に渡す。メッセージ処理部１７は、当該データ列とメッセージＩＤを含むメッセージを生成してＣＡＮバス３０にブロードキャストする（Ｓ１３’）。
【００５２】
ＥＣＵ２０のメッセージ処理部２７は、鍵管理用のＥＣＵ１０からブロードキャストされたメッセージを受信する。メッセージ処理部２７はメッセージから取り出したデータ列を暗号処理部２２に渡し、鍵管理用のＥＣＵ１０からメッセージを受信したことを鍵状態管理部２４に通知する。なお受信側でも以下で使用する暗号鍵ＥＫ、ＭＡＣ鍵ＭＫは、前回の一斉配布時の暗号鍵ＥＫ、ＭＡＣ鍵ＭＫと同じであるため新たに生成する必要はない。
【００５３】
暗号処理部２２は、メッセージ処理部２７から渡されたデータ列に含まれる暗号化カウンタ付きセッション鍵ＣＴ’と署名Ｓｉｇ’（ＭＡＣ）を分離する。ＭＡＣ生成・検証部２２５はＭＡＣ鍵ＭＫを用いて、分離された暗号化カウンタ付きセッション鍵ＣＴ’を対象とした署名Ｓｉｇ’（ＭＡＣ）を生成する（Ｓ２１’）。ＭＡＣ生成・検証部２２５は生成した署名Ｓｉｇ’（ＭＡＣ）と、データ列から分離した署名Ｓｉｇ’（ＭＡＣ）とを比較する（Ｓ２２’）。
【００５４】
両者が一致する場合（Ｓ２２’のＹ）、暗号・復号部２２４は、メッセージ処理部２７から渡されたデータ列に含まれる暗号化カウンタ付きセッション鍵ＣＴ’を暗号鍵ＥＫを用いて復号する（Ｓ２３’）。これによりメッセージからセッション鍵ＳＫとカウンタＲＣを取り出す。鍵状態管理部２４は今回取り出されたカウンタＲＣと、鍵再配布用のメッセージを前回受信したときのカウンタＲＣとを比較する（Ｓ２３５）。
【００５５】
今回のカウンタＲＣが前回のカウンタＲＣより大きい場合（Ｓ２３５のＹ）、鍵状態管理部２４はセッション鍵ＳＫの取得に成功したと判断し、暗号・復号部２２４は、取り出したセッション鍵ＳＫをセッション鍵保持部２２３に格納する。メッセージ処理部２７は、セッション鍵ＳＫの取り出しに成功したことを示す情報とメッセージＩＤを含むメッセージを生成し、ＣＡＮバス３０にブロードキャストする（Ｓ２４）。鍵管理用のＥＣＵ１０は当該メッセージを受信して、送信先のＥＣＵ２０がセッション鍵ＳＫを正常に取得したことを認識する。なおステップＳ２４において、セッション鍵ＳＫの取り出しに失敗した時のみ、メッセージ処理部２７が、セッション鍵ＳＫの取り出しに失敗したことを示す情報とメッセージＩＤを含むメッセージを生成し、ＣＡＮバス３０にブロードキャストしてもよい。またステップＳ２４の応答処理を省略する方式も採用可能である。
【００５６】
ＥＣＵ１０の鍵状態管理部１４は、今回セッション鍵ＳＫを正常に取得したＥＣＵ２０の識別情報をメッセージ処理部１７に渡し、メッセージ処理部１７は当該ＥＣＵ２０の識別情報を含むメッセージを再同期完了通知として、ＣＡＮバス３０にブロードキャストする（Ｓ１４）。セッション鍵ＳＫが異常な状態のＥＣＵ２０との通信を停止していたＥＣＵ２０は、再同期完了通知を受信することにより当該通信を再開する。
【００５７】
ステップＳ２２’において、ＭＡＣ生成・検証部２２５が生成した署名Ｓｉｇ’（ＭＡＣ）と、データ列から分離した署名Ｓｉｇ’（ＭＡＣ）とが一致しない場合（Ｓ２２’のＮ）、ステップＳ２３’、ステップＳ２３５、ステップＳ２４の処理をスキップする。またステップＳ２３５において、今回のカウンタＲＣが前回のカウンタＲＣ以下の場合（Ｓ２３５のＮ）、ステップＳ２４の処理をスキップする。
【００５８】
以上に説明したセッション鍵の個別配布処理において、カウンタＲＣを用いることによって、不正にメッセージを傍受した不正機器が旧バージョンのセッション鍵ＳＫを送付して、攻撃対象のＥＣＵ２０のセッション鍵ＳＫを旧バージョンのセッション鍵ＳＫに書き換える再送攻撃を判別することも可能となる。また、カウンタＲＣの代わりに、単純に個別配布か一斉配布かを示すフラグを用いてもよい。この場合、１ビットで記述できるためデータ量を低減できる。なお当該フラグとカウンタＲＣの両方を付加してもよい。また個別配布か一斉配布かでメッセージＩＤを変えることにより、受信側のＥＣＵ２０に個別配布か一斉配布か識別させる方式を採用してもよい。
【００５９】
また鍵管理用のＥＣＵ１０はセッション鍵ＳＫを個別配布する際、セッション鍵ＳＫを含むメッセージに、配布先のＥＣＵ２０の識別情報（例えば、ＥＣＵの機器ＩＤまたはメッセージＩＤ）を含めてもよい。受信側のＥＣＵ２０で自己が個別配布の対象となっているか否かを簡単に確認できる。
【００６０】
鍵状態管理部１４は配布履歴記憶部１６を参照して、セッション鍵ＳＫの個別配布の対象となった回数が閾値を超えたＥＣＵ２０を、次回以降のセッション鍵ＳＫの個別配布の対象から除外する。また次回のセッション鍵ＳＫの一斉配布の対象から除外してもよい。当該ＥＣＵ２０を一斉配布の対象から除外する場合、当該ＥＣＵ２０を除く全てのＥＣＵ２０に個別配布する方式で新規のセッション鍵ＳＫを配布する手法を用いることができる。
【００６１】
セッション鍵の異常を繰り返すＥＣＵ２０は不正機器からの攻撃対象となっている可能性があるため、ＣＡＮでサポートされているエラーフレームを送信してＣＡＮシステム１から切り離してもよい。なおセッション鍵の個別配布の対象となった回数が閾値を超えない場合でも、自己診断に基づき、攻撃対象となっている可能性があると通知してきたＥＣＵ２０については上記と同様の処置を実施する。
【００６２】
以上の説明において鍵管理用のＥＣＵ１０は、セッション鍵ＳＫが異常なＥＣＵ２０が車両走行に必須な状況でないことを確認できてから、セッション鍵ＳＫの個別配布または一斉配布を実施してもよい。例えば車両走行に直接関係するＥＣＵである場合、車両が停車状態（例えばパーキング状態）にあることを確認できてから実施する。なお車両走行に直接関係しないＥＣＵについては上記の確認は不要である。
【００６３】
以上説明したように本実施の形態によれば、ＣＡＮシステム１においてセッション鍵ＳＫに異常が発生したとき、個別配布と一斉配布を使い分けることにより、セッション鍵ＳＫを効率的に配布できる。一斉配布は、既存のセッション鍵ＳＫを無効にしてから新規のセッション鍵ＳＫの配布完了までの期間、通常の通信ができなくなる。従って基本的に一斉配布より個別配布が好ましい。しかしながらセッション鍵ＳＫが異常なＥＣＵ２０の数が多い場合、個別に再配布しても、セッション鍵ＳＫが異常なＥＣＵ２０が全て正常化する可能性が低くなり、再度のＳＫ配布が必要となる可能性が高くなる。一斉配布を選択したほうが、結果的にセッション鍵ＳＫの同期状態の回復が早くなる可能性が高くなる。またセッション鍵ＳＫが異常なＥＣＵ２０の数が多い場合、外部の不正機器から攻撃を受けている可能性が相対的に高いため、全体でセッション鍵ＳＫを更新したほうがＣＡＮシステム１セキュリティ上、好ましい。
【００６４】
以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００６５】
上述の実施の形態では、セッション鍵ＳＫが異常なＥＣＵ２０の数を基準に個別配布と一斉配布を選択したが、その他の基準で選択してもよい。例えば車両の状態を基準に選択してもよい。またセッション鍵ＳＫの異常が発生しているＥＣＵ２０の重要度を基準に選択してもよい。
【００６６】
上述した、車両の状態を基準に選択する例を変形例１として、以下に説明する。図８は、変形例１に係る個別配布と一斉配布の選択処理を説明するためのフローチャートである。セッション鍵ＳＫが異常な可能性があるＥＣＵ２０が検出されると（Ｓ２１のＹ）。車両状態検出部１５は、パーキングブレーキを管理するＥＣＵ２０からパーキングブレーキの状態を取得し、鍵状態管理部１４は車両がパーキング状態であるか否か判定する（Ｓ２１５）。パーキング状態にある場合（Ｓ２１５のＹ）、鍵配布部１３は一斉配布を選択する（Ｓ２３）、パーキング状態にない場合（Ｓ２２のＮ）、個別配布を選択する（Ｓ２４）。上述のように一斉配布は通信の空白期間が発生するが、車両がパーキング状態である場合、その弊害は小さくなる。一方、走行中は空白期間の発生を抑えるため、個別配布で対応する。なお車両状態検出部１５は、パーキングブレーキの状態の代わりに減速ブレーキの状態に基づき、車両がパーキング状態であるか否かを判定してもよい。また車両状態検出部１５は車両速度が設定速度以下であるか否か、エンジンの回転数が設定数以下であるか否かをもとに、車両がパーキング状態であるか否かを判定してもよい。
【００６７】
上述した、ＥＣＵの重要度を基準に選択する例を変形例２として、以下に説明する。これまで鍵管理用のＥＣＵ１０が一台の例を説明したが、大規模なＣＡＮシステム１では複数台使用される。大規模なＣＡＮシステム１は複数のサブネットワークシステムをゲートウェイ用のＥＣＵで接続して構築される。ゲートウェイ用のＥＣＵは鍵管理用のＥＣＵ１０を兼ねるケースも多い。このようなゲートウェイ用のＥＣＵに不具合が発生した場合、そのゲートウェイ用のＥＣＵが管理するサブネットワークシステムに接続された全てのＥＣＵが影響を受ける。従って、このゲートウェイ用のＥＣＵは重要度が高いＥＣＵといえる。
【００６８】
図９は、変形例２に係る個別配布と一斉配布の選択処理を説明するためのフローチャートである。鍵管理用のＥＣＵ１０の鍵状態管理部１４が、セッション鍵ＳＫが異常な可能性がある一般のＥＣＵ２０を検出すると（Ｓ２１のＹ）、鍵状態管理部１４は当該ＥＣＵ２０が重要度の高いＥＣＵであるか否か判定する（Ｓ２１６）。重要度の高いＥＣＵである場合（Ｓ２１６のＹ）、鍵配布部１３は一斉配布を選択する（Ｓ２３）、重要度が高いＥＣＵでない場合（Ｓ２１６のＮ）、個別配布を選択する（Ｓ２４）。重要度が高いＥＣＵのセッション鍵ＳＫに異常が発生した場合、そのＥＣＵが攻撃を受けた場合の影響が大きくなるため、一斉配布によるセキュリティ鍵ＳＫの更新を選択してセキュリティ確保を優先する。一方、重要度が高くないＥＣＵの場合、個別配布を選択して通信の空白期間の発生を抑える。
【００６９】
変形例１及び／または変形例２に係る個別配布と一斉配布の選択処理は、図５に示した個別配布と一斉配布の選択処理と組み合わせて使用することもできる。
【００７０】
図１０は、図５の個別配布と一斉配布の選択処理と図８の個別配布と一斉配布の選択処理を組み合わせた処理を説明するためのフローチャートである。図１０に示す選択処理では、図５のステップＳ２１の処理とステップＳ２２の処理との間に、図１０のステップＳ２１５の処理を追加する。即ち車両がパーキング状態にある場合（Ｓ２１５のＹ）、セッション鍵ＳＫが異常な可能性があるＥＣＵ２０の数を考慮せずに一斉配布を選択する（Ｓ２３）。一方、パーキング状態にない場合（Ｓ２１５のＮ）、セッション鍵ＳＫが異常な可能性があるＥＣＵ２０の数に応じて一斉配布（Ｓ２３）と個別配布（Ｓ２４）を場合分けする。
【００７１】
上述の実施の形態では図６に示した事象が発生したとき、セッション鍵ＳＫの状態を異常と判断したが別の方法により異常と判断してもよい。例えば鍵管理用のＥＣＵ１０の鍵状態管理部１４は、ＣＡＮバス３０に流れるメッセージ数をカウントし、メッセージ数がセッション鍵ＳＫを使用してＭＡＣを生成可能な上限数を超えた場合、セッション鍵ＳＫの状態を異常と判断してもよい。なお各ＥＣＵが全てのメッセージにＭＡＣを付加せず、間引いてＭＡＣを付加している（例えば重要性の高いメッセージにのみＭＡＣを付加している）場合、鍵状態管理部１４はＭＡＣが付加されているメッセージのみをカウントする。
【００７２】
また鍵管理用のＥＣＵ１０の鍵状態管理部１４は、ＣＡＮバス３０に流れている受信可能な全てのメッセージのＭＡＣを検証し、検証に失敗した数が閾値を超えた場合、セッション鍵ＳＫの状態を異常と判断してもよい。
【００７３】
また本発明はＣＡＮ以外の車内ネットワークにも適用可能である。ユニキャストが可能な車内ネットワークシステムでは、個別配布の場合にユニキャストが選択され、一斉配布の場合にブロードキャストが選択される。
【００７４】
本発明の一態様の概要は、次の通りである。本発明のある態様の鍵管理通信装置は、ネットワークに接続された通信装置間において共通に使用される通信鍵を、前記ネットワークを介して当該ネットワークに接続された通信装置に配布する鍵配布部と、前記通信装置に配布された通信鍵の状態を管理する鍵状態管理部と、を備える。前記鍵配布部は、前記通信鍵の状態に異常が発生したとき、前記通信鍵を正常に保持していない通信装置に前記通信鍵を個別に再配布するか、前記ネットワークに接続された通信装置に新たな通信鍵を一斉に配布するかを所定の条件に応じて選択する。「鍵管理通信装置」は、鍵管理用のＥＣＵ１０であってもよい。「ネットワーク」はＣＡＮバス３０であってもよい。「通信装置」は、ＥＣＵ２０であってもよい。「通信鍵」はセッション鍵ＳＫであってもよい。
【００７５】
この態様によると、通信鍵を個別に再配布するか新たな通信鍵を一斉に配布するかを状況に応じて使い分けることができるため、効率的な通信鍵の配布が可能となる。
【００７６】
前記鍵状態管理部は、前記ネットワークに接続された通信装置の内、配布された通信鍵を正常に保持していない通信装置の数を検出し、前記鍵配布部は、前記通信鍵を正常に保持していない通信装置の数が設定数未満のとき前記通信鍵を正常に保持していない通信装置に前記通信鍵を個別に再配布し、当該設定数以上のとき前記ネットワークに接続された通信装置に新たな通信鍵を一斉に配布してもよい。これによれば、通信鍵を正常に保持していない通信装置の数が多い場合、一斉配布を選択することにより、個別配布を選択することに起因する同期状態の回復に遅れが生じる事態を回避できる。
【００７７】
前記鍵状態管理部は、メッセージの送出を停止した通信装置、異常なメッセージ認証コードを付加したメッセージを送出した通信装置を、配布された通信鍵を正常に保持していない通信装置であると検出してもよい。これによれば、鍵管理用の通信装置と一般の通信装置との間の通信量を抑えつつ、通信鍵を正常に保持していない通信装置を検出できる。
【００７８】
前記鍵配布部は、個別に再配布する場合、個別配布であること示すフラグ又は再配布の回数を示すカウント値が付加された通信鍵をブロードキャストし、通信鍵を一斉に配布する場合、前記フラグ又は前記カウント値が付加されない通信鍵をブロードキャストしてもよい。これによれば、ＣＡＮのようなブロードキャストを採用したネットワークシステムでも、個別配布と一斉配布を使い分けることができる。
【００７９】
本発明の別の態様は、鍵配布方法である。この方法は、ネットワークに接続された通信装置間において共通に使用される通信鍵を、当該ネットワークを介して当該ネットワークに接続された通信装置に配布する鍵配布ステップと、配布された通信鍵の状態を管理する鍵状態管理ステップと、を備える。前記鍵配布ステップは、前記通信鍵の状態に異常が発生したとき、前記通信鍵を正常に保持していない通信装置に前記通信鍵を個別に再配布するか、前記ネットワークに接続された通信装置に新たな通信鍵を一斉に配布するかを所定の条件に応じて選択する。
【００８０】
この態様によると、通信鍵を個別に再配布するか新たな通信鍵を一斉に配布するかを状況に応じて使い分けることができるため、効率的な通信鍵の配布が可能となる。
【符号の説明】
【００８１】
１  ＣＡＮシステム、  １０，２０  ＥＣＵ、  ３０  ＣＡＮバス、  １１  アプリケーション処理部、  １２  暗号処理部、  １２１  マスタ鍵保持部、  １２２  鍵生成部、  １２３  セッション鍵保持部、  １２４  暗号・復号部、  １２５  ＭＡＣ生成・検証部、  １３  鍵配布部、  １４  鍵状態管理部、  １５  車両状態検出部、  １６  配布履歴記憶部、  １７  メッセージ処理部、  ２１  アプリケーション処理部、  ２２  暗号処理部、  ２２１  マスタ鍵保持部、  ２２２  鍵生成部、  ２２３  セッション鍵保持部、  ２２４  暗号・復号部、  ２２５  ＭＡＣ生成・検証部、  ２４  鍵状態管理部、  ２７  メッセージ処理部。
【産業上の利用可能性】
【００８２】
本発明は、ＣＡＮに利用可能である。
【図１】
2016092716.tif 000003
【図２】
2016092716.tif 000004
【図３】
2016092716.tif 000005
【図４】
2016092716.tif 000006
【図５】
2016092716.tif 000007
【図６】
2016092716.tif 000008
【図７】
2016092716.tif 000009
【図８】
2016092716.tif 000010
【図９】
2016092716.tif 000011
【図１０】
2016092716.tif 000012