(57)【要約】【課題】  ローカルエリアネットワークを介して共通の暗号鍵を用いた暗号通信を行う通信システムにおいて、鍵交換に要する時間の短縮を図ることを目的とする。【解決手段】  システムが起動すると、ゲートウェイＥＣＵ（ＧＷ）が暗号鍵を生成し、これを種鍵を用いて暗号化した暗号化データを、放送形式で全ＥＣＵ（ＥＣＵ１  〜ＥＣＵＮ  ）に一括配信する。各ＥＣＵは、受信した暗号化データを種鍵を用いて復号し、復号結果を暗号鍵として以後の通信データの暗号化，復号に用いる。また暗号鍵を設定したＥＣＵは、その旨を表す応答（鍵確認）を生成し、これを暗号鍵を用いて暗号化した暗号化データをゲートウェイＥＣＵに返送する。ゲートウェイＥＣＵは、その応答に基づいて各ＥＣＵの正当性を判定する。【選択図】  図３
2005341528.tif 000002
【特許請求の範囲】
【請求項１】
ローカルエリアネットワークに接続された三つ以上のノードが、共通の暗号鍵を用いて通信データを暗号化及び復号する暗号通信を行うことを特徴とする通信システム。
【請求項２】
前記ノードのいずれか一つが主ノードとなって前記暗号鍵の生成を行い、該暗号鍵を前記主ノード以外のノードである従ノードに前記ローカルエリアネットワークを介して放送形式で配信する鍵交換を実行することで、各ノードに前記暗号鍵を共有させることを特徴とする請求項１に記載の通信システム。
【請求項３】
前記ノードのそれぞれには、予め共通の種鍵が用意され、
前記鍵交換では、前記種鍵を用いて前記暗号鍵を暗号化することを特徴とする請求項２に記載の通信システム。
【請求項４】
前記鍵交換を、当該通信システムの起動毎に実行することを特徴とする請求項２又は３に記載の通信システム。
【請求項５】
当該通信システムの起動後、各ノードにおいて通信データを生成，処理するデータ処理部の初期化が終了するまでの間に、該データ処理部の初期化と並行して前記鍵交換を実行することを特徴とする請求項４に記載の通信システム。
【請求項６】
前記従ノードは、前記暗号鍵の配信を受けた場合に、前記ローカルエリアネットワークを介して前記主ノードに確認信号を返信し、
前記主ノードは、前記暗号鍵を共有すべき従ノードの中で、前記確認信号の返信のない未確認従ノードが存在する場合に、前記鍵交換を再実行することを特徴とする請求項２〜５のいずれかに記載の通信システム。
【請求項７】
前記主ノードは、前記確認信号の返信のあった従ノードを示した鍵確認リストを、前記ローカルエリアネットワークを介して放送形式で配信し、
前記従ノードは、前記鍵確認リストに自ノードが示されていない場合のみ、前記鍵交換の再実行による暗号鍵の再配信に対して前記確認信号を返信することを特徴とする請求項６に記載の通信システム。
【請求項８】
前記主ノードは、前記鍵交換の実行前に、前記暗号鍵を共有すべき従ノードを示した通知リストを、前記ローカルエリアネットワークを介して放送形式で配信し、
前記従ノードは、前記通知リストに自ノードが示され、且つ、前記暗号鍵の配信を受けた場合に、前記ローカルエリアネットワークを介して前記主ノードに確認信号を返信することを特徴とする請求項２〜５のいずれかに記載の通信システム。
【請求項９】
前記主ノードは、前記通知リストに示された従ノードの中で、前記確認信号の返信のない未確認従ノードが存在する場合に、該未確認従ノードを示した通知リストを配信後、前記鍵交換を再実行することを特徴とする請求項８に記載の通信システム。
【請求項１０】
前記従ノードは、当該従ノードにて発生させた乱数を前記確認信号とし、該確認信号を前記鍵交換によって取得した暗号鍵で暗号化して送信し、
前記主ノードは、前記確認信号を受信すると、前記確認信号を復号することで抽出した乱数に予め設定された認証子を付加してなる確認応答信号を、前記暗号鍵で暗号化し、前記ローカルエリアネットワークを介して返信することを特徴とする請求項６〜９のいずれかに記載の通信システム。
【請求項１１】
前記従ノードは、前記鍵交換が実行されるべきタイミングで、予め設定された鍵待ち時間内に前記暗号鍵の配信を受けることができなかった場合、前記主ノードに対して前記鍵交換の実行を要求する要求信号を前記ローカルエリアネットワークを介して送信することを特徴とする請求項２〜１０のいずれかに記載の通信システム。
【請求項１２】
ローカルエリアネットワークを介して暗号通信を行う通信システムにおいて、該通信システムを構成するノードのいずれか一つに搭載される鍵配信装置であって、
通信データの暗号化及び復号に用いる暗号鍵を、予め設定された鍵生成タイミングで生成する鍵生成手段と、
該鍵生成手段により生成された暗号鍵を、予め用意された種鍵を用いて暗号化し、前記ローカルエリアネットワークを介して放送形式で配信する鍵配信手段と、
該鍵配信手段が配信した暗号鍵を受信した他ノードからの確認信号を、前記ローカルエリアネットワークを介して受信し、該確認信号の返信があったノードを示した鍵確認リストを生成するリスト生成手段と、
該リスト生成手段が生成した鍵確認リストを、前記ローカルエリアネットワークを介して放送形式で配信するリスト配信手段と、
を備えることを特徴とする鍵配信装置。
【請求項１３】
前記暗号鍵を共有すべきノードの中で、前記確認信号の返信のない未確認ノードが存在する場合、前記暗号鍵を再配信する再配信手段を備えることを特徴とする請求項１２に記載の鍵配信装置。
【請求項１４】
前記リスト生成手段は、前記鍵配信手段による暗号鍵の配信後、予め設定された確認待時間内に受信した確認信号に基づいて、前記鍵確認リストを生成することを特徴とする請求項１２又は１３に記載の鍵配信装置。
【請求項１５】
ローカルエリアネットワークを介して暗号通信を行う通信システムにおいて、該通信システムを構成するノードのいずれか一つに搭載される鍵配信装置であって、
通信データの暗号化及び復号に用いる暗号鍵を、予め設定された鍵生成タイミングで生成する鍵生成手段と、
前記暗号鍵が配信されるべきノードを示した通知リストを、前記ローカルエリアネットワークを介して放送形式で配信する通知リスト配信手段と、
該通知リスト配信手段による通知リストの配信後、前記鍵生成手段により生成された暗号鍵を、予め用意された種鍵を用いて暗号化し、前記ローカルエリアネットワークを介して放送形式で配信する鍵配信手段と、
を備えることを特徴とする鍵配信装置。
【請求項１６】
前記鍵配信手段が配信した暗号鍵を受信した他ノードからの確認信号を前記ローカルエリアネットワークを介して受信し、前記通知リストに示したノードの中で、前記確認信号の返信のない未確認ノードが存在する場合に、該未確認ノードを示した通知リスト及び前記暗号鍵を再配信する再配信手段を備えることを特徴とする請求項１５に記載の鍵配信装置。
【請求項１７】
前記確認信号には乱数が含まれており、
前記確認信号が受信されると、該確認信号を復号することで抽出した乱数に予め設定された認証子を付加してなる確認応答信号を、前記暗号鍵で暗号化し、前記ローカルエリアネットワークを介して送信する確認応答送信手段を備えることを特徴とする請求項１２〜１６のいずれかに記載の鍵配信装置。
【請求項１８】
ローカルエリアネットワークを介して暗号通信を行う通信システムにおいて、該通信システムを構成するノードに搭載される暗号処理装置であって、
予め設定された種鍵を用いて暗号化された暗号鍵を前記ローカルエリアネットワークを介して受信すると、その旨を示す確認信号を前記ローカルエリアネットワークを介して返信する暗号鍵受信手段と、
前記暗号鍵受信手段により受信された暗号鍵を用いて、前記ローカルエリアネットワークを介して送受信される通信データを暗号化及び復号する暗号処理手段と、
を備えることを特徴とする暗号処理装置。
【請求項１９】
前記ローカルエリアネットワークを介して、前記確認信号を返信したノードが示された鍵確認リストを受信し、該鍵確認リストに自ノードが示されている場合に、前記暗号鍵受信手段の作動を禁止する確認リスト受信手段を備えることを特徴とする請求項１８に記載の暗号処理装置。
【請求項２０】
当該装置の起動後、予め設定された鍵待ち時間内に前記暗号鍵を受信できない場合、又は前記暗号鍵受信手段が前記確認信号を返信したにも関わらず前記鍵確認リストに自ノードが示されていない場合に、前記暗号鍵の配信元に対して前記暗号鍵の再配信を要求する要求信号を前記ローカルエリアネットワークを介して送信する要求送信手段を備えることを特徴とする請求項１９に記載の暗号処理装置。
【請求項２１】
前記ローカルエリアネットワークを介して、前記暗号鍵を共有すべきノードが示された通知リストを受信し、該通知リストに自ノードが示されている場合に、前記暗号鍵受信手段を作動させる通知リスト受信手段を備えることを特徴とする請求項１８に記載の暗号処理装置。
【請求項２２】
当該装置の起動後、予め設定されたリスト待ち時間内に前記通知リストを受信できない場合、又は前記通知リストの受信後、予め設定された鍵待ち時間内に前記暗号鍵を受信できない場合に、前記暗号鍵の配信元に対して前記暗号鍵の再配信を要求する要求信号を前記ローカルエリアネットワークを介して送信する要求送信手段を備えることを特徴とする請求項２１に記載の暗号処理装置。
【請求項２３】
前記暗号鍵受信手段は、当該装置にて発生された乱数を前記確認信号とし、該確認信号を前記暗号鍵で暗号化して送信し、
前記ローカルエリアネットワークを介して前記確認信号に対する確認応答信号を受信した場合、該確認応答信号を前記暗号鍵で復号した結果が、前記確認信号として送信した乱数、及び予め設定された認証子とは異なる場合に、前記暗号鍵の送信元に異常があると判定する異常判定手段と、
を備えることを特徴とする請求項１８〜２２のいずれかに記載の暗号処理装置。
【請求項２４】
複数の電子制御装置が車載ローカルエリアネットワークを介して互いに暗号通信を行い、且つ該暗号通信にて通信データの暗号化及び復号に用いる暗号鍵を前記電子制御装置間で共有するための鍵交換を実行する通信システムを備えた車両に搭載される盗難防止装置であって、
前記通信システムにて前記鍵交換を実行した結果に異常が検出された場合、車両周囲への報知、又は予め指定された外部装置への通報、或いは予め指定された特定車両制御の禁止のうち、少なくともいずれか一つを実行する異常対応手段を備えることを特徴とする盗難防止装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ローカルエリアネットワークを介して暗号通信を行う通信システム、その通信システムを構成するノードに搭載される鍵配信装置，暗号処理装置、及びその通信システムを搭載した車両に適用される盗難防止装置に関する。
【背景技術】
【０００２】
従来より、通信システムにおいては、通信データの盗聴・改竄や、部外者のなりすましを防ぐために、通信データを暗号化することが行われており、その暗号化の一つとして、通信を行う両者が共通の暗号鍵（以下「共通鍵」と称する。）を使用する共通鍵暗号がある。
【０００３】
そして、共通鍵暗号では、部外者に知られることなく、通信を行う両者に共通鍵を共有させることが重要であり、これを実現する一つの方法として、信頼できる第三者機関を介して鍵交換を行う第三者認証技術（例えば、ＳＳＬ：Secure Socket Layer やKerberos等）が知られている（例えば、非特許文献１参照。）。
【０００４】
以下、この第三者認証技術にて実行される鍵交換を、図５（ａ）に示す説明図を参照して説明する。
図５（ａ）に示すように、通信を行う各ノードＡ，Ｂには、それぞれ互いに異なった種鍵Ｋａ，Ｋｂが予め割り当てられ、また、第三者機関である鍵配送センターＳには、全てのノードの種鍵Ｋａ，Ｋｂが予め登録されている。
【０００５】
そして、ノードＢとの通信を希望するノードＡが、鍵配送センターＳに対してその旨（Ａ，Ｂ）を通知すると、鍵配送センターＳは、ノードＡ，Ｂ間の通信に使用する共通鍵Ｋabを生成し、その共通鍵Ｋabを、ノードＡに割り当てられた種鍵Ｋａ及びノードＢに割り当てられた種鍵Ｋbを用いてそれぞれ暗号化することで暗号文Ｅａ及びＥｂを生成し、ノードＡに配信する。
【０００６】
すると、ノードＡは、種鍵Ｋａを用いて暗号文Ｅａを復号することで共通鍵Ｋabを取得し、更に、その共通鍵Ｋabを用いて暗号化した暗号文Ｅabs と鍵配送センターＳから配信された暗号文ＥｂとをノードＢに送信する。
【０００７】
すると、ノードＢは、種鍵Ｋｂを用いて暗号文Ｅｂを復号することで共通鍵Ｋabを取得し、更に、この共通鍵Ｋabを用いて暗号文Ｅabs を復号し、復号に成功すれば、共通鍵Ｋabを用いて暗号化した暗号文Ｅabr をノードＡに送信する。以後のノードＢは、ノードＡとの暗号通信に共通鍵Ｋabを使用する。
【０００８】
一方、暗号文Ｅabr を受信したノードＡも、暗号文Ｅabr を共通鍵Ｋabを用いて復号し、復号に成功すれば、以後、ノードＢとの暗号通信に共通鍵Ｋabを使用する。これにより、共通鍵Ｋabが、ノードＡ，Ｂによって共有されることになる。
【非特許文献１】岡本龍明，山本博資著、「現代暗号」、産業図書、p198〜p199
【発明の開示】
【発明が解決しようとする課題】
【０００９】
ところで、車両においては、制御の高度化やサービスの充実を図るために、電子制御ユニット（ＥＣＵ）等の車載機器同士をローカルエリアネットワーク（いわゆる車載ＬＡＮ）を介して相互に接続し、車載機器間でデータを共有することが行われている。そして、今後、このような車載ＬＡＮにおいても、セキュリティ強化のために暗号通信を導入することが予想される。
【００１０】
この種の車載ＬＡＮに、上述した共通鍵を用いる暗号通信を適用した場合、図５（ｂ）に示すように、車載ＬＡＮに接続される全てのＥＣＵの組合せに対して共通鍵を割り当てる必要があるため、ＥＣＵの数をＮ個とすると、Ｎ×（Ｎ−１）／２個もの共通鍵が必要となる。通常、車載ＬＡＮには、十数個〜数十個ものＥＣＵが接続されるため、生成すべき鍵数は膨大なものとなる。
【００１１】
また、共通鍵を用いた暗号通信の場合、セキュリティ強度を高めるためには、定期的に鍵交換を行って共通鍵を更新する必要もある。
しかし、この場合、全てのＥＣＵの組合せについて鍵交換が実施されるため、図６に示すように、車載ＬＡＮが長期間に渡って、鍵交換（鍵の配信，確認）のための通信に占有されることになる。
【００１２】
つまり、上述の鍵交換を車載ＬＡＮに適用した場合には、膨大な数の共通鍵が必要となり、共通鍵の生成，配信のために長い処理時間を費やさなければならなくなる。
そして、通常、鍵交換を行うタイミングとして、イグニッションスイッチがオンされた時が考えられるが、この場合、鍵交換が終了してＥＣＵ同士が通信可能となり、通常の車両制御が可能な状態となるまでに、長い待ち時間が生じてしまい、ドライバーに違和感を与えてしまうという問題があった。このような問題は、車載ＬＡＮに限らず、高い応答性が要求されるＬＡＮにおいて共通である。
【００１３】
また、近年、欧米では、車両本体ではなく車両に取り付けられたＥＣＵ等の各種部品を目的とした車両の盗難が頻発しており、この種の盗難を抑制するために、盗難品を無効化する技術も望まれている。
【００１４】
そこで本発明は、上記問題点を解決するために、ローカルエリアネットワークを介して共通の暗号鍵を用いた暗号通信を行う通信システムにおいて、鍵交換に要する時間の短縮を図ることを第１の目的とし、車載ＬＡＮに接続される部品（ノード）を目的とした車両盗難を抑止することを第２の目的とする。
【課題を解決するための手段】
【００１５】
上記目的を達成するためになされた第一発明の通信システムは、ローカルエリアネットワークに接続された三つ以上のノードが、共通の暗号鍵を用いて通信データを暗号化及び復号する暗号通信を行うことを特徴とする。
【００１６】
このように構成された本発明の通信システムでは、ノードの数によらず鍵交換の際には暗号鍵を一つだけ生成すればよいため、鍵の生成に要する時間を大幅に削減することができる。
【００１７】
具体的には、共通の暗号鍵を用いるノードの数をＮとした場合、従来装置と比較して鍵数は、２／｛Ｎ（Ｎ−１）｝倍となるため、ノード数Ｎが多いほど、大きな効果が得られる。
【００１８】
そして、特に車載ＬＡＮ等のように、基本的に限られたノード間でのみ通信を行い、不特定多数との通信を行う必要がない閉じた通信システムでは、全てのノードで共通の暗号鍵を使用しても、セキュリティの強度を大きく低下させてしまうことがないため、本発明を好適に適用することができる。
【００１９】
ところで、本発明の通信システムは、ローカルエリアネットワークに接続されるノードのいずれか一つが主ノードとなって暗号鍵の生成を行い、その暗号鍵を主ノード以外のノードである従ノードにローカルエリアネットワークを介して放送形式で配信する鍵交換を実行することで、各ノードに暗号鍵を共有させるように構成することが望ましい。
【００２０】
この場合、暗号鍵の生成だけでなく、暗号鍵の配信に要する時間も大幅に削減することができる。
なお、暗号鍵の配信の際には、暗号鍵を秘密に保つために、暗号鍵自体を暗号化して配信する必要がある。このため、ノードのそれぞれには、予め共通の種鍵を割当てておき、鍵交換では、この種鍵を用いて暗号鍵を暗号化するように構成することが望ましい。
【００２１】
また、鍵交換は、例えば、一定時間が経過する毎に周期的に実行したり、外部からの指令に従って実行したりすることが考えられるが、システムの起動，停止が比較的短い間隔で繰り返されるような場合には、その起動毎に実行するように構成してもよい。
【００２２】
そして、当該通信システムの起動時に鍵交換を実行する場合には、システムの起動後、各ノードにおいて通信データを生成，処理するデータ処理部の初期化が終了するまでの間に、そのデータ処理部の初期化と並行して鍵交換を実行するように構成することが望ましい。
【００２３】
この場合、データ処理部の初期化が終了すると、ローカルエリアネットワークを介した他のノードとの暗号通信を直ちに開始することができ、システムを速やかに立ち上げることができる。
【００２４】
ところで、従ノードを、暗号鍵の配信を受けた場合に、ローカルエリアネットワークを介して主ノードに確認信号を返信するように構成した場合、主ノードは、暗号鍵を共有すべき従ノードの中で、確認信号の返信のない未確認従ノードが存在する場合に、鍵交換を再実行するように構成してもよい。
【００２５】
つまり、鍵交換の時に、主ノードや従ノードの異常や故障によらない何等かの外部要因（例えば外来ノイズなど）で、従ノードが暗号鍵を受信できなかったり、主ノードが確認信号を受信できない可能性がある。このような場合に、鍵交換を再実行することで、ノードの異常や故障ではないにも関わらず、暗号通信が実行不能となってしまうことを防止できる。
【００２６】
そして、このように鍵交換を再実行する場合、主ノードは、確認信号の返信のあった従ノードを示した鍵確認リストを、ローカルエリアネットワークを介して放送形式で配信し、従ノードは、鍵確認リストに自ノードが示されていない場合のみ、鍵交換の再実行による暗号鍵の再配信に対して確認信号を返信するように構成することが望ましい。
【００２７】
つまり、主ノードにて暗号鍵の取得が確認されなかった従ノードのみ、再配信された暗号鍵に対する処理を実行させることにより、暗号鍵の取得が確認されている従ノードに不要な処理を強いることなく、鍵交換の再実行を必要最小限の処理量にて実現することができる。
【００２８】
また、上述のように確認信号に基づいて生成した鍵確認リストを送信する代わりに、主ノードは、鍵交換の実行前に、暗号鍵を共有すべき従ノードを示した通知リストを、ローカルエリアネットワークを介して放送形式で配信し、従ノードは、通知リストに自ノードが示され、且つ、暗号鍵の配信を受けた場合に、ローカルエリアネットワークを介して主ノードに確認信号を返信するように構成してもよい。
【００２９】
更に、主ノードは、通知リストに示された従ノードの中で、確認信号の返信のない未確認従ノードが存在する場合に、その未確認従ノードを示した通知リストを配信後、鍵交換を再実行するように構成することが望ましい。
【００３０】
この場合、上述した通知リストを用いて鍵交換を再実行する場合と同様に、ノードの異常や故障ではないにも関わらず、暗号通信が実行不能となってしまうことを防止できる。
また、鍵交換の再実行に先立って配信される通知リストには、主ノードにて暗号鍵の取得が確認されなかった従ノードのみ示されるため、暗号鍵の取得が確認されている従ノードに不要な処理を強いることなく、鍵交換の再実行を必要最小限の処理量にて実現することができる。
【００３１】
ところで、主ノードを置換する不正が行われた場合、その置換された不正な主ノードが、正当な主ノードから従ノードに対して送信された信号のコピーを送信するように構成されていると、従ノードでは、その受信した信号が正当な主ノードから送信されたものであるか、置換された不正な主ノードから送信されたものであるかを識別することができない（いわゆるリプレイ攻撃）。
【００３２】
そこで、従ノードが確認信号を送信するように構成されている場合、従ノードは、当該従ノードにて発生させた乱数を確認信号とし、その確認信号を鍵交換によって取得した暗号鍵で暗号化して送信し、主ノードは、確認信号を受信すると、確認信号を復号することで抽出した乱数に予め設定された認証子を付加してなる確認応答信号を、暗号鍵で暗号化し、カルエリアネットワークを介して返信するように構成することが望ましい。
【００３３】
この場合、確認信号には、鍵交換毎に異なる乱数が添付されるため、主ノードでは、その乱数を抽出できなければ、即ち、暗号鍵を知っていなければ、正しい確認応答信号を生成することができない。従って、従ノードでは、この確認応答信号を調べることで、確認応答信号の送信元が正当な主ノードであるか否かを識別することができ、このような主ノードを置換する不正を防止することができる。
【００３４】
また、従ノードは、鍵交換が実行されるべきタイミングで、予め設定された鍵待ち時間内に暗号鍵の配信を受けることができなかった場合、主ノードに対して鍵交換の実行を要求する要求信号をローカルエリアネットワークを介して送信するように構成してもよい。
【００３５】
この場合、例えば、従ノードに異常が生じて再起動（自己リセット）した場合等に、再起動した従ノードは、主ノードに対して鍵交換を要求することになるため、再起動後、速やかに暗号鍵を再取得することができ、従ノードにおける暗号通信の途絶を必要最小限に抑えることができる。
【００３６】
次に、第二発明の鍵配信装置は、ローカルエリアネットワークを介して暗号通信を行う通信システムにおいて、その通信システムを構成するノードのいずれか一つに搭載される。そして、鍵生成手段が、通信データの暗号化及び復号に用いる暗号鍵を、予め設定された鍵生成タイミングで生成すると、鍵配信手段が、その暗号鍵を予め用意された種鍵を用いて暗号化し、ローカルエリアネットワークを介して配信する。
【００３７】
また、リスト生成手段が、鍵配信手段が配信した暗号鍵を受信した他ノードからの確認信号をローカルエリアネットワークを介して受信し、その確認信号の返信があったノードを示した鍵確認リストを生成する。
【００３８】
すると、リスト配信手段が、その鍵確認リストを、ローカルエリアネットワークを介して放送形式で配信する。
このように構成された本発明の鍵配信装置は、第一発明の通信システムにおいて、暗号鍵の生成，配信、及び鍵確認リストの配信を行う主ノードを構成する際に、好適に用いることができる。
【００３９】
また、本発明の鍵配信装置では、暗号鍵を共有すべきノードの中で、確認信号の返信のない未確認ノードが存在する場合、再配信手段が、暗号鍵を再配信するように構成してもよい。
【００４０】
この場合、未確認ノードとのみ、鍵交換が再実行されるため、鍵交換の再実行に要する処理量を必要最小限に抑えることができる。
なお、リスト生成手段は、鍵配信手段による暗号鍵の配信後、予め設定された確認待ち待時間内に受信した確認信号に基づいて、鍵確認リストを生成することが望ましい。
【００４１】
この場合、一部のノードの異常により、期待する全てのノードから確認信号の返信が得られなくても、確認信号の返信が得られたノード間でのみ暗号通信を実行することができる。
【００４２】
次に、第三発明の鍵配信装置は、ローカルエリアネットワークを介して暗号通信を行う通信システムにおいて、その通信システムを構成するノードのいずれか一つに搭載される。そして、鍵生成手段が、通信データの暗号化及び復号に用いる暗号鍵を、予め設定された鍵生成タイミングで生成し、通知リスト配信手段が、暗号鍵が配信されるべきノードを示した通知リストを、ローカルエリアネットワークを介して放送形式で配信する。
【００４３】
この通知リスト配信手段による通知リストの配信後、鍵配信手段が、鍵生成手段により生成された暗号鍵を、予め用意された種鍵を用いて暗号化し、ローカルエリアネットワークを介して放送形式で配信する。
【００４４】
このように構成された本発明の鍵配信装置は、第一発明の通信システムにおいて、通知リストの配信、及び暗号鍵の生成，配信を行う主ノードを構成する際に、好適に用いることができる。
【００４５】
また、本発明の鍵配信装置では、再配信手段が、鍵配信手段が配信した暗号鍵を受信した他ノードからの確認信号を前記ローカルエリアネットワークを介して受信し、通知リストに示したノードの中で、確認信号の返信のない未確認ノードが存在する場合に、その未確認ノードを示した通知リスト及び暗号鍵を再配信するように構成してもよい。
【００４６】
この場合、未確認ノードとのみ鍵交換が再実行されるため、鍵交換の再実行に要する処理量を必要最小限に抑えることができる。
ところで、暗号鍵を共有すべき他ノードから受信する確認信号に乱数が含まれている場合、第二及び第三発明の鍵配信装置では、確認応答送信手段が、確認信号が受信されると、その確認信号を復号することで抽出した乱数に予め設定された認証子を付加してなる確認応答信号を、暗号鍵で暗号化し、ローカルエリアネットワークを介して送信するように構成することが望ましい。
【００４７】
この場合、確認応答信号の返信を受けたノードでは、確認応答信号を復号することで得られる乱数と認証子とが正しいものであるか否かを調べることで、鍵配信装置が搭載されたノードの正当性を確認することができる。
【００４８】
次に、第四発明の暗号処理装置は、ローカルエリアネットワークを介して暗号通信を行う通信システムにおいて、該通信システムを構成するノードに搭載される。
そして、暗号鍵設定手段が、予め設定された種鍵を用いて暗号化された暗号鍵をローカルエリアネットワークを介して受信すると、その旨を示す確認信号をローカルエリアネットワークを介して返信する。
【００４９】
すると、暗号処理手段が、暗号鍵受信手段により受信された暗号鍵を用いて、ローカルエリアネットワークを介して送受信される通信データの暗号化及び復号を行う。
このように構成された本発明の暗号処理装置は、第一発明の通信システムにおいて、暗号鍵の配信を受けるノードを構成する際に、好適に用いることができる。
【００５０】
そして、本発明の暗号処理装置では、確認リスト受信手段が、ローカルエリアネットワークを介して、確認信号を返信したノードが示された鍵確認リストを受信し、その鍵確認リストに自ノードが示されている場合に、暗号鍵受信手段の作動を禁止するように構成してもよい。
【００５１】
つまり、鍵確認リストに自ノードが示されている場合、即ち、暗号鍵の配信元との間で鍵交換が成功した場合に、その後、鍵交換に失敗したノードのために再実行される鍵交換に対して、無駄に応答してしまうことを防止することができる。
【００５２】
そして、上述の暗号鍵受信手段を備えている場合には、要求送信手段が、当該装置の起動後、予め設定された鍵待ち時間内に暗号鍵を受信できない場合、又は暗号鍵受信手段が確認信号を返信したにも関わらず鍵確認リストに自ノードが示されていない場合に、暗号鍵の配信元に対して暗号鍵の再配信を要求する要求信号をローカルエリアネットワークを介して送信するように構成することが望ましい。
【００５３】
この場合、暗号処理装置を搭載したノードが再起動したり、送信した確認信号が伝送中に紛失した場合に、要求信号の送信によって鍵交換を再実行させることができるため、自ノードが正常であるにも関わらず暗号鍵を共有できないという事態の発生を回避することができる。
【００５４】
また、本発明の暗号処理装置では、確認リスト受信手段の代わりに、通知リスト受信手段を設け、この通知リスト受信手段が、ローカルエリアネットワークを介して、暗号鍵を共有すべきノードが示された通知リストを受信し、その通知リストに自ノードが示されている場合に、暗号鍵受信手段を作動させるように構成してもよい。
【００５５】
そして、このような通知リスト受信手段を備えている場合には、更に、要求送信手段が、当該装置の起動後、予め設定されたリスト待ち時間内に通知リストを受信できない場合、又は通知リストの受信後、予め設定された鍵待ち時間内に暗号鍵を受信できない場合に、暗号鍵の配信元に対して暗号鍵の再配信を要求する要求信号をローカルエリアネットワークを介して送信するように構成することが望ましい。
【００５６】
このように構成された本発明の暗号処理装置によれば、暗号鍵の送信元が、鍵交換に失敗したノードのために鍵交換を再実行する際に、再送付される通知リストから鍵交換に成功したノードを除外するようにしておけば、鍵交換に成功したノードが、再実行される鍵交換に対して、無駄に応答してしまうことを防止することができる。
【００５７】
ところで、本発明の暗号処理装置では、暗号鍵受信手段を、当該装置にて発生された乱数を確認信号とし、その確認信号を前記暗号鍵で暗号化して送信するように構成し、更に、異常判定手段が、ローカルエリアネットワークを介して確認信号に対する確認応答信号を受信した場合、その確認応答信号を暗号鍵で復号した結果が、確認信号として送信した乱数、及び予め設定された認証子とは異なる場合に、暗号鍵の送信元に異常があると判定するように構成してもよい。
【００５８】
この場合、確認応答信号の送信元は、配信した暗号鍵を用いて確認信号を正しく復号することができなければ、正常な確認応答信号を生成することができないため、この確認応答信号を復調した結果を調べることで、確認応答信号の送信元、即ち、暗号鍵の送信元の正当性を判定することができる。
【００５９】
次に、第五発明の盗難防止装置は、複数の電子制御装置が車載ローカルエリアネットワークを介して互いに暗号通信を行い、且つ該暗号通信にて通信データの暗号化及び復号に用いる暗号鍵を電子制御装置間で互いに共有するための鍵交換を実行する通信システムを備えた車両に搭載される。そして、通信システムにて鍵交換を実行した結果に異常が検出された場合、異常対応手段が、車両周囲への報知、又は予め指定された外部装置への通報、或いは予め指定された特定車両制御（例えばエンジン始動）の禁止のうち、少なくともいずれか一つを実行するように構成されている。
【００６０】
つまり、盗難品である電子制御装置が車載ローカルエリアネットワークに接続された場合、盗難品である電子制御装置は、鍵交換を正常に行うことができず、通信システムにて異常（認証の失敗）が検出され、異常対応手段が作動することになる。
【００６１】
その結果、盗難品を取り付けると、車両が作動が制限されたり、警報などにより車両周囲に報知されてしまうため、盗難品を売ることが困難になり、ひいては車両盗難を防止することができる。
【発明を実施するための最良の形態】
【００６２】
以下に本発明の実施形態を図面と共に説明する。
［第１実施形態］
図１は、本実施形態の車両制御システムの概略構成を示すブロック図である。
【００６３】
本実施形態の車両制御システム１は、図１に示すように、それぞれバス状の通信線（以下「バスライン」と称する。）Ｌ１，Ｌ２に接続された複数の電子制御ユニット（ＥＣＵ）２０からなる第１及び第２の車載ローカルエリアネットワーク（ＬＡＮ）３，５と、第１及び第２の車載ＬＡＮ３，５を相互に接続するゲートウェイＥＣＵ１０と、車両の盗難を防止するための機能を提供する盗難防止装置３０とを備えている。
【００６４】
このうち、ＥＣＵ２０は、いずれも基本的には同様の構成をしており、バスラインＬ１（又はＬ２）へのデータの送出、バスラインＬ１（又はＬ２）からのデータの取込を行うトランシーバ２１と、周知のＣＡＮプロトコルに従って車載ＬＡＮ３（又は５）を介した通信を制御するＣＡＮコントローラ２２と、ＣＡＮコントローラ２２を介して送受信される通信データの暗号化及び復号を行うと共に、後述するＥＣＵ側認証処理を実行する暗号処理部２３と、ＣＰＵ，ＲＯＭ，ＲＡＭ，Ｉ／Ｏを中心に構成され、ＣＡＮコントローラ２２を制御して他のＥＣＵとの通信を行うことにより、他のＥＣＵと連動して、自ＥＣＵに割り当てられた機能を実現するための各種処理を実行するマイクロコンピュータ（マイコン）２４とを備えている。
【００６５】
但し、マイコン２４を構成するＩ／Ｏには、図示しないが、自ＥＣＵ２０に割り当てられた機能に応じて、その機能を実現するために必要なセンサやアクチュエータ等の各種機器が接続されている。また、暗号処理部２３は、暗号通信を可能なＥＣＵの一覧である鍵確認リスト、及び通信データの暗号化及び復号に用いる暗号鍵を記憶するための書換可能なメモリと、暗号鍵を取得する際に使用する種鍵が予め記憶された不揮発性メモリとを備えている。なお、書換可能なメモリに記憶される鍵確認リストについては、マイコン２４からの参照が可能なように構成されている。また、不揮発性メモリに記憶される種鍵は、全てのＥＣＵ２０に共通であるが、車両毎に異なったものが割り当てられる。
【００６６】
ゲートウェイＥＣＵ１０は、ＥＣＵ２０を構成するトランシーバ２１、ＣＡＮコントローラ２２、マイコン２４と同様に構成されたトランシーバ１１，１２、ＣＡＮコントローラ１４、マイコン１６を備えている。但し、トランシーバ１１はバスラインＬ１に接続され、トランシーバ１２はバスラインＬ２に接続されている。
【００６７】
また、ゲートウェイＥＣＵ１０は、トランシーバ１１，１２及びＣＡＮコントローラ１４から取り込んだデータの通過，不通過を、そのデータの宛先に従って制御するフィルタ１３と、ＣＡＮコントローラ１４を制御して他のＥＣＵとの通信を行うことにより、後述するＧＷ側認証処理を実行すると共に、この認証処理に基づいて、車載ＬＡＮ３，５に接続されたＥＣＵ２０の異常の有無を盗難防止装置３０に通知する鍵交換処理部１５とを備えている。
【００６８】
なお、鍵交換処理部１５は、暗号鍵の生成に使用する乱数を発生させる乱数発生装置と、鍵確認リストを記憶するための書換可能なメモリと、暗号鍵の配信に使用する種鍵が予め記憶された不揮発性メモリとを備えている。但し、不揮発性メモリに記憶される種鍵はＥＣＵ２０の暗号処理部２３に記憶されるものと同じものである。また、乱数発生装置は、例えば、疑似ランダムパターン発生回路，時計，ノイズ等を利用して乱数を発生させるように構成されている。
【００６９】
このように構成されたゲートウェイＥＣＵ１０及びＥＣＵ２０は、図示しないイグニションスイッチがオンされ、車両各部への電源供給が開始されることにより起動する。
そして、ＥＣＵ２０では、マイコン２４がＥＣＵ２０内各部の初期化を実行すると共に、ＣＡＮコントローラ２２がマイコン２４によって初期化されると、暗号処理部２３がマイコン２４からの指令によらず、自律的にＥＣＵ側認証処理を実行する。
【００７０】
このＥＣＵ側認証処理により、暗号処理部２３は、ゲートウェイＥＣＵ１０から暗号鍵を取得し、以後、マイコン２４が生成，処理する通信データの暗号化，復号を、この取得した暗号鍵を用いて行う。
【００７１】
そして、マイコン２４による初期化と、暗号処理部２３のＥＣＵ側認証処理が終了すると、マイコン２４は、自ＥＣＵに割り当てられた機能を実現するための通常処理を開始する。この通常処理では、他のＥＣＵ２０と暗号通信を行って、互いのデータを共有し合うことにより、全てのＥＣＵ２０が連動して車両制御を実現する。
【００７２】
ここで、ゲートウェイＥＣＵ１０の鍵交換処理部１５が実行するＧＷ側認証処理、及び各ＥＣＵ２０の暗号処理部２３が実行するＥＣＵ側認証処理の詳細を、図２に示すフローチャートに沿って説明する。
【００７３】
ＧＷ側認証処理では、まず、乱数発生装置を用いて暗号鍵を生成し（Ｓ１１０）、生成した暗号鍵を種鍵を用いて暗号化し、その暗号化により得られた暗号化データを、放送形式により、全てのＥＣＵ２０に一括して配信する（Ｓ１２０）。
【００７４】
そして、暗号鍵を取得したことを示す確認信号を、暗号鍵を共有すべき全てのＥＣＵ２０から受信するか（Ｓ１３０）、或いは、先のＳ１２０にて暗号鍵の配信を行ってから予め設定された確認待ち時間が経過するまで待機し（Ｓ１４０）、暗号鍵を共有すべき全てのＥＣＵから確認信号を受信するか、確認待ち時間が経過した場合には、鍵確認リストの生成を行う（Ｓ１５０）。
【００７５】
なお、確認信号は、後述するように配信した暗号鍵で暗号化されているため、ＥＣＵ２０から受信した暗号化データを暗号鍵で復号し、その復号に成功した場合にのみ、その確認信号の送信元であるＥＣＵ２０を、鍵確認リストに登録する。つまり、この鍵確認リストに登録されたＥＣＵ２０が、認証に成功したものとされる。
【００７６】
このようにして生成された鍵確認リストを暗号鍵を用いて暗号化し、この暗号化データを、放送形式により全てのＥＣＵ２０に一括して配信する（Ｓ１６０）と共に、認証処理の結果を盗難防止装置３０に通知して（Ｓ１７０）、本処理を終了する。なお、認証処理の結果は、一つでも認証に失敗したＥＣＵ２０がある場合には、異常ありとして通知する。
【００７７】
一方、ＥＣＵ側認証処理では、ゲートウェイＥＣＵ１０から放送形式で配信されてくる暗号化データを受信するまで待機する（Ｓ２１０）。
暗号化データを受信すると、その暗号化データを種鍵を用いて復号し、その復号により得られたデータを暗号鍵としてメモリに保存する（Ｓ２２０）。そして、暗号鍵を取得したことを表す確認信号（少なくとも自ＥＣＵを識別するためのＩＤを含む）を生成し、これを先に保存した暗号鍵を用いて暗号化して、ゲートウェイＥＣＵ１０に対して送信する（Ｓ２３０）。
【００７８】
その後、再び、放送形式で配信されてくる暗号化データを受信するまで待機し（Ｓ２４０）、暗号化データを受信すると、これをＳ２２０にて記憶した暗号鍵を用いて復号し、その復号により得られた鍵確認リストを、マイコン２４からアクセス可能なメモリに保存して（Ｓ２５０）、本処理を終了する。これにより、各ＥＣＵ２０のマイコン２４は、鍵確認リストに示されたＥＣＵ２０との暗号通信が可能となる。
【００７９】
つまり、ゲートウェイＥＣＵ１０及び他のＥＣＵ２０が上述した認証処理を実行すると、図３に示すように、ゲートウェイＥＣＵ１０にて生成された暗号鍵（種鍵を用いて暗号化）が放送形式で全てのＥＣＵ２０（図中ではＥＣＵ１〜ＥＣＵＮ）に一括して配信され、これを受信した各ＥＣＵ２０からは、ゲートウェイＥＣＵ１０に対して、それぞれ個別に確認信号（暗号鍵を用いて暗号化）が返送される。するとゲートウェイＥＣＵ１０からは、受信した確認信号に基づいて作成された鍵確認リスト（暗号鍵を用いて暗号化）が、放送形式で全てのＥＣＵ２０に一括して配信されることになる。
【００８０】
次に、盗難防止装置３０が実行する盗難防止処理を、図４に示すフローチャートに沿って説明する。
なお、盗難防止装置３０は、図１に示すように、ゲートウェイＥＣＵ１０の鍵交換処理部１５からの認証結果通知、車室内への侵入者の有無を検出する侵入センサ３２からの侵入検知信号、携帯型送信機から送信される各種指令を受信する受信機３３からの受信データを入力し、これらの入力に基づいて、エンジンを始動するスタータ３４、警報（室内灯，ハザードランプ，テールランプ，ヘッドランプ等を点滅させたり、ホーンを鳴らす等）を発生させる警報装置３５、車両外部のセキュリティ会社や警察に無線通信による通報を行う通報装置３６を制御するように構成されている。また、盗難防止装置３０は、常時起動しており、盗難防止処理も常時実行される。
【００８１】
図４に示すように、盗難防止処理では、まず、イグニッションスイッチがオンされるまでの間（Ｓ３２０：ＮＯ）は、侵入センサ３２からの侵入検知信号に基づいて、車室内への侵入者が検知されたか否かを判断し（Ｓ３１０）、侵入者が検知されたのであれば、警報装置３５を作動させることにより、警報によって車両周囲への報知を行うと共に、通報装置３６を作動させて、セキュリティ会社や警察等への通報を行って（Ｓ３７０）、本処理を終了する。
【００８２】
そして、イグニッションスイッチがオンされると（Ｓ３２０：ＹＥＳ）、受信機３３を介して受信した携帯型送信機からの受信データに基づいて、イグニッションスイッチをオンする指令を出した携帯型送信機の認証を行い（Ｓ３３０）、認証に失敗した場合には、Ｓ３７０に移行し警報装置３５及び通報装置３６を作動させて本処理を終了する。
【００８３】
一方、認証に成功した場合には、ゲートウェイＥＣＵ１０の鍵交換処理部１５から認証結果通知を受信するまで待機する（Ｓ３４０）。そして、認証結果通知を受信すると、その通知の内容が「異常あり」であるか否かを判断し（Ｓ３５０）、「異常あり」であれば、Ｓ３７０に移行し警報装置３５及び通報装置３６を作動させて本処理を終了する。
【００８４】
一方、認証結果通知の内容が「異常なし」であれば、スタータ３４を作動させることでエンジンを始動して（Ｓ３６０）、本処理を終了する。
以上説明したように、本実施形態では、図３に示すように、一つのＥＣＵ（ここではゲートウェイＥＣＵ）１０が暗号鍵を生成し、その暗号鍵を放送形式で他の全てのＥＣＵ２０に配信するようにされている。
【００８５】
従って、本実施形態では、個々のノード（ＥＣＵ）同士が、それぞれ個別に鍵交換を実行する従来のものと比較して、暗号鍵の数、及びその暗号鍵を共有する鍵交換のために必要な処理量（ひいては鍵交換に要する時間）を大幅に削減することができる。
【００８６】
また、本実施形態では、車両制御システム１が起動される毎に鍵交換を実行して暗号鍵を更新しているため、高いセキュリティ強度を保持することができ、しかも、鍵交換に要する時間が短いため、車両制御システム１の立ち上げに要する時間を増大させることもない。
【００８７】
また、本実施形態の車両制御システム１を搭載した車両では、盗難品であるＥＣＵを車載ＬＡＮ３，４に接続すると、その盗難品ＥＣＵは鍵交換を正常に行うことができず、ゲートウェイＥＣＵ１０の鍵交換処理部１５が生成する認証結果通知が「異常あり」となって、自動的に警報装置３５や通報装置３６が作動し、またエンジンを始動させることもできなくなる。
【００８８】
その結果、車両の所有者が盗難品を購入する意味がなくなり、盗難品を売ることが困難になるため、ＥＣＵ等の部品を目的とした車両盗難を抑止することができる。
なお、本実施形態において、Ｓ１１０が鍵生成手段、Ｓ１２０が鍵配信手段、Ｓ１５０がリスト生成手段、Ｓ１６０がリスト配信手段、Ｓ２１０〜Ｓ２３０が暗号鍵受信手段、暗号処理部２３が暗号処理手段、Ｓ３５０〜Ｓ３７０が異常対応手段に相当する。
［第２実施形態］
次に第２実施形態について説明する。
【００８９】
本実施形態では、ゲートウェイＥＣＵ１０のマイコン１６が実行するＧＷ側認証処理、及び他のＥＣＵ２０のマイコン２４が実行するＥＣＵ側認証処理の一部が、第１実施形態と異なるだけであるため、これらの処理についてのみ説明する。
【００９０】
まず、ＧＷ側認証処理を図５に示すフローチャートに沿って説明する。
なお、第１実施形態と同じ処理には、同一のステップ番号を付与して説明を省略し、新たに追加されたステップを中心に説明する。
【００９１】
図５に示すように、Ｓ１１０〜Ｓ１７０は、第１実施形態と同様であり、Ｓ１７０にて盗難防止装置３０に対するＥＣＵ認証結果通知を実行した後、暗号鍵を共有すべきＥＣＵ２０の中で、Ｓ１５０にて作成された鍵確認リストに未登録のもの（以下「未登録ＥＣＵ」と称する。）が存在するか否かを判断する（Ｓ１８０）。そして、未登録ＥＣＵが存在しなければ、ＥＣＵ２０のいずれかから、車載ＬＡＮ３，５を介して後述する鍵交換要求信号の受信するまで待機し（Ｓ１８５）、鍵交換要求信号を受信すると、その鍵交換要求信号の送信元ＥＣＵ２０を、鍵確認リストから除外し（Ｓ１９０）、Ｓ１２０で配信したものと同じ暗号鍵を再配信して（Ｓ１９５）、Ｓ１３０に戻る。
【００９２】
また、先のＳ１８０にて、未登録ＥＣＵが存在すると判定された場合には、Ｓ１８５，Ｓ１９０を実行することなく、Ｓ１９５に移行して、暗号鍵の再配信を直ちに実行する。
但し、暗号鍵の再配信では、これを受信したＥＣＵ２０が、Ｓ１２０による初回の配信と識別できるように、ＣＡＮプロトコルによって伝送データに付与するＩＤとして、初回の配信で付与されるもの（以下「初回配布用ＩＤ」と称する。）とは異なるもの（以下「再配布用ＩＤ」と称する。）を使用する。
【００９３】
次に、ＥＣＵ側認証処理を、図６に示すフローチャートに沿って説明する。
なお、第１実施形態と同じ処理には、同一のステップ番号を付与して説明を省略し、新たに追加されたステップを中心に説明する。
【００９４】
図６に示すように、Ｓ２１０〜Ｓ２４０は、第１実施形態と同様であり、Ｓ２１０にて暗号鍵の受信がないと判定された場合、本処理（又は本ＥＣＵ２０）の起動後、又は後述するＳ２４５にて否定判定された後、予め設定された鍵待ち時間が経過したか否かを判断し（Ｓ２７０）、鍵待ち時間が経過していなければ、Ｓ２１０に戻り、鍵待ち時間が経過していれば、ゲートウェイＥＣＵ１０に対して鍵交換の実行を要求する鍵交換要求信号を送信して（Ｓ２７５）、Ｓ２１０に戻る。
【００９５】
また、Ｓ２４０にて、鍵確認リストの受信が有ったと判定された場合、その受信した鍵確認リストに、自ＥＣＵ２０の登録が有るか否かを判断し（Ｓ２４５）、鍵確認リストに自ＥＣＵ２０の登録が無ければ、Ｓ２１０に戻る。
【００９６】
この場合、その後、鍵待ち時間を経過しても、暗号鍵の再配布を受けることができない場合には（Ｓ２７０：ＹＥＳ）、鍵交換要求信号を送信する（Ｓ２７５）ことになる。
一方、鍵確認リストに自ＥＣＵ２０の登録が有れば、その鍵確認リストを保存し（Ｓ２５０）、新たな暗号鍵を受信するまで待機する（Ｓ２６０）。そして、新たな暗号鍵を受信すると、その暗号鍵に付与されたＩＤが再配布用ＩＤであるか否かを判断し（Ｓ２６５）、再配布用のＩＤであれば、鍵交換（受信した暗号鍵を保存や確認信号の返信）を行うことなく、Ｓ２４０に戻り、一方、再配布用のＩＤでなければ、即ち、初回配布用のＩＤであれば、ゲートウェイＥＣＵ１０が再起動したものとして、Ｓ２２０に戻って、再度鍵交換（受信した暗号鍵の保存，確認信号の送信）を実行する。
【００９７】
つまり、ゲートウェイＥＣＵ１０及び他のＥＣＵ２０が上述した認証処理を実行すると、図７（ａ）に示すように、ゲートウェイＥＣＵ１０にて生成された暗号鍵（種鍵を用いて暗号化）が初回配布用ＩＤを用いて放送形式で全てのＥＣＵ２０（図中ではＥＣＵ１〜ＥＣＵＮ）に一括して配信され、この配信された暗号鍵が各ＥＣＵ２０にて保存されると共に、暗号鍵を受信した各ＥＣＵ２０からは、ゲートウェイＥＣＵ１０に対して、それぞれ個別に鍵確認（暗号鍵を用いて暗号化）が返送される。
【００９８】
この時、ＥＣＵ１〜ＥＣＵＮのいずれか（図ではＥＣＵ２）から送信された確認信号が、ノイズによる通信不良等により、ゲートウェイＥＣＵ１０で受信されなかった場合、ゲートウェイＥＣＵ１０からは、確認信号の返信のないＥＣＵ２が除外された鍵確認リスト（暗号鍵を用いて暗号化）が、放送形式で全てのＥＣＵ２０に一括して配信され、この配信された鍵確認リストが各ＥＣＵ２０にて保存される。
【００９９】
この鍵確認リストに続けて、ゲートウェイＥＣＵ１０からは、先に送付したものと同じ暗号鍵が、再配布用ＩＤを用いて放送形式で全てのＥＣＵ２０に一括して配信される。すると、鍵確認リストから除外されているＥＣＵ２からのみ、確認信号が返信され、これを受信したゲートウェイＥＣＵ１０からは、新たに確認信号の返信が確認されたＥＣＵ２を追加した鍵確認リストが、放送形式で全てのＥＣＵ２０に一括して配信され、この配信された確認リストが各ＥＣＵ２０にて改めて保存される。
【０１００】
また、図７（ｂ）に示すように、鍵交換が正常に終了した後、暗号鍵を共有するＥＣＵ１〜ＥＣＵＮのいずれか（図ではＥＣＵ２）が、何等かの理由によって再起動した場合、その再起動したＥＣＵ２からは、鍵交換要求信号が送信され、これを受信したゲートウェイＥＣＵ１０からは、先に送付したものと同じ暗号鍵が、再配布用ＩＤを用いて放送形式で全てのＥＣＵ２０に一括して配信される。以下、先に説明した場合と同様に、ＥＣＵ２からの確認信号の送信、ゲートウェイＥＣＵ１０からの鍵確認リストの再配布が実行される。
【０１０１】
以上説明したように、本実施形態の車両制御システム１においては、第１実施形態で行う処理に加えて、ゲートウェイＥＣＵ１０は、暗号鍵を共有すべきＥＣＵ２０の中で、暗号鍵の配信に対する確認信号の返信のないものが存在する時には、鍵交換を再実行する処理を行い、また、ＥＣＵ２０は、ゲートウェイＥＣＵ１０から暗号鍵や鍵確認リストを受信できなかった時に、鍵交換要求信号を送信して、ゲートウェイＥＣＵ１０に鍵交換を再実行させる処理を行うようにされている。
【０１０２】
従って、本実施形態の車両制御システム１によれば、第１実施形態の場合と同様の効果を得ることができるだけでなく、通信不良やＥＣＵ２０の再起動が発生した場合でも、そのＥＣＵ２０に暗号鍵を確実に共有させることができる。
【０１０３】
つまり、ゲートウェイＥＣＵ１０や他のＥＣＵ２０の異常や故障ではないにも関わらず、何らかの外部要因（例えば外来ノイズによる通信不良等）によって、暗号通信が実行不能となってしまうことを確実に防止することができる。
【０１０４】
また、本実施形態では、鍵交換を再実行した際には、鍵確認リストに未登録のＥＣＵ２０のみが確認信号を返信するようにされているため、鍵交換に成功した（鍵確認リストに登録済の）ＥＣＵ２０に不要な処理を強いることなく、鍵交換の再実行を必要最小限の処理量にて実現することができる。
【０１０５】
なお、本実施形態において、Ｓ１８０，Ｓ１９５が再配信手段（請求項１３）、Ｓ２４０〜Ｓ２６０が確認リスト受信手段、Ｓ２７０，Ｓ２７５が要求送信手段に相当する。
［第３実施形態］
次に第３実施形態について説明する。
【０１０６】
本実施形態では、ゲートウェイＥＣＵ１０のマイコン１６が実行するＧＷ側認証処理、及び他のＥＣＵ２０のマイコン２４が実行するＥＣＵ側認証処理が、第１実施形態のものと異なるだけであるため、これらの処理についてのみ説明する。
【０１０７】
図８は、ゲートウェイＥＣＵ１０の鍵交換処理部１５が実行するＧＷ側認証処理、及び各ＥＣＵ２０の暗号処理部２３が実行するＥＣＵ側認証処理の詳細を表すフローチャートである。
【０１０８】
図８に示すように、ＧＷ側認証処理では、まず、乱数発生装置を用いて暗号鍵を生成し（Ｓ３１０）、暗号鍵を共有すべきＥＣＵ２０を示した通知リストを、放送形式により全てのＥＣＵ２０に一括して配信する（Ｓ３２０）。なお、通知リストは、そのまま配信してもよいし、種鍵で暗号化したものを配信してもよい。
【０１０９】
その後、Ｓ３１０にて生成した暗号鍵を種鍵を用いて暗号化し、その暗号化により得られた暗号化データを、放送形式により、全てのＥＣＵ２０に一括して配信する（Ｓ３３０）。
【０１１０】
そして、暗号鍵を取得したことを示す確認信号を、通知リストに示した全てのＥＣＵ２０から受信するか（Ｓ３４０）、或いは、先のＳ３３０にて暗号鍵の配信を行ってから予め設定された確認待ち時間が経過するまで待機し（Ｓ３５０）、通知リストに示した全てのＥＣＵ２０から確認信号を受信するか、確認待ち時間が経過した場合には、受信した確認信号に基づいて判定したＥＣＵ２０の認証結果を盗難防止装置３０に通知して（Ｓ３６０）、本処理を終了する。
【０１１１】
なお、確認信号は、後述するように配信した暗号鍵で暗号化されているため、ＥＣＵ２０から受信した暗号化データを暗号鍵で復号する。そして、通知リストに示した全ＥＣＵ２０からの確認信号について、その復号に成功した場合には、認証結果は異常なしとして通知し、確認信号の返信のないＥＣＵ２０が一つでも存在する場合、或いは復号に失敗した確認信号が一つでも存在する場合には、認証結果は異常ありとして通知する。
【０１１２】
一方、ＥＣＵ側認証処理では、ゲートウェイＥＣＵ１０から放送形式で配信されてくる通知リストを受信するまで待機する（Ｓ４１０）。
通知リストを受信すると、その通知リストに自ＥＣＵ２０が示されているか否か、即ち、鍵交換が必要なＥＣＵ２０であるか否かを判断し（Ｓ４２０）、通知リストに自ＥＣＵ２０が示されていなければ、鍵交換は不要であるとして、そのまま本処理を終了する。
【０１１３】
一方、通知リストに自ＥＣＵ２０が示されていれば、鍵交換が必要であるとして、暗号鍵を受信するまで待機し（Ｓ４３０）、暗号鍵を受信すると、その暗号鍵をメモリに保存する（Ｓ４４０）。なお、暗号鍵は、種鍵を用いて暗号化されているため、メモリには、受信した暗号化データを種鍵を用いて復号した結果を保存する。
【０１１４】
そして、暗号鍵を取得したことを表す確認信号を生成し、これを先に保存した暗号鍵を用いて暗号化して、ゲートウェイＥＣＵ１０に対して送信して（Ｓ４５０）、本処理を終了する。
【０１１５】
これにより、確認信号を返信したＥＣＵ２０のマイコン２４は、通知リストに示されたＥＣＵ２０との暗号通信が可能となる。
つまり、ゲートウェイＥＣＵ１０及び他のＥＣＵ２０が上述した認証処理を実行すると、図９に示すように、ゲートウェイＥＣＵ１０からは、通知リスト、暗号鍵（種鍵を用い手暗号化）が、その順番で放送形式で全てのＥＣＵ２０（図中ではＥＣＵ１〜ＥＣＵＮ）に一括して配信される。そして、これら通知リスト及び暗号鍵を受信した各ＥＣＵ２０のうち、通知リストに示されたＥＣＵ２０から、ゲートウェイＥＣＵ１０に対して、それぞれ個別に確認信号（暗号鍵を用いて暗号化）が返信される。
【０１１６】
以上説明したように、本実施形態では、鍵交換後に、その鍵交換の結果（暗号鍵の共有が確認されたＥＣＵ２０）を示した鍵確認リストを各ＥＣＵ２０に配信する代わりに、鍵交換前に、鍵交換を必要とする（暗号鍵を共有すべき）ＥＣＵを示した通知リストを各ＥＣＵ２０に配信する以外は、第１実施形態のものと同様に構成されている。従って、第１実施形態の場合と同様の効果を得ることができる。
【０１１７】
なお、本実施形態において、Ｓ３１０が鍵生成手段、Ｓ３２０が通知リスト配信手段、Ｓ３３０が鍵配信手段、Ｓ４１０，Ｓ４２０が通知リスト受信手段、Ｓ４３０が暗号鍵受信手段に相当する。
［第４実施形態］
次に第４実施形態について説明する。
【０１１８】
本実施形態では、ゲートウェイＥＣＵ１０のマイコン１６が実行するＧＷ側認証処理、及び他のＥＣＵ２０のマイコン２４が実行するＥＣＵ側認証処理の一部が、第３実施形態と異なるだけであるため、これらの処理についてのみ説明する。
【０１１９】
まず、ＧＷ側認証処理を図１０に示すフローチャートに沿って説明する。
なお、第３実施形態と同じ処理には、同一のステップ番号を付与して説明を省略し、新たに追加されたステップを中心に説明する。
【０１２０】
図１０に示すように、Ｓ３１０〜Ｓ３６０は、第３実施形態と同様であり、Ｓ３６０にて盗難防止装置３０に対するＥＣＵ認証結果通知を実行した後、先に配信した通知リストに示したＥＣＵ２０の中で、確認信号の返信のないもの（以下「未確認ＥＣＵ」と称する。）が存在するか否かを判断する（Ｓ３７０）。
【０１２１】
そして、未確認ＥＣＵが存在しなければ、ＥＣＵ２０のいずれかから、後述する鍵交換要求信号を受信するまで待機し（Ｓ３８０）、鍵交換要求信号を受信すると、その鍵交換要求信号の送信元ＥＣＵ２０を示した通知リストを、放送形式で再配信して（Ｓ３９０）、Ｓ３３０に戻る。
【０１２２】
一方、先のＳ３７０にて、未確認ＥＣＵが存在すると判定された場合には、その未確認ＥＣＵを示した通知リストを、放送形式で再配信して（Ｓ３９５）、Ｓ３３０に戻る。
次に、ＥＣＵ側認証処理を、図１１に示すフローチャートに沿って説明する。
【０１２３】
なお、第３実施形態と同じ処理には、同一のステップ番号を付与して説明を省略し、新たに追加されたステップを中心に説明する。
図１１に示すように、Ｓ４１０〜Ｓ４５０は、第３実施形態と同様である。但し、Ｓ４１０にて通知リストの受信がないと判定された場合、本処理（又は本ＥＣＵ２０）の起動後、予め設定された通知待ち時間が経過したか否かを判断し（Ｓ４７０）、通知待ち時間が経過していなければ、Ｓ４１０に戻り、通知待ち時間が経過していれば、ゲートウェイＥＣＵ１０に対して鍵交換の実行を要求する鍵交換要求信号を送信して（Ｓ４９０）、Ｓ４１０に戻る。
【０１２４】
また、Ｓ４３０にて、暗号鍵の受信がないと判定された場合、通知リストの受信後、予め設定された鍵待ち時間が経過したか否かを判断する（Ｓ４８０）。そして、鍵待ち時間が経過していなければ、Ｓ４３０に戻り、鍵待ち時間が経過していれば、Ｓ４９０に移行して、鍵交換要求信号を送信し（Ｓ４９０）、Ｓ４１０に戻る。
【０１２５】
また、Ｓ４２０にて、通知リストに自ＥＣＵ２０が示されておらず、鍵交換が不要であると判定された場合、又はＳ４５０にて確認信号を送信した後は、通知リストを受信するまで待機し（Ｓ４６０）、通知リストを受信すると、Ｓ４２０に戻る。
【０１２６】
つまり、ゲートウェイＥＣＵ１０及び他のＥＣＵ２０が上述した認証処理を実行すると、図１２（ａ）に示すように、ゲートウェイＥＣＵ１０からは通知リストが、暗号鍵を共有すべきＥＣＵ２０（図中ではＥＣＵ１〜ＥＣＵＮ）が示された通知リストが、放送形式で全てのＥＣＵ２０に一括して配信され、これに続けて暗号鍵（種鍵を用いて暗号化）が放送形式で全てのＥＣＵ２０に一括して配信される。
【０１２７】
この配信された暗号鍵が、通知リストに示された各ＥＣＵ２０にて保存されると共に、暗号鍵を保存した各ＥＣＵ２０からは、ゲートウェイＥＣＵ１０に対して、それぞれ個別に鍵確認（暗号鍵を用いて暗号化）が返送される。
【０１２８】
この時、ＥＣＵ１〜ＥＣＵＮのいずれか（図ではＥＣＵ２）から送信された確認信号が、ノイズによる通信不良等により、ゲートウェイＥＣＵ１０で受信されなかった場合、ゲートウェイＥＣＵ１０からは、確認信号の返信のないＥＣＵ２が示された通知リストが、放送形式で全てのＥＣＵ２０に一括して配信され、これに続けて、先に送付したものと同じ暗号鍵が放送形式で全てのＥＣＵ２０に一括して再配信される。
【０１２９】
すると、この配信された暗号鍵が通知リストに示されたＥＣＵ２にて保存されると共に、通知リストに示され且つ暗号鍵を保存したＥＣＵ２からのみ確認信号が返信される。この確認信号がゲートウェイＥＣＵ１０にて受信された場合には鍵交換が終了し、確認信号が受信されなかった場合には、鍵交換が再実行される。
【０１３０】
また、図１２（ｂ）に示すように、鍵交換が正常に終了した後、暗号鍵を共有するＥＣＵ１〜ＥＣＵＮのいずれか（図ではＥＣＵ２）が、何等かの理由によって再起動した場合、その再起動したＥＣＵ２からは、鍵交換要求信号が送信される。
【０１３１】
この鍵交換要求信号を受信したゲートウェイＥＣＵ１０からは、鍵交換要求信号の送信元であるＥＣＵ２を示した通知リストが放送形式で全てのＥＣＵ２０に一括して配信され、これに続けて、先に送付したものと同じ暗号鍵が、放送形式で全てのＥＣＵ２０に一括して再配信される。以下、先に説明した場合と同様に、ＥＣＵ２からの確認信号の返信が行われ、確認信号の返信の有無によって、鍵交換が終了或いは再実行される。
【０１３２】
以上説明したように、本実施形態の車両制御システム１においては、第３実施形態で行う処理に加えて、ゲートウェイＥＣＵ１０は、通知リストに示した（即ち、暗号鍵を共有すべき）ＥＣＵ２０の中で、暗号鍵の配信に対する確認信号の返信のないものが存在する時には、鍵交換を再実行する処理を行い、また、ＥＣＵ２０は、ゲートウェイＥＣＵ１０から通知リストや暗号鍵を受信できなかった時に、鍵交換要求信号を送信して、ゲートウェイＥＣＵ１０に鍵交換を再実行させる処理を行うようにされている。
【０１３３】
従って、本実施形態の車両制御システムによれば、第３実施形態の場合と同様の効果を得ることができるだけでなく、通信不良やＥＣＵ２０の再起動が発生した場合でも、各ＥＣＵ２０に暗号鍵を確実に共有させることができる。
【０１３４】
つまり、ゲートウェイＥＣＵ１０や他のＥＣＵ２０の異常や故障ではないにも関わらず、何らかの外部要因（例えば外来ノイズによる通信不良等）によって、暗号通信が実行不能となってしまうことを防止することができる。
【０１３５】
また、本実施形態では、通知リストに示されたＥＣＵ２０のみが鍵交換を実行し、鍵交換を再実行する際には、鍵交換に成功したＥＣＵ２０を通知リストから除外するようにされているため、鍵交換に成功したＥＣＵ２０に不要な処理を強いることなく、鍵交換の再実行を必要最小限の処理量にて実現することができる。
【０１３６】
なお、本実施形態において、Ｓ３７０〜ＳＳ９５が再配信手段（請求項１６）、Ｓ４１０〜Ｓ４２０が通知リスト受信手段、Ｓ４７０〜Ｓ４９０が要求送信手段に相当する。
［第５実施形態］
次に、第５実施形態について説明する。
【０１３７】
本実施形態では、ＥＣＵ２０が暗号鍵生成に用いるものとは異なる第２の乱数発生装置（図示せず）を備えている点、及び、ゲートウェイＥＣＵ１０のマイコン１６が実行するＧＷ側認証処理、及び他のＥＣＵ２０のマイコン２４が実行するＥＣＵ側認証処理の一部が追加，変更されている点が、第１実施形態と異なるだけであるため、これらについてのみ説明する。
【０１３８】
なお、ＧＷ側認証処理では、第１実施形態のＳ１３０〜Ｓ１４０の代わりに、図１３（ａ）に示すフローチャートが挿入され、ＥＣＵ側認証処理では、第１実施形態のＳ２４０とＳ２５０の間に、図１３（ｂ）に示すフローチャートが挿入されているだけであるため、第１実施形態と同じ処理には、同一のステップ番号を付与して説明を省略し、新たに追加されたステップを中心に説明する。
【０１３９】
まず、ＧＷ側認証処理では、Ｓ１１０〜Ｓ１２０は第１実施形態の場合と同様であり、Ｓ１２０にて暗号鍵の配信を行った後、暗号鍵を取得したことを示す確認信号を受信するか（Ｓ５１０）、或いは、先のＳ１２０にて暗号鍵の配信を行ってから予め設定された確認待ち時間が経過するまで待機する（Ｓ５４０）。
【０１４０】
そして、確認信号を受信した場合は、確認信号を暗号鍵で復号することで抽出される乱数に、予め設定された認証子を付加することで確認応答信号を生成し、この確認応答信号を暗号鍵で暗号化して、確認信号の送信元に返信する（Ｓ５２０）。更に、暗号鍵を共有すべき全てのＥＣＵ２０から確認信号の返信を受けたか否かを判断し（Ｓ５３０）、未だ確認信号の返信を受けていないＥＣＵ２０があれば、Ｓ５４０に移行し、暗号鍵を共有すべき全てのＥＣＵ２０から確認信号の返信を受けていれば、Ｓ１５０に移行する。
【０１４１】
また、Ｓ５４０にて、確認待ち時間が経過したと判定された場合も、Ｓ１５０に移行する。そして、Ｓ１５０〜Ｓ１９０は、第１実施形態と同様である。
次に、ＥＣＵ側認証処理では、Ｓ２１０〜Ｓ２４０は第１実施形態の場合と同様であり、Ｓ２４０にて、暗号鍵を受信したと判定されると、第２の乱数発生装置から乱数を取得し（Ｓ６１０）、取得した乱数を確認信号として、この確認信号を配信を受けた暗号鍵で暗号化して、ゲートウェイＥＣＵ１０に送信する（Ｓ６２０）。
【０１４２】
その後、ゲートウェイＥＣＵ１０から、確認応答信号を受信するか（Ｓ６３０）、Ｓ６２０にて確認信号を送信後、予め設定された確認応答待ち時間が経過するまで待機する（Ｓ６４０）。
【０１４３】
そして、確認応答信号を受信した場合には、確認応答信号を復号することで得られた乱数が、確認信号として送信したものと一致し、且つその乱数に正しい認証子が付加されているか否かを判断し（Ｓ６５０）、肯定判定された場合は、Ｓ２５０に移行する。このＳ２５０は、第１実施形態と同様である。
【０１４４】
一方、確認応答信号に異常があり、Ｓ６５０にて否定判定されるか、或いはＳ６４０にて確認応答待ち時間が経過したと判定された場合、確認応答信号の送信元であるゲートウェイＥＣＵ１０に異常があるものとして、異常対応処理を実行して（Ｓ６６０）、本処理を終了する。なお、異常対応処理としては、ＥＣＵ２０の機能を停止すること等が考えられる。
【０１４５】
つまり、ゲートウェイＥＣＵ１０及び他のＥＣＵ２０が上述した認証処理を実行すると、図１４に示すように、ゲートウェイＥＣＵ１０にて生成された暗号鍵（種鍵を用いて暗号化）が放送形式で全てのＥＣＵ２０（図中ではＥＣＵ１〜ＥＣＵＮ）に一括して配信されると、これを受信した各ＥＣＵ２０からは、ゲートウェイＥＣＵ１０に対して、それぞれ個別に自ＥＣＵ２０内で発生させた乱数からなる確認信号（暗号鍵を用いて暗号化）が返信される。するとゲートウェイＥＣＵ１０からは、各確認信号毎に、その確認信号から抽出した乱数に認証子を付加した確認応答信号（暗号鍵を用いて暗号化）が、各ＥＣＵ２０に対して個別に返信される。
【０１４６】
以上説明したように、本実施形態の車両制御システム１においては、第１実施形態での処理に加えて、確認信号に対する応答である確認応答信号をゲートウェイＥＣＵ１０に送信させる処理を行うようにされており、しかも、暗号鍵を知っていなければ、正しい確認応答信号を生成することができないようにすることにより、確認応答信号からゲートウェイＥＣＵ１０の正当性をＥＣＵ２０側で判定できるようにされている。
【０１４７】
従って、本実施形態の車両制御システム１によれば、第１実施形態の場合と同様の効果を得ることができるだけでなく、ゲートウェイＥＣＵ１０を置換する不正が行われたとしても、これを検出して異常対処処理を実行することができ、このような不正を防止することができる。
【０１４８】
なお、本実施形態において、Ｓ５１０〜Ｓ５２０が確認応答送信手段、Ｓ６５０〜Ｓ６６０が異常判定手段に相当する。
また、本実施形態では、図１３（ａ）に示すフローチャートを第１実施形態に適用したが、第２実施形態のＳ１３０〜Ｓ１４０、又は第３，第４実施形態のＳ３４０〜Ｓ３５０の代わりに、図１３（ａ）に示すフローチャートを挿入し、第２実施形態のＳ２４０とＳ２５０の間、又は第３，第４実施形態のＳ４３０とＳ４４０の間に、図１３（ｂ）に示すフローチャートを挿入してもよい。
［他の実施形態］
以上、本発明のいくつかの実施形態について説明したが、本発明は上記実施形態に限定されるものではなく、様々な態様にて実施することが可能である。
【０１４９】
例えば、上記実施形態では、ゲートウェイＥＣＵ１０を介して接続された二つの車載ＬＡＮ３，５は、同じ暗号鍵を用いているが、車載ＬＡＮ毎に異なる暗号鍵を用いるように構成してもよい。この場合、ゲートウェイＥＣＵ１０には、ゲートウェイＥＣＵ１０を通過する暗号化データがある場合、その暗号化データを一端復号し、再度暗号化する機能を付加する必要がある。
【０１５０】
また、上記実施形態では、ＥＣＵ２０は、暗号処理部２３をマイコン２４とは別の構成として設けられているが、イグニッションスイッチの状態によらず常時起動状態にあるＥＣＵでは、暗号処理部２３を省略して、その機能をマイコン２４が実行するように構成してもよい。
【０１５１】
また、上記実施形態では、車載ＬＡＮ３，５としてバス型のものを用いているが、スター型や、バス型とスター型とを複合した車載ＬＡＮ（例えばFlex Ray）等を用いてもよい。
【図面の簡単な説明】
【０１５２】
【図１】実施形態の車両制御システムの構成を示すブロック図である。
【図２】第１実施形態におけるＧＷ側認証処理、及びＥＣＵ側認証処理の内容を示すフローチャートである。
【図３】第１実施形態におけるゲートウェイＥＣＵと他のＥＣＵとの間で実行される認証処理（鍵交換）を実行した時のデータの流れを示す説明図である。
【図４】盗難防止処理の内容を示すフローチャートである。
【図５】第２実施形態におけるＧＷ側認証処理の内容を示すフローチャートである。
【図６】第２実施形態におけるＥＣＵ側認証処理の内容を示すフローチャートである。
【図７】第２実施形態におけるゲートウェイＥＣＵと他のＥＣＵとの間で実行される認証処理（鍵交換）を実行した時のデータの流れを示す説明図である。
【図８】第３実施形態におけるＧＷ側認証処理、及びＥＣＵ側認証処理の内容を示すフローチャートである。
【図９】第３実施形態におけるゲートウェイＥＣＵと他のＥＣＵとの間で実行される認証処理（鍵交換）を実行した時のデータの流れを示す説明図である。
【図１０】第４実施形態におけるＧＷ側認証処理の内容を示すフローチャートである。
【図１１】第４実施形態におけるＥＣＵ側認証処理の内容を示すフローチャートである。
【図１２】第４実施形態におけるゲートウェイＥＣＵと他のＥＣＵとの間で実行される認証処理（鍵交換）を実行した時のデータの流れを示す説明図である。
【図１３】第５実施形態におけるＧＷ側認証処理、及びＥＣＵ側認証処理の内容を示すフローチャートである。
【図１４】第５実施形態におけるゲートウェイＥＣＵと他のＥＣＵとの間で実行される認証処理（鍵交換）を実行した時のデータの流れを示す説明図である。
【図１５】従来装置の構成、及び動作を示す説明図である。
【図１６】従来装置にて認証処理（鍵交換）を実行した時のデータの流れを示す説明図である。
【符号の説明】
【０１５３】
１…車両制御システム、３，５…車載ＬＡＮ、１０…ゲートウェイＥＣＵ、１１，１２，２１…トランシーバ、１３…フィルタ、１４，２２…ＣＡＮコントローラ、１５…鍵交換処理部、１６，２４…マイコン、２０…ＥＣＵ、２３…暗号処理部、３０…盗難防止装置、３２…侵入センサ、３３…受信機、３４…スタータ、３５…警報装置、３６…通報装置、Ｌ１，Ｌ２…バスライン。
【図１】
2005341528.tif 000003
【図２】
2005341528.tif 000004
【図３】
2005341528.tif 000005
【図４】
2005341528.tif 000006
【図５】
2005341528.tif 000007
【図６】
2005341528.tif 000008
【図７】
2005341528.tif 000009
【図８】
2005341528.tif 000010
【図９】
2005341528.tif 000011
【図１０】
2005341528.tif 000012
【図１１】
2005341528.tif 000013
【図１２】
2005341528.tif 000014
【図１３】
2005341528.tif 000015
【図１４】
2005341528.tif 000016
【図１５】
2005341528.tif 000017
【図１６】
2005341528.tif 000018