車載ネットワークシステム
【課題】各車載制御装置の処理負荷(およびコスト)の上昇を抑えつつ、構成証明を実施する機能を備えた車載ネットワークを提供し、車両のセキュリティを向上させる。
【解決手段】本発明に係る車載ネットワークシステムは、車載制御装置を認証する構成管理装置を備え、構成管理装置は、構成証明を実施するために用いる構成証明データを、車載ネットワークに接続する登録装置を介して車載制御装置に配信する。
【解決手段】本発明に係る車載ネットワークシステムは、車載制御装置を認証する構成管理装置を備え、構成管理装置は、構成証明を実施するために用いる構成証明データを、車載ネットワークに接続する登録装置を介して車載制御装置に配信する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、車載ネットワークシステムに関する。
【背景技術】
【0002】
近年、乗用車、トラック、バス等には、各機能部を制御する車載ECU(Electronic Control Unit)が多数搭載されている。各ECUは車載ネットワークを介して相互接続し、協調動作する。
【0003】
通常、車載ECUが搭載している制御プログラムは、車載ECUに内蔵されているマイクロコンピュータのフラッシュROM(Read Onle Memory)などの記憶装置に格納されている。この制御プログラムのバージョンは、製造者によって管理されており、正規のソフトウェアバージョンを組み合わせることにより、単独機能および車載ネットワークを通じての協調機能が正常に動作するように意図されている。
【0004】
したがって、意図しないソフトウェアを搭載した車載ECU、または意図的に改竄された車載ECUが車載ネットワークに接続されることは、車両のセキュリティの観点から看過できない。
【0005】
各車載ECUが自局のソフトウェアの真正性を外部に証明すること、さらには全ての関連する車載ECUの真正性を証明することを、構成証明と呼ぶ。構成証明が得られた場合は、製造者によって提供された正しいプログラムを組み合わせ、意図した制御が実施されているという確証となる。
【0006】
下記特許文献1には、共通鍵または共通鍵生成源を複数の車載ECU間で共有し、この情報を共有していると推定されているECU間で暗号化通信が成立するか否かにより、上記構成証明を実施する手法が開示されている。
【0007】
下記特許文献2には、KPS(Key Predistribution System)方式の共通鍵配信手法が開示されている。同方式は、特許文献1において共通鍵生成源として利用することができる。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開2010−11400号公報
【特許文献2】特公平5−48980号公報
【発明の概要】
【発明が解決しようとする課題】
【0009】
上記特許文献1では、共通鍵または共通鍵生成源を複数のECU間で共有させるため、センターサーバなどの外部インフラが必要である。また、車載ECU間で暗号化通信が成立することをもって構成証明に代えるため、暗号化通信を実施する際に多大な計算機パワーが必要となる。以下、これら2点の課題について詳述する。
【0010】
(1)センターサーバについて
(1.1)情報集約について
センターサーバは、全車の鍵情報が集約されている外部サーバであり、車載ネットワークを構成する各車載ECUはそれぞれセンターサーバに接続して鍵情報を受け取らなければならない。鍵情報の全てがセンターサーバに集約されているため、車載ECUとセンターサーバとの間の通信が妨害されたり、センターサーバ自体が攻撃されたり、悪意の第3者がセンターサーバになりすましたりした場合は、システム全体が崩壊しかねない。
【0011】
(1.2)センターサーバとの間の通信について
KPS方式によって配信する共通鍵生成源は、車載ネットワークに参加しているECU間で通信するために用いるものである。したがって、ECU間で安全に通信するためには、まず初期化処理としてセンターサーバから共通鍵生成源を取得する必要がある。このとき各ECUがセンターサーバと通信するために用いる暗号化鍵は、ECU毎に固有の暗号化鍵ではなく、固定の暗号化鍵を使わざるを得ない。なぜなら、車載ECUは、部品メーカにより量産され組み立てメーカに納入されるものであり、初期化処理のための暗号化鍵は、車種単位、同一部品番号単位、またはIDの等しいロット単位で、必然的にバリエーションが固定されるためである。暗号化鍵が固定であると、悪意の第3者にとってはECUとセンターサーバの間の通信を盗聴しやすくなるので、これを利用して初期化鍵を不正入手される可能性がある。初期化鍵が不正入手されると、センターサーバの情報が不正に引き出される可能性がある。また、車載ECUに対して偽りの共通鍵を配信し、他の車載ECUとの間の通信を妨害される可能性もある。
【0012】
(2)暗号化通信について
特許文献1に記載されている技術では、KPS方式に基づいて通信相手方の鍵を復元する計算資源と、その鍵を用いて暗号化通信するための共通鍵暗号処理(例えば、DES:Data Encryption Standard方式の暗号処理)を実行する計算資源とが必要になる。これらの処理は、現状の車載ECUの能力(CPUの計算能力、ROM/RAMの容量など)にとって非常に大きなリソースを要求する。したがって、特許文献1に記載されている暗号化通信を実現するためには、車載ECUのコスト上昇が避けられない。
【0013】
現状の車載ECUを設計する際には、各ECUおよびその構成部品の原価低減を積み上げて、車両システム全体の価格戦略を摺り合わせている。車載ECUの構成証明という目的に対して、これら構成部品の価格が上昇することは、到底許容できるものではない。
【0014】
本発明は、上記のような課題を解決するためになされたものであり、各車載制御装置の処理負荷(およびコスト)の上昇を抑えつつ、構成証明を実施する機能を備えた車載ネットワークを提供し、車両のセキュリティを向上させることを目的とする。
【課題を解決するための手段】
【0015】
本発明に係る車載ネットワークシステムは、車載制御装置を認証する構成管理装置を備え、構成管理装置は、構成証明を実施するために用いる構成証明データを、車載ネットワークに接続する登録装置を介して車載制御装置に配信する。
【発明の効果】
【0016】
本発明に係る車載ネットワークシステムは、車載制御装置を認証する構成管理装置が車載ネットワーク内に配置されているため、車内の鍵情報を車両外で保持する必要がない。したがって、安全でない通信方式を用いて車外と通信する必要がなくなり、セキュリティが向上する。また、登録装置は必ずしも車載ネットワークに常時接続されている必要はなく、車載制御装置を新規に登録する際に、オペレータが手作業で登録装置を車載ネットワークに接続させることができる。そのため、登録装置の処理能力を高めても、車載ネットワーク自体のコストは増加しないので、登録装置と構成管理装置の間では強固な認証方式を用いることができる。これにより、車載ネットワーク全体としてのコストを抑えつつセキュリティを向上させることができる。
【図面の簡単な説明】
【0017】
【図1】実施形態1に係る車載ネットワークシステム1000の構成図である。
【図2】構成管理サーバ103がネットワーク登録装置102を認証するシーケンスを説明する図である。
【図3】特許文献1に記載されている車載ネットワークの構成例を示す図である。
【図4】実施形態2に係る車載ネットワークシステム1000の構成例を示す図である。
【図5】構成管理サーバ103と目標ECU101の間で構成証明情報(共通鍵)を共有する形態を示す図である。
【図6】構成管理サーバ103が構成証明用鍵(共通鍵)を生成する方法を示す図である。
【図7】構成管理サーバ103が目標ECU101を認証する手順を説明するシーケンス図である。
【図8】構成管理サーバ103が目標ECU101を認証する手順を示す別方式のシーケンス図である。
【図9】構成管理サーバ103の内部で実行される処理を示すフローチャートである。
【図10】目標ECU101の内部で実行される処理を示すフローチャートである。
【図11】実施形態1〜3で説明した構成証明手法を、構成証明以外の用途に応用した動作例を説明する図である。
【図12】近年の代表的な高機能車両が備えている車載ネットワークのネットワークトポロジー例を示す図である。
【発明を実施するための形態】
【0018】
<実施の形態1>
図1は、本発明の実施形態1に係る車載ネットワークシステム1000の構成図である。車載ネットワークシステム1000は、車両の動作を制御するECUを接続する車内ネットワークである。ここでは、構成証明の対象である目標ECU101を1台のみ例示したが、車載ネットワークシステム1000に接続することができるECUは、これに限られるものではない。
【0019】
車載ネットワークシステム1000には、目標ECU101と構成管理サーバ103が車載ネットワークを介して接続されている。また、目標ECU101を車載ネットワークに参加させるため、必要に応じてネットワーク登録装置102が車載ネットワークシステム1000に接続される。
【0020】
構成管理サーバ103は、車載ネットワークを介して目標ECU101およびネットワーク登録装置102と通信することのできる装置である。構成管理サーバ103は、ECUの1種として構成してもよいし、その他任意の通信装置として構成してもよい。構成管理サーバ103は、目標ECU101とネットワーク登録装置102を認証する。目標ECU101を認証する目的は、目標ECU101が車載ネットワークに参加する正当権限を有しているか否かを確認することである。ネットワーク登録装置102を認証する目的は、ネットワーク登録装置102が目標ECU101を車載ネットワークに参加させる正当権限を有しているか否かを確認することである。
【0021】
ネットワーク登録装置102は、目標ECU101を車載ネットワークに参加させる装置である。車載ネットワークに参加させるとは、目標ECU101が車載ネットワークを介して他のECUと通信するために必要な構成証明データを目標ECU101に配信することである。ネットワーク登録装置102が目標ECU101を車載ネットワークに参加させるためには、あらかじめ構成管理サーバ103による認証を受ける必要がある。
【0022】
ネットワーク登録装置102は、必ずしも車載ネットワークに常時接続されている必要はない。例えば、車両の製造工程において車載ネットワークシステム1000を構築する際に、目標ECU101を車載ネットワークに参加させる作業を実施するときのみ、ネットワーク登録装置102を手作業で車載ネットワークに接続することができる。
【0023】
以下、図1にしたがって、ネットワーク登録装置102が目標ECU101を車載ネットワークに参加させる手順を説明する。
【0024】
(図1:ステップS111:認証要求)
オペレータは、ネットワーク登録装置102を操作して、目標ECU101を車載ネットワークに参加させる作業(登録処理)を開始する。ネットワーク登録装置102は、登録処理を開始すると、構成管理サーバ103に対し、自己を認証するように車載ネットワークを介して要求する。
【0025】
(図1:ステップS111:認証要求:補足)
ネットワーク登録装置102は、構成管理サーバ103に認証要求を出すと同時に、車載ネットワークに参加させる目標ECU101の識別情報(詳細は後述の図5で説明)を構成管理サーバ103に通知する。この識別情報としては、例えばECU−ID(部品番号)、ソフトウェアバージョンなどが挙げられる。これらの識別情報は、オペレータがネットワーク登録装置102上で手動入力するなどして与えることができる。
【0026】
(図1:ステップS112:構成証明鍵の配布)
構成管理サーバ103は、ネットワーク登録装置102から認証要求を受け取ると、所定の認証アルゴリズム(詳細は後述の図2で説明)にしたがってネットワーク登録装置102を認証する。構成管理サーバ103は、ネットワーク登録装置102の真正性を確認した場合は、認証要求時にネットワーク登録装置102から受け取った情報を用いて内部のデータベース(詳細は後述の図5で説明)を更新し、目標ECU101固有の構成証明用鍵(共通鍵)(詳細は後述の図6で説明)を生成して、ネットワーク登録装置102に配信する。
【0027】
(図1:ステップS113:鍵格納指令)
ネットワーク登録装置102は、目標ECU101に対して、構成管理サーバ103から配信された目標ECU101固有の構成証明用鍵(共通鍵)を中継し、目標ECU101にこれを格納するよう指示する。
【0028】
(図1:ステップS114:格納完了通知)
目標ECU101は、ステップS113で受け取った目標ECU101固有の構成証明用鍵(共通鍵)を自局のメモリに格納し、車載ネットワークに正常に参加した旨をネットワーク登録装置102に通知する。
【0029】
(図1:ステップS115:構成証明要求)
構成管理サーバ103は、ステップS112でネットワーク登録装置102を経由して配布しておいた構成証明用鍵(共通鍵)が目標ECU101内に保持されている、との推定に基づいて、目標ECU101に対して自局の真正性を証明するよう要求する。
【0030】
(図1:ステップS116:構成証明回答)
目標ECU101は、構成管理サーバ103に対して構成証明用鍵(共通鍵)の共有知識に基づいた回答を返信し、自局の真正性を証明する。
【0031】
(図1:ステップS116:構成証明回答:補足)
ステップS115〜S116における構成証明要求と回答は、構成管理サーバ103と目標ECU101の間で相互になされるべきものである。したがって、図1に図示するステップS115とステップS116の矢印方向とは逆に、目標ECU101が構成管理サーバ103に対して構成証明を要求し、構成管理サーバ103が回答してもよい。また、上記双方向のやり取りを合成して、目標ECU101が構成管理サーバ103に対して構成証明を開示する前に、構成管理サーバ103の構成証明を要求し、目標ECU101が構成管理サーバ103の真正性を確認しておいてから構成管理サーバ103に対して回答するように、相互的なハンドシェイクの形態を取ってもよい。
【0032】
<実施の形態1:ネットワーク登録装置の認証>
図2は、構成管理サーバ103がネットワーク登録装置102を認証するシーケンスを説明する図である。図2の認証シーケンスは、図1のステップS111の詳細を示すものである。ここでは、公開鍵暗号方式に基づくデジタル署名を用いてネットワーク登録装置102を認証する手法を例示するが、チャレンジ&レスポンス認証など別の認証方式を用いることもできる。なお、あらかじめネットワーク登録装置102の公開鍵と秘密鍵のペアを生成し、公開鍵を構成管理サーバ103に配信しておくものとする。以下、図2の各ステップについて説明する。
【0033】
(図2:ステップS201)
ネットワーク登録装置102は、例えば車載ネットワークに最初に接続した時点など、目標ECU101をネットワーク登録する動作に先立って、構成管理サーバ103に対し自己が正規端末であることを認証するように要求する。このとき、ネットワーク登録装置102の識別コード(またはそれに類する情報)を併せて送信し、自身を固有に識別する情報を構成管理サーバ103に対して明らかにする。
【0034】
(図2:ステップS201:補足)
本ステップでいう正規端末とは、ネットワーク登録装置102が当該車両のメーカによって認定された正規のものであること、改竄されたものでないこと、別の装置が正規のネットワーク登録端末102になりすましたものでないこと、などを保証された端末のことである。すなわち、目標ECU101を車載ネットワークに参加させる正当権限を有する端末である。
【0035】
(図2:ステップS202〜S203)
構成管理サーバ103は、認証開始処理を実行する(S202)。具体的には、疑似乱数を用いて種コードを生成し、ネットワーク登録装置102に返送する(S203)。また、ステップS201でネットワーク登録装置102から受け取った識別コードを用いて、ネットワーク登録装置102に対応する公開鍵を特定しておく。
【0036】
(図2:ステップS204〜S205)
ネットワーク登録装置102は、ステップS203で認証サーバから受け取った種コードを自身の秘密鍵で署名し(S204)、署名済みコードとして構成管理サーバ103に返送する(S205)。
【0037】
(図2:ステップS206)
構成管理サーバ103は、ステップS202で特定しておいた公開鍵を読み出し、これを用いてステップS205でネットワーク登録装置102から受け取った署名済みコードを復号する。構成管理サーバ103は、その復号結果とステップS203でネットワーク登録装置102に送信した種コードを比較し、両者が一致すればネットワーク登録装置102が正規端末であると判断する。両者が一致しなければ、ネットワーク登録装置102は認証許可されなかったことになる。
【0038】
(図2:ステップS207〜S208)
構成管理サーバ103は、認証シーケンスが終了した旨を、確認応答としてネットワーク登録装置102に対して送信する(S207)。その後、ネットワーク登録装置102は、これから車載ネットワークに参加させる予定の目標ECU101の{ECU−ID,ソフトウェアバージョン}を構成管理サーバ103に通知する(S208)。
【0039】
<実施の形態1:まとめ>
以上のように、本実施形態1に係る車載ネットワークシステム1000において、構成管理サーバ103は、厳密に真正性を検証することができるネットワーク登録装置102を経由して、目標ECU101に構成証明用鍵(共通鍵)を配布する。これにより、目標ECU101は、多大な計算資源を消費するKPS方式のように高度な計算を実施することなく、簡便に構成証明用鍵(共通鍵)を共有することができるので、ECUコストを抑えつつ車載ネットワークのセキュリティを向上させることができる。
【0040】
また、本実施形態1に係る車載ネットワークシステム1000において、ネットワーク登録装置102は必ずしも車載ネットワークシステム1000に常時接続する必要はないので、車載ネットワークシステム1000から独立した高性能な装置を用いてネットワーク登録装置102を構成することができる。これにより、車載ネットワークシステム1000を構成するECUのコストを抑えつつ、構成管理サーバ103とネットワーク登録装置102の間で強固な認証処理を実施することができる。この認証処理には、構成管理サーバ103と目標ECU101の間の認証処理よりも強固な手法を用いることができる。すなわち、ネットワーク登録装置102の性能を目標ECU101よりも高くすることができるので、多大なリソースを消費する強固な認証処理を実施することができる。
【0041】
また、本実施形態1に係る車載ネットワークシステム1000において、目標ECU101およびネットワーク登録装置102を認証する構成管理サーバ103は、車載ネットワーク内部に配置されている。これにより、各装置は認証処理を実施するために車外と通信する必要がなくなり、セキュリティを向上させることができる。また、認証処理を実施するためのリソースを構成管理サーバ103に集約させることにより、他のECUのコストを抑えることができる。
【0042】
<実施の形態2>
本発明の実施形態2では、実施形態1で説明した車載ネットワークシステム1000の具体的な構成例について説明する。
【0043】
以下、本実施形態2に係る車載ネットワークシステム1000(図4)と、特許文献1に記載されている従来例(図3)とを比較し、両者の構成とセキュリティに関する違いを説明する。
【0044】
<実施の形態2:従来例の説明>
図3は、特許文献1に記載されている車載ネットワークの構成例を示す図であり、本実施形態2と対比するために記載したものである。図3において、車載ネットワーク202の中にECUマスタ105が存在しており、これが車両ごとの識別番号{車両ID}を保持している。
【0045】
ECUマスタ105は、初期化処理を実施するとき、車載ネットワーク202の外部に設置されているセンターサーバ203に対して、{車両ID,ECU−ID,ソフトウェアバージョン}の情報をセットにして、{共通鍵生成源}を配信するよう要求する(ステップS311)。ECU−IDはECUマスタ105の識別子であり、ソフトウェアバージョンはECUマスタ105が搭載しているソフトウェアのバージョンである。
【0046】
センターサーバ203は、その要求に応じて{共通鍵生成源}を配布する(ステップS312)。これらのやり取りは、ECUマスタ105内部に固定的に設定された初期化鍵によって暗号化されている(外部通信F221)。
【0047】
センターサーバ203より配布される{共通鍵生成源}は、車載ネットワーク202に属するECU間の通信のみに使われる「共通鍵を導出する情報源」である。{共通鍵生成源}は、センターサーバ203と通信する際には用いられない。
【0048】
ECUマスタ105以外の車載ネットワークに属する目標ECU101は、ECUマスタ105より{車両ID}を入手する。この時点では、目標ECU101は{共通鍵生成源}を入手していないので、目標ECU101は暗号化を実施せずにECUマスタ105と通信する(ステップS313)。
【0049】
目標ECU101は、ECUマスタ105より受け取った{車両ID}を用いて、{車両ID,ECU−ID,ソフトウェアバージョン}のセットを組み立て、センターサーバ203に対して、{共通鍵生成源}を配信するよう要求する(ステップS314)。ECU−IDは目標ECU101の識別子であり、ソフトウェアバージョンは目標ECU101が搭載しているソフトウェアのバージョンである。
【0050】
センターサーバ203は、その要求に応じて{共通鍵生成源}を配布する(ステップS315)。これらのやり取りは、目標ECU101内部に固定的に設定された初期化鍵によって暗号化されている(外部通信F222)。
【0051】
以上の構成より、特許文献1における方式には次のような脆弱性が存在することが明らかとなる。
(脆弱性1)車載ネットワーク202に属する全てのECUは、初期化処理を実施するとき、車載ネットワーク202の外部に配置されているセンターサーバ203と接続して{共通鍵生成源}の配布を受ける。そのため、初期化処理中にセンターサーバ203との間の接続が断たれた場合は、有効な車載ネットワークを構成することができない。
(脆弱性2)センターサーバ203は、全ての車両の{車両ID,ECU−ID,ソフトウェアバージョン}と{共通鍵生成源}のセットを管理している。そのため、センターサーバ203が不正に侵入されると、全ての車両の鍵が流出する。また、故意・過失を問わずセンターサーバ203に障害が発生すると、全ての車両の鍵が紛失する危険を伴う。
(脆弱性3)初期化処理を実施するときの暗号化通信(外部通信F221および外部通信F222)が脆弱である。そのため、{共通鍵生成源}の配布をうける際に、ECUとセンターサーバ203との間の相互認証がセキュアではない。これは、部品として量産されるECUハードウェアの制約上、固定的でバリエーションの少ない暗号化鍵を使わざるを得ない特性に起因する。したがって、この暗号化鍵が破られると、センターサーバ203については特定車両の鍵情報が流出するおそれがあり、車載ECUについては悪意の第3者が偽りの鍵情報を配布することにより車載ネットワークへの妨害などが発生し得る。
(脆弱性4)初期化処理を実施するときのECUマスタ105から目標ECU101の間の{車両ID}の流れ(ステップS313)は暗号化されていないので、車載ネットワーク202の外部から容易にキャプチャすることができる。これは、{車両ID,ECU−ID,ソフトウェアバージョン}のセット(ステップS311およびステップS314で使用)を悪意の第3者が類推する糸口になる。
【0052】
<実施の形態2:本発明の説明>
図4は、本実施形態2に係る車載ネットワークシステム1000の構成例を示す図である。車載ネットワーク202に、構成管理サーバ103が設置されている。この車載ネットワーク202に新たな目標ECU101を参加させる手順を詳述する。
【0053】
オペレータは、ネットワーク登録装置102を接続用車両コネクタ104に接続し、構成管理サーバ103と通信して認証を受ける。このときオペレータは、これから車載ネットワーク202に参加させようとしている目標ECU101のECUI−IDなどをネットワーク登録装置102上で入力し、構成管理サーバ103に送信する。この手順は、図1のステップS111に相当する。
【0054】
構成管理サーバ103は、ネットワーク登録装置102の真正性を厳密に審査・検証する。構成管理サーバ103は、ネットワーク登録装置102が正規のものであることを確認した場合は、目標ECU101固有の{共通鍵}を発行する(ステップS112)。
【0055】
ネットワーク登録装置102は、この{共通鍵}を目標ECU101に中継して格納させる(ステップS113)。以上の手順により、構成管理サーバ103と目標ECU101の間で{共通鍵}が安全に共有される。
【0056】
以上説明した本発明のメカニズムにより、先に説明した従来例における脆弱性は、以下に示すように改善される。先に説明した脆弱性に対応する改善点を、脆弱性と同じ順番で説明する。
(改善点1)各ECUが実施する通信は、車載ネットワーク202内部でクローズしており、車両外部との間の通信は実施されない。したがって、車載ネットワーク202に対して不正侵入を受ける機会も、情報漏洩を発生させる機会も少ない。
(改善点2)車載ネットワーク202内の鍵情報は、車両ごとに内蔵されている構成管理サーバ103が管理する。したがって、センターサーバ203に全車両の情報を集約させることによる脆弱性は存在しない。また、{共通鍵}は車両ごとに独立してユニークであり、これが流出しても他車両に対するセキュリティ上の懸案事項は発生しない。
(改善点3)初期化処理を実施するときの{共通鍵}の発行および中継は、厳密に相互認証を実施した構成管理サーバ103とネットワーク登録装置102の間で実施される。したがって、悪意の第3者による妨害などのセキュリティリスクは少ない。
(改善点4)車載ネットワーク202のメンバを構成するECUの識別情報、例えば{車両ID,ECU−ID,ソフトウェアバージョン}は、構成管理サーバ103の内部のみで管理されている。そのため、車載ネットワーク202を介して他ECUにこれら識別情報を開示する必要がない。したがって、これら情報の漏洩リスクに対して頑健である。
【0057】
<実施の形態2:共通鍵の共有形態>
ネットワーク登録装置102は、目標ECU101上の不揮発性メモリ(EEPROM:Electronically Erasable and Programmable Read−Only Memory)に上記共通鍵情報を記憶させる機能のみを有する簡易装置として構成してもよいし、制御ソフトウェアを記憶するフラッシュROMに上記共通鍵情報を直接書き込むプログラム書換装置として構成してもよい。
【0058】
車両が市場に出た後に制御プログラムの不具合が発覚した場合、ディーラーは車両を回収して該当車載ECUのプログラムを書き換える。このとき、このプログラム書換装置を用いて、目標ECUのソフトバージョンアップ、構成証明用鍵(共通鍵)の更新、構成管理サーバ103の登録情報(ECU−ID,ソフトウェアバージョンなど)の更新が同時に実施できるようにしておけば、作業者にとって便宜である。そのため、ネットワーク登録装置102はプログラム書換装置としての機能を兼ね備えていることが望ましいといえる。
【0059】
なお図4において、ネットワーク登録装置102は、車載ネットワーク202に直接接続するように図示されているが、無線通信などの有線以外の信号結合方式を用いて車外の通信網と接続し、ネットワーク登録装置102をその通信網の一要素として構成してもよい。この場合も、車内の構成管理サーバ103とネットワーク登録装置102との間の認証は厳密に実行される。
【0060】
図5は、構成管理サーバ103と目標ECU101の間で構成証明情報(共通鍵)を共有する形態(情報分布形態)を示す図である。ここでは目標ECU101が複数存在する例を示した。
【0061】
図5(a)は、構成管理サーバ103内のデータベース410が格納しているデータ例を示す。各車載ECUの識別情報(ECU−ID,ソフトウェアバージョンなど)がデータ412で示すように保持されている。データ411は、構成管理サーバ自体の認証鍵であり、車載ECU全てに等しく配布される。
【0062】
図5(b)〜(d)に示すデータベース420、430、440は、目標ECU101a〜101cのメモリ上にそれぞれ記憶されている構成証明用鍵(共通鍵)のデータ例を示す。各目標ECU101が保持している共通鍵は、構成管理サーバ103が発行し、ネットワーク登録装置102を経由して設定されたものである。
【0063】
すなわち、構成管理サーバ内データベース410のデータ412のうちECU−IDとソフトウェアバージョンを除いた情報が、各目標ECU101に転写される。この共通鍵は、各目標ECU101が構成管理サーバ103に対して自己の真正性を証明するために用いる鍵情報である。以降、この情報を「ECU鍵」と呼ぶ。
【0064】
また、構成管理サーバ内データベース410のデータ411のうちECU−IDとソフトウェアバージョンを除いた共通鍵情報も、各目標ECU101に転写される。この共通鍵は、構成管理サーバ103が目標ECU101に対して自己の真正性を証明するために用いる鍵情報である。以降、この情報を「サーバ鍵」と呼ぶ。
【0065】
上述したECU鍵とサーバ鍵に加えて、構成管理サーバ103と各目標ECU101とが通信する際に用いるチャンネル番号またはメッセージIDなどの通信識別情報413を各目標ECU101に配信することもできる。
【0066】
通信識別情報413は、通信データの種別を指定する情報である。例えば、構成管理サーバ103が目標ECU101aに共通鍵を送信するときはメッセージID0x15を用い、目標ECU101bに共通鍵を送信するときはメッセージID0x17を用いる、といった使い分けをすることができる。各目標ECU101は、受信したデータが何を記述しているのかを、メッセージIDの値によって識別することができる。
【0067】
各目標ECU101は、車載ネットワーク202に参加する前は、構成証明において用いられる通信チャンネルを把握していない。そこで、構成証明用鍵(共通鍵)を配布するとともに各目標ECU101にメッセージIDを配布することができる。メッセージIDは、各目標ECU101のデータベース内に、それぞれデータ421、431、441として格納される。
【0068】
通信データの種別毎にメッセージIDを変えることにより、通信の秘匿性がより一層高まる。すなわち、悪意の第3者はどのメッセージIDを用いて共通鍵が配信されているかを知らないため、通信データのなかから共通鍵を抽出することが困難である。
【0069】
上述の各情報の他、構成管理サーバ内データベース410が格納している、ECU−ID、ソフトウェアバージョンなどの属性情報を、各目標ECU101に配信することもできる。これら情報は、ネットワーク登録装置102や目標ECU101にとって有用な情報である。
【0070】
ネットワーク登録装置102は、車両のECUが現在どのようなECU群・ソフトウェア群で構成されているのかを調査したい場合がある。また、車載ECUは、協調制御の相手方となる他の車載ECUのソフトウェアバージョンが自局の制御ソフトと対応しているのかを調査したい場合がある。このような要求に答えるため、構成管理サーバ103は、データベース410が保持しているこれら情報を、ネットワーク登録装置102や目標ECU101に配信してもよい。
【0071】
ただしセキュリティの観点から、これら情報の開示は、ネットワーク登録装置102については前述の認証が厳密に実施された後、車載ECUについては当該ECUの構成証明が厳密に実施された後になされる。
【0072】
図5に示すデータベース410は、オペレータがネットワーク登録装置102を用いて内容を閲覧し、更新することができるように構成してもよい。閲覧または更新に先立って構成管理サーバ103がネットワーク登録装置102を認証するのは、構成証明の場合と同様である。
【0073】
<実施の形態2:共通鍵の生成手段>
図6は、構成管理サーバ103が構成証明用鍵(共通鍵)を生成する方法を示す図である。以下図6にしたがって、構成証明用鍵を生成する手順を説明する。
【0074】
車両識別番号501は、車両個々にユニークに付けられる番号であり、構成管理サーバ103が内部的に情報を保持している。ECU−ID(部品番号)502とソフトウェアバージョン503は、車載ネットワーク202に参加させようとしている目標ECU101のECU−ID(部品番号)とソフトウェアバージョンである。乱数504は、構成管理サーバ103内部で適宜発生させた乱数である。例えば、半導体閾値のホワイトノイズ的な揺らぎで一様乱数を生成するデバイスを用いて生成することができる。簡易的には、例えばマイコンのフリーランカウンタなどを適当なタイミングでキャプチャした数値列を乱数504として採用してもよい。
【0075】
構成管理サーバ103は、これらの値を一方向性ハッシュ関数505に入力する。一方向性ハッシュ関数505は、固定長のECU固有の共通鍵506を出力する。この共通鍵506またはこれを用いて算出した値を、構成証明用鍵として用いることができる。
【0076】
一方向性ハッシュ関数505は、ECU固有の共通鍵506から、車両識別番号501、ECU−ID(部品番号)502、ソフトウェアバージョン503などの情報を復元することが不可能となるようにするために用いる。また、入力値が少しでも変わると共通鍵506も変化し、生成値が衝突しにくく、同一の出力値を与える入力値の組み合わせが予見不可能であることも重要である。
【0077】
一方向性ハッシュ関数505の入力値として、車両識別番号501を用いているので、同じECU−ID(部品番号)502の目標ECU101をネットワーク登録しても、車両ごとに共通鍵506の値は異なる。また、一方向性ハッシュ関数505の入力値として乱数504を用いているので、同一車両の車載ネットワーク202に、同一のECU−ID(部品番号)502および同一のソフトウェアバージョン503の車載ECUを参加させても、参加を実施する毎に共通鍵506の値は異なる。
【0078】
この仕組みにより、ECU改竄やECU不正入れ換えを検出する能力を向上させることができる。同様の効果を発揮することができれば、一方向性ハッシュ関数505以外の関数を用いてもよいが、共通鍵506に基づき元の値を推測することができないようにする観点からは、一方向性関数を採用することが望ましい。
【0079】
<実施の形態2:構成証明の手順>
図7は、構成管理サーバ103が目標ECU101を認証する手順を説明するシーケンス図である。ここでは上述のサーバ鍵とECU鍵をパスワードとして用いる例を示した。以下、図7の各ステップについて説明する。
【0080】
(図7:ステップS701〜S702:構成証明の開始)
構成管理サーバ103は、目標ECU101に対して、構成証明要求を送信する(S701)。この構成証明要求は、車両が特定の状態時(始動直後、アイドリング時、イグニッションオフ直後など)に実施してもよいし、定期的に実施してもよい。目標ECU101は、証明を要求しているのが本当に正規の構成管理サーバ103であるかを確かめるため、サーバ認証要求を返信する(S702)。
【0081】
(図7:ステップS701〜S702:補足)
前述の構成証明用鍵(共通鍵)とともに通信識別情報413を配布する場合は、図7に示す通信シーケンスは、各ECUが記憶している通信チャンネルまたはメッセージIDを用いて実施される。
【0082】
(図7:ステップS703〜S704:サーバ側認証)
構成管理サーバ103は、自分の真正性を目標ECU101に示すため、サーバ鍵をサーバ側パスワードとして開示する(S703)。このサーバ鍵と、目標ECU101が内部に保持しているサーバ鍵とが一致した場合、構成管理サーバ103が真正であると結論付けられる(S704)。
【0083】
(図7:ステップS705〜S707:ECU側構成証明)
構成管理サーバ103が真正である旨を目標ECU101が確認した場合、目標ECU101は、ECU鍵をECU側パスワードとして構成管理サーバ103に送信する(S705)。構成管理サーバ103は、データベース410が保持している鍵と受信したECU鍵が一致した場合、目標ECU101は改竄されていないと判断する(S706)。以上の手順によって構成証明が完了し、構成管理サーバ103はセッション終了通知を目標ECU101に送信する(S707)。
【0084】
<実施の形態2:構成証明の手順その2>
図7で説明した手順によれば、サーバ認証とECU構成証明を簡便に実行することができる。ただし、サーバ鍵とECU鍵が直接車載ネットワーク202上に流れるので、これをキャプチャすれば、改竄された目標ECU101(もしくは構成管理サーバ103)を作成して車載ネットワーク202に接続することができる。
【0085】
このような状況を防止し、セキュリティ性能を向上させるため、構成証明用鍵(共通鍵)を直接車載ネットワーク202に流すことに代えて、チャレンジ&レスポンス認証の共通鍵として構成証明用鍵を用いることもできる。図8を用いてその手順を説明する。
【0086】
図8は、構成管理サーバ103が目標ECU101を認証する手順を示す別方式のシーケンス図である。以下、図8の各ステップについて説明する。
【0087】
(図8:ステップS801:構成証明要求)
構成管理サーバ103は、目標ECU101に対して、構成証明要求を送信する(S801)。この構成証明要求は、車両が特定の状態時(始動直後、アイドリング時、イグニッションオフ直後など)に実施してもよいし、定期的に実施してもよい。目標ECU101は、証明を要求しているのが本当に正規の構成管理サーバ103であるかを確かめる認証処理を開始する。
【0088】
(図8:ステップS802〜S803)
目標ECU101は、乱数を発生させ(S802)、サーバ認証用のチャレンジデータとして構成管理サーバ103に送信する(S803)。
【0089】
(図8:ステップS804〜S805)
構成管理サーバ103は、ステップS803のサーバ認証用チャレンジを受け取り、このデータとサーバ鍵を入力として、一方向性ハッシュ関数を用いてレスポンスを計算する(S804)。構成管理サーバ103は、算出したレスポンスをサーバ側レスポンスとして目標ECU101に送信する(S805)。
【0090】
(図8:ステップS806)
目標ECU101は、ステップS802で生成した乱数と、構成管理サーバ103との間で共有しているサーバ鍵とを一方向性ハッシュ関数に入力し、レスポンスとして構成管理サーバ103から帰ってくるであろうと予測される期待値を計算する。構成管理サーバ103と目標ECU101は、規約によりそれぞれ同じアルゴリズムの一方向性ハッシュ関数を採用していると推定されるので、同じデータを入力とする一方向性ハッシュ関数の出力値は一致するはずである。
【0091】
(図8:ステップS807〜S808)
目標ECU101は、ステップS806で計算した値と、構成管理サーバ103から受け取った値とを比較する(S807)。両者の値が一致すれば、構成管理サーバ103の真正性が証明されたことになるので、目標ECU101は構成証明用チャレンジ要求を構成管理サーバに送信する(S808)。
【0092】
(図8:ステップS809〜S810)
構成管理サーバ103は、ステップS808で目標ECU101が送信した構成証明用チャレンジ要求を受信すると、乱数を発生させ(S809)、目標ECU101に対して構成証明用チャレンジデータとして送信する(S810)。乱数発生の手段は、目標ECU101と同様である。
【0093】
(図8:ステップS811〜S813)
構成管理サーバ103は、ステップS810で送信したチャレンジデータとECU鍵を用いて、ステップS806と同様の手順でレスポンスの期待値を計算しておく(S811)。目標ECU101は、ステップS810で構成管理サーバ103が送信したチャレンジデータとECU鍵を用いて、ステップS804と同様の手順でレスポンスを計算し(S812)、構成管理サーバ103に返信する(S813)。
【0094】
(図8:ステップS814〜S815)
構成管理サーバ103は、ステップS813で目標ECU101から返信された構成証明用レスポンスとステップS811で計算した期待値を比較する。両者が一致すれば、目標ECU101の構成証明が得られたことになる(S814)。その後、構成管理サーバ103は、目標ECU101に対してセッション終了通知を送信する(S815)。
【0095】
<実施の形態2:まとめ>
以上のように、本実施形態2に係る車載ネットワークシステム1000において、構成管理サーバ103は、車載ネットワークに202に接続される全ての車載ECUの識別情報(ECU−ID(部品番号)、ソフトウェアバージョン等)を管理する。この管理形態は、全車両の情報を集約する外部サーバなどを用いず、各車両が自己の識別情報を個別に保持する分散制御として構成される。したがって、情報管理形態としてロバストであり、個別車両の構成管理サーバ103が破られても、セキュリティ危機が全車両に波及することがない。
【0096】
また、本実施形態2に係る車載ネットワークシステム1000において、目標ECU101を車載ネットワーク202に参加させる際に、信頼できるネットワーク登録装置102の力を借りて、安全に構成証明用鍵(共通鍵)を配信することができる。これにより、上述のように簡単なチャレンジ&レスポンス認証で、構成管理サーバ103と目標ECU101が互いに相手方を認証し、構成の真正性を互いに証明し合うことができる。
【0097】
また、本実施形態2に係る車載ネットワークシステム1000においては、構成証明を実施する際に、高度な暗号化通信(一般の共通鍵暗号や公開鍵暗号)や共通鍵配信技術(KPS方式など)を使う必要がない。すなわち、現状のECUにおけるCPU/ROM/RAM等の計算リソースを構成証明のために浪費する必要がなくなり、ひいては実装コストが増加しない。したがって本手法は、構成証明機能を車載ネットワークシステム1000に簡便に付加し、ECUの改竄に対抗する手法として、非常にコストパフォーマンスに優れた方式であると言える。
【0098】
<実施の形態3>
本発明の実施形態3では、実施形態2で開示した車載ネットワークシステム1000の具体的なソフトウェア実装例について説明する。図9と図10は、図8で示したチャレンジ&レスポンス方式の構成証明手順を、ソフトウェア実装の観点でフローチャートとして開示したものである。したがって、機能として図8のシーケンスとは完全に等価というわけではなく、異常系処理と診断NG時の警告系処理を含んでいる。
【0099】
図9は、構成管理サーバ103の内部で実行される処理を示すフローチャートである。以下、図9の各ステップについて説明する。
【0100】
(図9:ステップS901〜S905:構成証明開始)
構成管理サーバ103は、データベース410より、検証すべき目標ECU101の共通鍵を読み出し、構成証明に備える(S901)。その後、該当する目標ECU101に対して構成証明要求を送信し(S902)、タイムアウト計測に備えてタイマを初期化する(S903)。構成管理サーバ103は、サーバ認証用チャレンジデータの到来を待ち受け(S904)、データが到来すればステップS906に遷移する。サーバ認証用チャレンジデータが到来せずタイムアウトと判定された場合は(S905)、目標ECU101が反応していないと判断し、ステップS917に遷移する。
【0101】
(図9:ステップS906〜S910:サーバ側認証)
構成管理サーバ103は、サーバ認証用チャレンジデータを受信すると、サーバ鍵を用いてレスポンスを計算し(S906)、目標ECU101にレスポンスを返信する(S907)。その後、ECU側の判定を待ち受けるためのタイムアウト計測に備えてタイマを初期化する(S908)。構成管理サーバ103は、目標ECU101から構成証明用チャレンジ要求を待ち受け(S909)、要求を受信すると、目標ECU101がサーバ認証を受け入れたということなので、ステップS911に遷移する。構成証明用チャレンジ要求が到来せずタイムアウトと判定された場合は(S910)、目標ECU101がサーバ認証を受け入れなかったか、または目標ECU101が改竄され手続きを知らない可能性があると判断し、ステップS917に遷移する。
【0102】
(図9:ステップS911〜S916:ECU側証明要求)
ステップS911〜S916は、目標ECU101の構成証明を実施するためのデータを準備するステップである。構成管理サーバ103は、乱数を発生させ(S911)、構成証明用チャレンジデータとして目標ECU101に送信する(S912)。その後、タイムアウト計測用タイマを初期化し(S913)、ステップS901で検索済みの目標ECU101のECU鍵を用いて、レスポンスの期待値を計算する(S914)。構成管理サーバ103は、目標ECU101から構成証明用レスポンスを待ち受け(S915)、レスポンスがあった場合はステップS918に遷移する。構成証明用レスポンスが到来せずタイムアウトと判定された場合は(S916)、目標ECU101が改竄され手続きを知らない可能性があると判断し、ステップS917に遷移する。
【0103】
(図9:ステップS917:ECU不正検出&警告処理)
構成管理サーバ103は、適当なインターフェースを介して、目標ECU101が改竄されている旨の警告信号を出力するか、またはその旨を記述した通信データを車載ネットワーク202に対してブロードキャストする。
【0104】
(図9:ステップS918〜S920:構成証明結果)
構成管理サーバ103は、ステップS914で計算した期待値と、目標ECU101から受信した構成証明用レスポンスとを比較する(S918)。両者が一致すれば構成証明が完了したということなので、目標ECU101にセッション終了通知を送信し(S919)、構成証明が終了したことを通知する。その後、全ての検査すべき車載ECUについて構成証明が完了したか否かをチェックする(S920)。完了している場合は図9の処理を終了し、未完である場合はステップS901に戻る。期待値と構成証明用レスポンスとが一致しなかった場合は、目標ECU101が他の車両のものと取り換えられたり、車載ネットワーク202に参加する処理を実行しないまま車載ネットワーク202に接続されたりするなど、不正な改竄が行われた可能性があると判断し、ステップS917に遷移する。
【0105】
図10は、目標ECU101の内部で実行される処理を示すフローチャートである。以下、図10の各ステップについて説明する。
【0106】
(図10:ステップS1001〜S1007:サーバ側認証開始)
目標ECU101は、構成管理サーバ103からの構成証明要求を待ち受け、要求が到着するとステップS1002に遷移する(S1001)。目標ECU101は、構成管理サーバ103が改竄されていないか(悪意の盗聴装置ではないか)を確認するために乱数を発生し(S1002)、サーバ認証用チャレンジデータとして送信する(S1003)。目標ECU101は、タイムアウト計測用タイマを初期化し(S1004)、サーバ鍵を用いて構成管理サーバ103からのレスポンスの期待値を計算する(S1005)。目標ECU101は、構成管理サーバ103からのサーバ認証用レスポンスを待ち受け(S1006)、返信を受け取るとステップS1008に遷移する。サーバ認証用レスポンスが到来せずタイムアウトと判定された場合は(S1007)、構成管理サーバ103が改竄されるか、または悪意の盗聴装置と交換されている可能性があると判断し、ステップS1018に遷移する。
【0107】
(図10:ステップS1008〜S1012:ECU側構成証明開始)
目標ECU101は、ステップS1005で計算した期待値と、構成管理サーバ103から受信したサーバ認証用レスポンスとを比較する(S1008)。両者が一致すれば、構成管理サーバ103の真正性が確認されたということなので、ステップS1009に遷移する。期待値とサーバ認証用レスポンスとが一致しなかった場合は、構成管理サーバ103が他の車両のものと取り換えられるか、または不正な改竄が行われた可能性があると判断し、ステップS1018に遷移する。目標ECU101は、構成管理サーバ103に対して、自局の真正性を証明するための構成証明用チャレンジデータを送信するよう要求する(S1009)。その後、構成管理サーバ103から構成証明用チャレンジデータを待ち受けるためのタイムアウト計測に備えてタイマを初期化する(S1010)。目標ECU101は、構成管理サーバ103から構成証明用チャレンジデータを待ち受け、返信を受け取るとステップS1013に遷移する。構成証明用チャレンジデータが到来せずタイムアウトと判定された場合は(S1012)、構成管理サーバ103が改竄され手続きを知らない可能性があると判断し、ステップS1018に遷移する。
【0108】
(図10:ステップS1013〜S1017:構成証明結果)
目標ECU101は、構成管理サーバ103から受信した構成証明用チャレンジデータとECU鍵を用いてレスポンスを計算し(S1013)、構成管理サーバに返信する(S1014)。また、構成管理サーバ103からの応答を監視するためのタイムアウト計測に備えてタイマを初期化する(S1015)。目標ECU101は、構成管理サーバ103からセッション終了通知を待ち受け、返信を受け取ると、構成管理サーバ103が構成証明を完了したことを意味しているので、図10の処理を終了する(S1016)。構成証明用チャレンジデータが到来せずタイムアウトと判定された場合は(S1017)、構成管理サーバ103が他の車両のものと取り換えられるか、または不正な改竄が行われた可能性があると判断し、ステップS1018に遷移する。
【0109】
(図10:ステップS1018:構成管理サーバ不正検出&警告処理)
目標ECU101は、適当なインターフェースを介して、構成管理サーバ103が改竄されている旨の警告信号を出力するか、またはその旨を記述した通信データを車載ネットワーク202に対してブロードキャストする。
【0110】
<実施の形態3:まとめ>
以上のように、本実施形態3に係る車載ネットワークシステム1000において、構成証明は、構成管理サーバ103と目標ECU101の間の相互認証によって実施される。これにより、構成管理サーバ103または目標ECU101が改竄されたことを検知し、その旨の警告を発信することができる。
【0111】
<実施の形態4>
図11は、実施形態1〜3で説明した構成証明手法を、構成証明以外の用途に応用した動作例を説明する図である。図11では、ECU101が2台存在し(ECU101aと101b)、これらECUの間でデジタル署名付きのメッセージを送受信する動作を想定する。
【0112】
ECU鍵は、構成管理サーバ103と特定の車載ECUのペア間のみで共有される情報であるが、サーバ鍵は複数の車載ECUが共有する情報である。したがって、サーバ鍵を用いて複数の車載ECU間でメッセージ認証符号(MAC:Message Authentication Code)を送受信し、メッセージの真正性を保証することが考えられる。
【0113】
サーバ鍵は、目標ECU101が車載ネットワーク202に参加するときに、構成管理サーバ103から安全に配布されたものであり、車載ネットワーク202に属する正規ECU以外には流出しない。よって、このサーバ鍵を用いてデジタル署名(メッセージ認証符号を添付すること)を実施すれば、構成管理サーバ103により認証を受けた車載ECUからのメッセージであることを、他ECUが確認することができる。
【0114】
ECU101aは、送りたいメッセージ1011aとサーバ鍵1012aを一方向性ハッシュ関数1013aに入力してメッセージ認証符号(MAC)1014aを生成する。メッセージ1011aとメッセージ認証符号(MAC)1014aをパッキング(S1101)して送信バッファ1015aに格納し、車載ネットワーク202に送り出す(S1102)。
【0115】
ECU101bは、ECU101aが送信した信号を受信(S1103)して受信バッファ1016bに格納し、送信側と申し合わせた規約によりアンパック(S1104)して、メッセージ1011bとメッセージ認証符号(MAC)1014bとに分離する。
【0116】
ECU101bは、メッセージ1011bとサーバ鍵1012b(サーバ鍵1012aと等しいと推定される)を一方向性ハッシュ関数1013bに入力して受信側メッセージ認証符号(MAC)を作成し(S1105)、MAC1014bと受信側メッセージ認証符号(MAC)を比較器1017bにより比較する。両者が一致する旨の判定結果1018bが得られれば、メッセージ1011bの内容が確かにECU101aによって作成されたものであり、途中で改竄されていないと判断できる。
【0117】
なお、一方向性ハッシュ関数1013aと1013bは、ECU間の規約にしたがって同一のアルゴリズムを採用するものとする。
【0118】
図11では、ネットワーク登録装置102により正規に車載ネットワーク202へ参加したECUが共通して保持するサーバ鍵を用いてメッセージ認証符号(MAC)を実現する実施例を開示したが、この用途はメッセージ認証符号に限られるものではなく、共通鍵暗号方式(例えば、DES方式、AES(Advanced Encryption Standard)方式など)による車載ECU間の暗号化通信に応用してもよい。
【0119】
<実施の形態4:まとめ>
以上のように、本発明による車載ECU間で共通鍵を共有する手法は、構成証明用途のみならず、任意の車載ECU間での高信頼度通信についても有効であることが分かる。
【0120】
<実施の形態5>
図12は、近年の代表的な高機能車両が備えている車載ネットワークのネットワークトポロジー例を示す図である。ネットワーク登録装置(ソフトウェア書換装置が兼任)102、構成管理サーバ103、各ECUなどの構成および動作は、実施形態1〜4と同様である。
【0121】
図12において、4群のネットワークが搭載されており、各々通信ゲートウェイ(ゲートウェイECU)201によってネットワークが束ねられている。図12では、ゲートウェイECU201を中心にしてスター型のネットワーク配置を採用しているが、ゲートウェイECU201を複数段設けてカスケード型の接続形態を採用してもよい。
【0122】
図12に示す車載ネットワークには、駆動系ネットワーク301、シャーシ/安全系ネットワーク305、ボディ/電装系ネットワーク309、AV/情報系ネットワーク313が搭載されている。
【0123】
駆動系ネットワーク301の配下には、エンジン制御ECU302、AT(Automatic Transmission)制御ECU303、HEV(Hybrid Electric Vehicle)制御ECU304が接続されている。シャーシ/安全系ネットワーク305の配下には、ブレーキ制御ECU306、シャーシ制御ECU307、ステアリング制御ECU308が接続されている。ボディ/電装系ネットワーク309の配下には、計器表示ECU310、エアコン制御ECU311、盗難防止制御ECU312が接続されている。AV/情報系ネットワーク313の配下には、ナビゲーションECU314、オーディオECU315、ETC/電話ECU316が接続されている。
【0124】
また、車両と外部との間で情報を送受信するため、車外通信部317が車外情報用ネットワーク322によってゲートウェイECU201に接続されている。車外通信部317には、ETC無線機318、VICS(Vehicle Information and Communication System)無線機319、TV/FM無線機320、電話用無線機321が接続されている。
【0125】
ネットワーク登録装置102は、車両が備えている接続用車両コネクタ104を介して、車外情報用ネットワーク322の1ノードとして接続するように構成されている。これに代えて、他のネットワーク(駆動系ネットワーク301、シャーシ/安全系ネットワーク305、ボディ/電装系ネットワーク309、AV/情報系ネットワーク313)またはゲートウェイECU201に単独で接続してもよい。すなわち、機械的な配置は無関係であって、直接もしくはゲートウェイECU201を介して目標ECUに対して電気信号が到達すればよい。
【0126】
電話用無線機321を通じてネットワーク越しに車外通信網からネットワーク登録装置102の機能を実施することもできる。例えば、構成管理サーバ103のデータベース検索や目標ECU101の構成証明用データのメンテナンスなどが考えられる。この場合においても、上述の実施形態1〜4と同様の手法を用いることができる。
【0127】
電話網越しやインターネット越しにECUのソフトウェアを書き換える手法は、リコールなどの不具合対応に際してその実施コストを下げる重要技術であって、将来的にありふれた行為になることが予想される。
【0128】
したがって、本発明で開示する技術を用いることによって、このソフトウェア書き換え後に引き続いて、リモートで構成管理サーバ103のデータベース内容を更新し、リモートでソフトウェア書き換え後の車載ECUを正しくネットワークに再登録することができる。
【0129】
図12では、構成管理サーバ103を通信ゲートウェイECU201の配下に直接接続したが、構成管理サーバ103のネットワーク上の位置は任意でよい。すなわち、電気信号的な接続が確保できるのであれば、他のネットワーク(駆動系ネットワーク301、シャーシ/安全系ネットワーク305、ボディ/電装系ネットワーク309、AV/情報系ネットワーク313、車外情報用ネットワーク322など)に直接接続してもよい。
【0130】
ただし、以下の2つの観点で通信ゲートウェイECU201が構成管理サーバ103の役割を兼ねることが望ましい。
(1)図1の認証シーケンスS111が失敗したとき、ネットワーク登録装置102からの通信を、目標ECU101が属する車載ネットワーク(駆動系ネットワーク301、シャーシ/安全系ネットワーク305、ボディ/電装系ネットワーク309、AV/情報系ネットワーク313)から電気的に切り離すことができる。この構成を用いることによって、いわゆるファイヤーウォール(防火壁)機能を通信ゲートウェイ201に付与することになるので、車載ネットワークに対する外部からの侵入リスクを低下させ、セキュリティをさらに向上させることができる。
(2)車両の不正改造・特定車載ECUの改竄などの目的で、構成管理サーバ103が車載ネットワークから除去される行為を防がなければならない。その目的では、通信ゲートウェイECU201と構成管理サーバ103が機能統合されており、1つのECUであることは望ましい。なぜなら、構成管理サーバ103を除去すると、複数の車載ネットワークにまたがる相互の通信が実施できなくなるからである。
【0131】
以上、本発明者によってなされた発明を実施形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【0132】
また、上記各構成、機能、処理部などは、それらの全部または一部を、例えば集積回路で設計することによりハードウェアとして実現することもできるし、プロセッサがそれぞれの機能を実現するプログラムを実行することによりソフトウェアとして実現することもできる。各機能を実現するプログラム、テーブルなどの情報は、メモリやハードディスクなどの記憶装置、ICカード、DVDなどの記憶媒体に格納することができる。
【符号の説明】
【0133】
101:目標ECU、102:ネットワーク登録装置、103:構成管理サーバ、104:接続用車両コネクタ、201:通信ゲートウェイ、202:車載ネットワーク、301:駆動系ネットワーク、302:エンジン制御ECU、303:AT制御ECU、304:HEV制御ECU、305:シャーシ/安全系ネットワーク、306:ブレーキ制御ECU、307:シャーシ制御ECU、308:ステアリング制御ECU、309:ボディ/電装系ネットワーク、310:計器表示ECU、311:エアコン制御ECU、312:盗難防止制御ECU、313:AV/情報系ネットワーク、314:ナビゲーションECU、315:オーディオECU、316:ETC/電話ECU、317:車外通信部、318:ETC無線機、319:VICS無線機、320:TV/FM無線機、321:電話用無線機、322:車外情報用ネットワーク、1000:車載ネットワークシステム。
【技術分野】
【0001】
本発明は、車載ネットワークシステムに関する。
【背景技術】
【0002】
近年、乗用車、トラック、バス等には、各機能部を制御する車載ECU(Electronic Control Unit)が多数搭載されている。各ECUは車載ネットワークを介して相互接続し、協調動作する。
【0003】
通常、車載ECUが搭載している制御プログラムは、車載ECUに内蔵されているマイクロコンピュータのフラッシュROM(Read Onle Memory)などの記憶装置に格納されている。この制御プログラムのバージョンは、製造者によって管理されており、正規のソフトウェアバージョンを組み合わせることにより、単独機能および車載ネットワークを通じての協調機能が正常に動作するように意図されている。
【0004】
したがって、意図しないソフトウェアを搭載した車載ECU、または意図的に改竄された車載ECUが車載ネットワークに接続されることは、車両のセキュリティの観点から看過できない。
【0005】
各車載ECUが自局のソフトウェアの真正性を外部に証明すること、さらには全ての関連する車載ECUの真正性を証明することを、構成証明と呼ぶ。構成証明が得られた場合は、製造者によって提供された正しいプログラムを組み合わせ、意図した制御が実施されているという確証となる。
【0006】
下記特許文献1には、共通鍵または共通鍵生成源を複数の車載ECU間で共有し、この情報を共有していると推定されているECU間で暗号化通信が成立するか否かにより、上記構成証明を実施する手法が開示されている。
【0007】
下記特許文献2には、KPS(Key Predistribution System)方式の共通鍵配信手法が開示されている。同方式は、特許文献1において共通鍵生成源として利用することができる。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開2010−11400号公報
【特許文献2】特公平5−48980号公報
【発明の概要】
【発明が解決しようとする課題】
【0009】
上記特許文献1では、共通鍵または共通鍵生成源を複数のECU間で共有させるため、センターサーバなどの外部インフラが必要である。また、車載ECU間で暗号化通信が成立することをもって構成証明に代えるため、暗号化通信を実施する際に多大な計算機パワーが必要となる。以下、これら2点の課題について詳述する。
【0010】
(1)センターサーバについて
(1.1)情報集約について
センターサーバは、全車の鍵情報が集約されている外部サーバであり、車載ネットワークを構成する各車載ECUはそれぞれセンターサーバに接続して鍵情報を受け取らなければならない。鍵情報の全てがセンターサーバに集約されているため、車載ECUとセンターサーバとの間の通信が妨害されたり、センターサーバ自体が攻撃されたり、悪意の第3者がセンターサーバになりすましたりした場合は、システム全体が崩壊しかねない。
【0011】
(1.2)センターサーバとの間の通信について
KPS方式によって配信する共通鍵生成源は、車載ネットワークに参加しているECU間で通信するために用いるものである。したがって、ECU間で安全に通信するためには、まず初期化処理としてセンターサーバから共通鍵生成源を取得する必要がある。このとき各ECUがセンターサーバと通信するために用いる暗号化鍵は、ECU毎に固有の暗号化鍵ではなく、固定の暗号化鍵を使わざるを得ない。なぜなら、車載ECUは、部品メーカにより量産され組み立てメーカに納入されるものであり、初期化処理のための暗号化鍵は、車種単位、同一部品番号単位、またはIDの等しいロット単位で、必然的にバリエーションが固定されるためである。暗号化鍵が固定であると、悪意の第3者にとってはECUとセンターサーバの間の通信を盗聴しやすくなるので、これを利用して初期化鍵を不正入手される可能性がある。初期化鍵が不正入手されると、センターサーバの情報が不正に引き出される可能性がある。また、車載ECUに対して偽りの共通鍵を配信し、他の車載ECUとの間の通信を妨害される可能性もある。
【0012】
(2)暗号化通信について
特許文献1に記載されている技術では、KPS方式に基づいて通信相手方の鍵を復元する計算資源と、その鍵を用いて暗号化通信するための共通鍵暗号処理(例えば、DES:Data Encryption Standard方式の暗号処理)を実行する計算資源とが必要になる。これらの処理は、現状の車載ECUの能力(CPUの計算能力、ROM/RAMの容量など)にとって非常に大きなリソースを要求する。したがって、特許文献1に記載されている暗号化通信を実現するためには、車載ECUのコスト上昇が避けられない。
【0013】
現状の車載ECUを設計する際には、各ECUおよびその構成部品の原価低減を積み上げて、車両システム全体の価格戦略を摺り合わせている。車載ECUの構成証明という目的に対して、これら構成部品の価格が上昇することは、到底許容できるものではない。
【0014】
本発明は、上記のような課題を解決するためになされたものであり、各車載制御装置の処理負荷(およびコスト)の上昇を抑えつつ、構成証明を実施する機能を備えた車載ネットワークを提供し、車両のセキュリティを向上させることを目的とする。
【課題を解決するための手段】
【0015】
本発明に係る車載ネットワークシステムは、車載制御装置を認証する構成管理装置を備え、構成管理装置は、構成証明を実施するために用いる構成証明データを、車載ネットワークに接続する登録装置を介して車載制御装置に配信する。
【発明の効果】
【0016】
本発明に係る車載ネットワークシステムは、車載制御装置を認証する構成管理装置が車載ネットワーク内に配置されているため、車内の鍵情報を車両外で保持する必要がない。したがって、安全でない通信方式を用いて車外と通信する必要がなくなり、セキュリティが向上する。また、登録装置は必ずしも車載ネットワークに常時接続されている必要はなく、車載制御装置を新規に登録する際に、オペレータが手作業で登録装置を車載ネットワークに接続させることができる。そのため、登録装置の処理能力を高めても、車載ネットワーク自体のコストは増加しないので、登録装置と構成管理装置の間では強固な認証方式を用いることができる。これにより、車載ネットワーク全体としてのコストを抑えつつセキュリティを向上させることができる。
【図面の簡単な説明】
【0017】
【図1】実施形態1に係る車載ネットワークシステム1000の構成図である。
【図2】構成管理サーバ103がネットワーク登録装置102を認証するシーケンスを説明する図である。
【図3】特許文献1に記載されている車載ネットワークの構成例を示す図である。
【図4】実施形態2に係る車載ネットワークシステム1000の構成例を示す図である。
【図5】構成管理サーバ103と目標ECU101の間で構成証明情報(共通鍵)を共有する形態を示す図である。
【図6】構成管理サーバ103が構成証明用鍵(共通鍵)を生成する方法を示す図である。
【図7】構成管理サーバ103が目標ECU101を認証する手順を説明するシーケンス図である。
【図8】構成管理サーバ103が目標ECU101を認証する手順を示す別方式のシーケンス図である。
【図9】構成管理サーバ103の内部で実行される処理を示すフローチャートである。
【図10】目標ECU101の内部で実行される処理を示すフローチャートである。
【図11】実施形態1〜3で説明した構成証明手法を、構成証明以外の用途に応用した動作例を説明する図である。
【図12】近年の代表的な高機能車両が備えている車載ネットワークのネットワークトポロジー例を示す図である。
【発明を実施するための形態】
【0018】
<実施の形態1>
図1は、本発明の実施形態1に係る車載ネットワークシステム1000の構成図である。車載ネットワークシステム1000は、車両の動作を制御するECUを接続する車内ネットワークである。ここでは、構成証明の対象である目標ECU101を1台のみ例示したが、車載ネットワークシステム1000に接続することができるECUは、これに限られるものではない。
【0019】
車載ネットワークシステム1000には、目標ECU101と構成管理サーバ103が車載ネットワークを介して接続されている。また、目標ECU101を車載ネットワークに参加させるため、必要に応じてネットワーク登録装置102が車載ネットワークシステム1000に接続される。
【0020】
構成管理サーバ103は、車載ネットワークを介して目標ECU101およびネットワーク登録装置102と通信することのできる装置である。構成管理サーバ103は、ECUの1種として構成してもよいし、その他任意の通信装置として構成してもよい。構成管理サーバ103は、目標ECU101とネットワーク登録装置102を認証する。目標ECU101を認証する目的は、目標ECU101が車載ネットワークに参加する正当権限を有しているか否かを確認することである。ネットワーク登録装置102を認証する目的は、ネットワーク登録装置102が目標ECU101を車載ネットワークに参加させる正当権限を有しているか否かを確認することである。
【0021】
ネットワーク登録装置102は、目標ECU101を車載ネットワークに参加させる装置である。車載ネットワークに参加させるとは、目標ECU101が車載ネットワークを介して他のECUと通信するために必要な構成証明データを目標ECU101に配信することである。ネットワーク登録装置102が目標ECU101を車載ネットワークに参加させるためには、あらかじめ構成管理サーバ103による認証を受ける必要がある。
【0022】
ネットワーク登録装置102は、必ずしも車載ネットワークに常時接続されている必要はない。例えば、車両の製造工程において車載ネットワークシステム1000を構築する際に、目標ECU101を車載ネットワークに参加させる作業を実施するときのみ、ネットワーク登録装置102を手作業で車載ネットワークに接続することができる。
【0023】
以下、図1にしたがって、ネットワーク登録装置102が目標ECU101を車載ネットワークに参加させる手順を説明する。
【0024】
(図1:ステップS111:認証要求)
オペレータは、ネットワーク登録装置102を操作して、目標ECU101を車載ネットワークに参加させる作業(登録処理)を開始する。ネットワーク登録装置102は、登録処理を開始すると、構成管理サーバ103に対し、自己を認証するように車載ネットワークを介して要求する。
【0025】
(図1:ステップS111:認証要求:補足)
ネットワーク登録装置102は、構成管理サーバ103に認証要求を出すと同時に、車載ネットワークに参加させる目標ECU101の識別情報(詳細は後述の図5で説明)を構成管理サーバ103に通知する。この識別情報としては、例えばECU−ID(部品番号)、ソフトウェアバージョンなどが挙げられる。これらの識別情報は、オペレータがネットワーク登録装置102上で手動入力するなどして与えることができる。
【0026】
(図1:ステップS112:構成証明鍵の配布)
構成管理サーバ103は、ネットワーク登録装置102から認証要求を受け取ると、所定の認証アルゴリズム(詳細は後述の図2で説明)にしたがってネットワーク登録装置102を認証する。構成管理サーバ103は、ネットワーク登録装置102の真正性を確認した場合は、認証要求時にネットワーク登録装置102から受け取った情報を用いて内部のデータベース(詳細は後述の図5で説明)を更新し、目標ECU101固有の構成証明用鍵(共通鍵)(詳細は後述の図6で説明)を生成して、ネットワーク登録装置102に配信する。
【0027】
(図1:ステップS113:鍵格納指令)
ネットワーク登録装置102は、目標ECU101に対して、構成管理サーバ103から配信された目標ECU101固有の構成証明用鍵(共通鍵)を中継し、目標ECU101にこれを格納するよう指示する。
【0028】
(図1:ステップS114:格納完了通知)
目標ECU101は、ステップS113で受け取った目標ECU101固有の構成証明用鍵(共通鍵)を自局のメモリに格納し、車載ネットワークに正常に参加した旨をネットワーク登録装置102に通知する。
【0029】
(図1:ステップS115:構成証明要求)
構成管理サーバ103は、ステップS112でネットワーク登録装置102を経由して配布しておいた構成証明用鍵(共通鍵)が目標ECU101内に保持されている、との推定に基づいて、目標ECU101に対して自局の真正性を証明するよう要求する。
【0030】
(図1:ステップS116:構成証明回答)
目標ECU101は、構成管理サーバ103に対して構成証明用鍵(共通鍵)の共有知識に基づいた回答を返信し、自局の真正性を証明する。
【0031】
(図1:ステップS116:構成証明回答:補足)
ステップS115〜S116における構成証明要求と回答は、構成管理サーバ103と目標ECU101の間で相互になされるべきものである。したがって、図1に図示するステップS115とステップS116の矢印方向とは逆に、目標ECU101が構成管理サーバ103に対して構成証明を要求し、構成管理サーバ103が回答してもよい。また、上記双方向のやり取りを合成して、目標ECU101が構成管理サーバ103に対して構成証明を開示する前に、構成管理サーバ103の構成証明を要求し、目標ECU101が構成管理サーバ103の真正性を確認しておいてから構成管理サーバ103に対して回答するように、相互的なハンドシェイクの形態を取ってもよい。
【0032】
<実施の形態1:ネットワーク登録装置の認証>
図2は、構成管理サーバ103がネットワーク登録装置102を認証するシーケンスを説明する図である。図2の認証シーケンスは、図1のステップS111の詳細を示すものである。ここでは、公開鍵暗号方式に基づくデジタル署名を用いてネットワーク登録装置102を認証する手法を例示するが、チャレンジ&レスポンス認証など別の認証方式を用いることもできる。なお、あらかじめネットワーク登録装置102の公開鍵と秘密鍵のペアを生成し、公開鍵を構成管理サーバ103に配信しておくものとする。以下、図2の各ステップについて説明する。
【0033】
(図2:ステップS201)
ネットワーク登録装置102は、例えば車載ネットワークに最初に接続した時点など、目標ECU101をネットワーク登録する動作に先立って、構成管理サーバ103に対し自己が正規端末であることを認証するように要求する。このとき、ネットワーク登録装置102の識別コード(またはそれに類する情報)を併せて送信し、自身を固有に識別する情報を構成管理サーバ103に対して明らかにする。
【0034】
(図2:ステップS201:補足)
本ステップでいう正規端末とは、ネットワーク登録装置102が当該車両のメーカによって認定された正規のものであること、改竄されたものでないこと、別の装置が正規のネットワーク登録端末102になりすましたものでないこと、などを保証された端末のことである。すなわち、目標ECU101を車載ネットワークに参加させる正当権限を有する端末である。
【0035】
(図2:ステップS202〜S203)
構成管理サーバ103は、認証開始処理を実行する(S202)。具体的には、疑似乱数を用いて種コードを生成し、ネットワーク登録装置102に返送する(S203)。また、ステップS201でネットワーク登録装置102から受け取った識別コードを用いて、ネットワーク登録装置102に対応する公開鍵を特定しておく。
【0036】
(図2:ステップS204〜S205)
ネットワーク登録装置102は、ステップS203で認証サーバから受け取った種コードを自身の秘密鍵で署名し(S204)、署名済みコードとして構成管理サーバ103に返送する(S205)。
【0037】
(図2:ステップS206)
構成管理サーバ103は、ステップS202で特定しておいた公開鍵を読み出し、これを用いてステップS205でネットワーク登録装置102から受け取った署名済みコードを復号する。構成管理サーバ103は、その復号結果とステップS203でネットワーク登録装置102に送信した種コードを比較し、両者が一致すればネットワーク登録装置102が正規端末であると判断する。両者が一致しなければ、ネットワーク登録装置102は認証許可されなかったことになる。
【0038】
(図2:ステップS207〜S208)
構成管理サーバ103は、認証シーケンスが終了した旨を、確認応答としてネットワーク登録装置102に対して送信する(S207)。その後、ネットワーク登録装置102は、これから車載ネットワークに参加させる予定の目標ECU101の{ECU−ID,ソフトウェアバージョン}を構成管理サーバ103に通知する(S208)。
【0039】
<実施の形態1:まとめ>
以上のように、本実施形態1に係る車載ネットワークシステム1000において、構成管理サーバ103は、厳密に真正性を検証することができるネットワーク登録装置102を経由して、目標ECU101に構成証明用鍵(共通鍵)を配布する。これにより、目標ECU101は、多大な計算資源を消費するKPS方式のように高度な計算を実施することなく、簡便に構成証明用鍵(共通鍵)を共有することができるので、ECUコストを抑えつつ車載ネットワークのセキュリティを向上させることができる。
【0040】
また、本実施形態1に係る車載ネットワークシステム1000において、ネットワーク登録装置102は必ずしも車載ネットワークシステム1000に常時接続する必要はないので、車載ネットワークシステム1000から独立した高性能な装置を用いてネットワーク登録装置102を構成することができる。これにより、車載ネットワークシステム1000を構成するECUのコストを抑えつつ、構成管理サーバ103とネットワーク登録装置102の間で強固な認証処理を実施することができる。この認証処理には、構成管理サーバ103と目標ECU101の間の認証処理よりも強固な手法を用いることができる。すなわち、ネットワーク登録装置102の性能を目標ECU101よりも高くすることができるので、多大なリソースを消費する強固な認証処理を実施することができる。
【0041】
また、本実施形態1に係る車載ネットワークシステム1000において、目標ECU101およびネットワーク登録装置102を認証する構成管理サーバ103は、車載ネットワーク内部に配置されている。これにより、各装置は認証処理を実施するために車外と通信する必要がなくなり、セキュリティを向上させることができる。また、認証処理を実施するためのリソースを構成管理サーバ103に集約させることにより、他のECUのコストを抑えることができる。
【0042】
<実施の形態2>
本発明の実施形態2では、実施形態1で説明した車載ネットワークシステム1000の具体的な構成例について説明する。
【0043】
以下、本実施形態2に係る車載ネットワークシステム1000(図4)と、特許文献1に記載されている従来例(図3)とを比較し、両者の構成とセキュリティに関する違いを説明する。
【0044】
<実施の形態2:従来例の説明>
図3は、特許文献1に記載されている車載ネットワークの構成例を示す図であり、本実施形態2と対比するために記載したものである。図3において、車載ネットワーク202の中にECUマスタ105が存在しており、これが車両ごとの識別番号{車両ID}を保持している。
【0045】
ECUマスタ105は、初期化処理を実施するとき、車載ネットワーク202の外部に設置されているセンターサーバ203に対して、{車両ID,ECU−ID,ソフトウェアバージョン}の情報をセットにして、{共通鍵生成源}を配信するよう要求する(ステップS311)。ECU−IDはECUマスタ105の識別子であり、ソフトウェアバージョンはECUマスタ105が搭載しているソフトウェアのバージョンである。
【0046】
センターサーバ203は、その要求に応じて{共通鍵生成源}を配布する(ステップS312)。これらのやり取りは、ECUマスタ105内部に固定的に設定された初期化鍵によって暗号化されている(外部通信F221)。
【0047】
センターサーバ203より配布される{共通鍵生成源}は、車載ネットワーク202に属するECU間の通信のみに使われる「共通鍵を導出する情報源」である。{共通鍵生成源}は、センターサーバ203と通信する際には用いられない。
【0048】
ECUマスタ105以外の車載ネットワークに属する目標ECU101は、ECUマスタ105より{車両ID}を入手する。この時点では、目標ECU101は{共通鍵生成源}を入手していないので、目標ECU101は暗号化を実施せずにECUマスタ105と通信する(ステップS313)。
【0049】
目標ECU101は、ECUマスタ105より受け取った{車両ID}を用いて、{車両ID,ECU−ID,ソフトウェアバージョン}のセットを組み立て、センターサーバ203に対して、{共通鍵生成源}を配信するよう要求する(ステップS314)。ECU−IDは目標ECU101の識別子であり、ソフトウェアバージョンは目標ECU101が搭載しているソフトウェアのバージョンである。
【0050】
センターサーバ203は、その要求に応じて{共通鍵生成源}を配布する(ステップS315)。これらのやり取りは、目標ECU101内部に固定的に設定された初期化鍵によって暗号化されている(外部通信F222)。
【0051】
以上の構成より、特許文献1における方式には次のような脆弱性が存在することが明らかとなる。
(脆弱性1)車載ネットワーク202に属する全てのECUは、初期化処理を実施するとき、車載ネットワーク202の外部に配置されているセンターサーバ203と接続して{共通鍵生成源}の配布を受ける。そのため、初期化処理中にセンターサーバ203との間の接続が断たれた場合は、有効な車載ネットワークを構成することができない。
(脆弱性2)センターサーバ203は、全ての車両の{車両ID,ECU−ID,ソフトウェアバージョン}と{共通鍵生成源}のセットを管理している。そのため、センターサーバ203が不正に侵入されると、全ての車両の鍵が流出する。また、故意・過失を問わずセンターサーバ203に障害が発生すると、全ての車両の鍵が紛失する危険を伴う。
(脆弱性3)初期化処理を実施するときの暗号化通信(外部通信F221および外部通信F222)が脆弱である。そのため、{共通鍵生成源}の配布をうける際に、ECUとセンターサーバ203との間の相互認証がセキュアではない。これは、部品として量産されるECUハードウェアの制約上、固定的でバリエーションの少ない暗号化鍵を使わざるを得ない特性に起因する。したがって、この暗号化鍵が破られると、センターサーバ203については特定車両の鍵情報が流出するおそれがあり、車載ECUについては悪意の第3者が偽りの鍵情報を配布することにより車載ネットワークへの妨害などが発生し得る。
(脆弱性4)初期化処理を実施するときのECUマスタ105から目標ECU101の間の{車両ID}の流れ(ステップS313)は暗号化されていないので、車載ネットワーク202の外部から容易にキャプチャすることができる。これは、{車両ID,ECU−ID,ソフトウェアバージョン}のセット(ステップS311およびステップS314で使用)を悪意の第3者が類推する糸口になる。
【0052】
<実施の形態2:本発明の説明>
図4は、本実施形態2に係る車載ネットワークシステム1000の構成例を示す図である。車載ネットワーク202に、構成管理サーバ103が設置されている。この車載ネットワーク202に新たな目標ECU101を参加させる手順を詳述する。
【0053】
オペレータは、ネットワーク登録装置102を接続用車両コネクタ104に接続し、構成管理サーバ103と通信して認証を受ける。このときオペレータは、これから車載ネットワーク202に参加させようとしている目標ECU101のECUI−IDなどをネットワーク登録装置102上で入力し、構成管理サーバ103に送信する。この手順は、図1のステップS111に相当する。
【0054】
構成管理サーバ103は、ネットワーク登録装置102の真正性を厳密に審査・検証する。構成管理サーバ103は、ネットワーク登録装置102が正規のものであることを確認した場合は、目標ECU101固有の{共通鍵}を発行する(ステップS112)。
【0055】
ネットワーク登録装置102は、この{共通鍵}を目標ECU101に中継して格納させる(ステップS113)。以上の手順により、構成管理サーバ103と目標ECU101の間で{共通鍵}が安全に共有される。
【0056】
以上説明した本発明のメカニズムにより、先に説明した従来例における脆弱性は、以下に示すように改善される。先に説明した脆弱性に対応する改善点を、脆弱性と同じ順番で説明する。
(改善点1)各ECUが実施する通信は、車載ネットワーク202内部でクローズしており、車両外部との間の通信は実施されない。したがって、車載ネットワーク202に対して不正侵入を受ける機会も、情報漏洩を発生させる機会も少ない。
(改善点2)車載ネットワーク202内の鍵情報は、車両ごとに内蔵されている構成管理サーバ103が管理する。したがって、センターサーバ203に全車両の情報を集約させることによる脆弱性は存在しない。また、{共通鍵}は車両ごとに独立してユニークであり、これが流出しても他車両に対するセキュリティ上の懸案事項は発生しない。
(改善点3)初期化処理を実施するときの{共通鍵}の発行および中継は、厳密に相互認証を実施した構成管理サーバ103とネットワーク登録装置102の間で実施される。したがって、悪意の第3者による妨害などのセキュリティリスクは少ない。
(改善点4)車載ネットワーク202のメンバを構成するECUの識別情報、例えば{車両ID,ECU−ID,ソフトウェアバージョン}は、構成管理サーバ103の内部のみで管理されている。そのため、車載ネットワーク202を介して他ECUにこれら識別情報を開示する必要がない。したがって、これら情報の漏洩リスクに対して頑健である。
【0057】
<実施の形態2:共通鍵の共有形態>
ネットワーク登録装置102は、目標ECU101上の不揮発性メモリ(EEPROM:Electronically Erasable and Programmable Read−Only Memory)に上記共通鍵情報を記憶させる機能のみを有する簡易装置として構成してもよいし、制御ソフトウェアを記憶するフラッシュROMに上記共通鍵情報を直接書き込むプログラム書換装置として構成してもよい。
【0058】
車両が市場に出た後に制御プログラムの不具合が発覚した場合、ディーラーは車両を回収して該当車載ECUのプログラムを書き換える。このとき、このプログラム書換装置を用いて、目標ECUのソフトバージョンアップ、構成証明用鍵(共通鍵)の更新、構成管理サーバ103の登録情報(ECU−ID,ソフトウェアバージョンなど)の更新が同時に実施できるようにしておけば、作業者にとって便宜である。そのため、ネットワーク登録装置102はプログラム書換装置としての機能を兼ね備えていることが望ましいといえる。
【0059】
なお図4において、ネットワーク登録装置102は、車載ネットワーク202に直接接続するように図示されているが、無線通信などの有線以外の信号結合方式を用いて車外の通信網と接続し、ネットワーク登録装置102をその通信網の一要素として構成してもよい。この場合も、車内の構成管理サーバ103とネットワーク登録装置102との間の認証は厳密に実行される。
【0060】
図5は、構成管理サーバ103と目標ECU101の間で構成証明情報(共通鍵)を共有する形態(情報分布形態)を示す図である。ここでは目標ECU101が複数存在する例を示した。
【0061】
図5(a)は、構成管理サーバ103内のデータベース410が格納しているデータ例を示す。各車載ECUの識別情報(ECU−ID,ソフトウェアバージョンなど)がデータ412で示すように保持されている。データ411は、構成管理サーバ自体の認証鍵であり、車載ECU全てに等しく配布される。
【0062】
図5(b)〜(d)に示すデータベース420、430、440は、目標ECU101a〜101cのメモリ上にそれぞれ記憶されている構成証明用鍵(共通鍵)のデータ例を示す。各目標ECU101が保持している共通鍵は、構成管理サーバ103が発行し、ネットワーク登録装置102を経由して設定されたものである。
【0063】
すなわち、構成管理サーバ内データベース410のデータ412のうちECU−IDとソフトウェアバージョンを除いた情報が、各目標ECU101に転写される。この共通鍵は、各目標ECU101が構成管理サーバ103に対して自己の真正性を証明するために用いる鍵情報である。以降、この情報を「ECU鍵」と呼ぶ。
【0064】
また、構成管理サーバ内データベース410のデータ411のうちECU−IDとソフトウェアバージョンを除いた共通鍵情報も、各目標ECU101に転写される。この共通鍵は、構成管理サーバ103が目標ECU101に対して自己の真正性を証明するために用いる鍵情報である。以降、この情報を「サーバ鍵」と呼ぶ。
【0065】
上述したECU鍵とサーバ鍵に加えて、構成管理サーバ103と各目標ECU101とが通信する際に用いるチャンネル番号またはメッセージIDなどの通信識別情報413を各目標ECU101に配信することもできる。
【0066】
通信識別情報413は、通信データの種別を指定する情報である。例えば、構成管理サーバ103が目標ECU101aに共通鍵を送信するときはメッセージID0x15を用い、目標ECU101bに共通鍵を送信するときはメッセージID0x17を用いる、といった使い分けをすることができる。各目標ECU101は、受信したデータが何を記述しているのかを、メッセージIDの値によって識別することができる。
【0067】
各目標ECU101は、車載ネットワーク202に参加する前は、構成証明において用いられる通信チャンネルを把握していない。そこで、構成証明用鍵(共通鍵)を配布するとともに各目標ECU101にメッセージIDを配布することができる。メッセージIDは、各目標ECU101のデータベース内に、それぞれデータ421、431、441として格納される。
【0068】
通信データの種別毎にメッセージIDを変えることにより、通信の秘匿性がより一層高まる。すなわち、悪意の第3者はどのメッセージIDを用いて共通鍵が配信されているかを知らないため、通信データのなかから共通鍵を抽出することが困難である。
【0069】
上述の各情報の他、構成管理サーバ内データベース410が格納している、ECU−ID、ソフトウェアバージョンなどの属性情報を、各目標ECU101に配信することもできる。これら情報は、ネットワーク登録装置102や目標ECU101にとって有用な情報である。
【0070】
ネットワーク登録装置102は、車両のECUが現在どのようなECU群・ソフトウェア群で構成されているのかを調査したい場合がある。また、車載ECUは、協調制御の相手方となる他の車載ECUのソフトウェアバージョンが自局の制御ソフトと対応しているのかを調査したい場合がある。このような要求に答えるため、構成管理サーバ103は、データベース410が保持しているこれら情報を、ネットワーク登録装置102や目標ECU101に配信してもよい。
【0071】
ただしセキュリティの観点から、これら情報の開示は、ネットワーク登録装置102については前述の認証が厳密に実施された後、車載ECUについては当該ECUの構成証明が厳密に実施された後になされる。
【0072】
図5に示すデータベース410は、オペレータがネットワーク登録装置102を用いて内容を閲覧し、更新することができるように構成してもよい。閲覧または更新に先立って構成管理サーバ103がネットワーク登録装置102を認証するのは、構成証明の場合と同様である。
【0073】
<実施の形態2:共通鍵の生成手段>
図6は、構成管理サーバ103が構成証明用鍵(共通鍵)を生成する方法を示す図である。以下図6にしたがって、構成証明用鍵を生成する手順を説明する。
【0074】
車両識別番号501は、車両個々にユニークに付けられる番号であり、構成管理サーバ103が内部的に情報を保持している。ECU−ID(部品番号)502とソフトウェアバージョン503は、車載ネットワーク202に参加させようとしている目標ECU101のECU−ID(部品番号)とソフトウェアバージョンである。乱数504は、構成管理サーバ103内部で適宜発生させた乱数である。例えば、半導体閾値のホワイトノイズ的な揺らぎで一様乱数を生成するデバイスを用いて生成することができる。簡易的には、例えばマイコンのフリーランカウンタなどを適当なタイミングでキャプチャした数値列を乱数504として採用してもよい。
【0075】
構成管理サーバ103は、これらの値を一方向性ハッシュ関数505に入力する。一方向性ハッシュ関数505は、固定長のECU固有の共通鍵506を出力する。この共通鍵506またはこれを用いて算出した値を、構成証明用鍵として用いることができる。
【0076】
一方向性ハッシュ関数505は、ECU固有の共通鍵506から、車両識別番号501、ECU−ID(部品番号)502、ソフトウェアバージョン503などの情報を復元することが不可能となるようにするために用いる。また、入力値が少しでも変わると共通鍵506も変化し、生成値が衝突しにくく、同一の出力値を与える入力値の組み合わせが予見不可能であることも重要である。
【0077】
一方向性ハッシュ関数505の入力値として、車両識別番号501を用いているので、同じECU−ID(部品番号)502の目標ECU101をネットワーク登録しても、車両ごとに共通鍵506の値は異なる。また、一方向性ハッシュ関数505の入力値として乱数504を用いているので、同一車両の車載ネットワーク202に、同一のECU−ID(部品番号)502および同一のソフトウェアバージョン503の車載ECUを参加させても、参加を実施する毎に共通鍵506の値は異なる。
【0078】
この仕組みにより、ECU改竄やECU不正入れ換えを検出する能力を向上させることができる。同様の効果を発揮することができれば、一方向性ハッシュ関数505以外の関数を用いてもよいが、共通鍵506に基づき元の値を推測することができないようにする観点からは、一方向性関数を採用することが望ましい。
【0079】
<実施の形態2:構成証明の手順>
図7は、構成管理サーバ103が目標ECU101を認証する手順を説明するシーケンス図である。ここでは上述のサーバ鍵とECU鍵をパスワードとして用いる例を示した。以下、図7の各ステップについて説明する。
【0080】
(図7:ステップS701〜S702:構成証明の開始)
構成管理サーバ103は、目標ECU101に対して、構成証明要求を送信する(S701)。この構成証明要求は、車両が特定の状態時(始動直後、アイドリング時、イグニッションオフ直後など)に実施してもよいし、定期的に実施してもよい。目標ECU101は、証明を要求しているのが本当に正規の構成管理サーバ103であるかを確かめるため、サーバ認証要求を返信する(S702)。
【0081】
(図7:ステップS701〜S702:補足)
前述の構成証明用鍵(共通鍵)とともに通信識別情報413を配布する場合は、図7に示す通信シーケンスは、各ECUが記憶している通信チャンネルまたはメッセージIDを用いて実施される。
【0082】
(図7:ステップS703〜S704:サーバ側認証)
構成管理サーバ103は、自分の真正性を目標ECU101に示すため、サーバ鍵をサーバ側パスワードとして開示する(S703)。このサーバ鍵と、目標ECU101が内部に保持しているサーバ鍵とが一致した場合、構成管理サーバ103が真正であると結論付けられる(S704)。
【0083】
(図7:ステップS705〜S707:ECU側構成証明)
構成管理サーバ103が真正である旨を目標ECU101が確認した場合、目標ECU101は、ECU鍵をECU側パスワードとして構成管理サーバ103に送信する(S705)。構成管理サーバ103は、データベース410が保持している鍵と受信したECU鍵が一致した場合、目標ECU101は改竄されていないと判断する(S706)。以上の手順によって構成証明が完了し、構成管理サーバ103はセッション終了通知を目標ECU101に送信する(S707)。
【0084】
<実施の形態2:構成証明の手順その2>
図7で説明した手順によれば、サーバ認証とECU構成証明を簡便に実行することができる。ただし、サーバ鍵とECU鍵が直接車載ネットワーク202上に流れるので、これをキャプチャすれば、改竄された目標ECU101(もしくは構成管理サーバ103)を作成して車載ネットワーク202に接続することができる。
【0085】
このような状況を防止し、セキュリティ性能を向上させるため、構成証明用鍵(共通鍵)を直接車載ネットワーク202に流すことに代えて、チャレンジ&レスポンス認証の共通鍵として構成証明用鍵を用いることもできる。図8を用いてその手順を説明する。
【0086】
図8は、構成管理サーバ103が目標ECU101を認証する手順を示す別方式のシーケンス図である。以下、図8の各ステップについて説明する。
【0087】
(図8:ステップS801:構成証明要求)
構成管理サーバ103は、目標ECU101に対して、構成証明要求を送信する(S801)。この構成証明要求は、車両が特定の状態時(始動直後、アイドリング時、イグニッションオフ直後など)に実施してもよいし、定期的に実施してもよい。目標ECU101は、証明を要求しているのが本当に正規の構成管理サーバ103であるかを確かめる認証処理を開始する。
【0088】
(図8:ステップS802〜S803)
目標ECU101は、乱数を発生させ(S802)、サーバ認証用のチャレンジデータとして構成管理サーバ103に送信する(S803)。
【0089】
(図8:ステップS804〜S805)
構成管理サーバ103は、ステップS803のサーバ認証用チャレンジを受け取り、このデータとサーバ鍵を入力として、一方向性ハッシュ関数を用いてレスポンスを計算する(S804)。構成管理サーバ103は、算出したレスポンスをサーバ側レスポンスとして目標ECU101に送信する(S805)。
【0090】
(図8:ステップS806)
目標ECU101は、ステップS802で生成した乱数と、構成管理サーバ103との間で共有しているサーバ鍵とを一方向性ハッシュ関数に入力し、レスポンスとして構成管理サーバ103から帰ってくるであろうと予測される期待値を計算する。構成管理サーバ103と目標ECU101は、規約によりそれぞれ同じアルゴリズムの一方向性ハッシュ関数を採用していると推定されるので、同じデータを入力とする一方向性ハッシュ関数の出力値は一致するはずである。
【0091】
(図8:ステップS807〜S808)
目標ECU101は、ステップS806で計算した値と、構成管理サーバ103から受け取った値とを比較する(S807)。両者の値が一致すれば、構成管理サーバ103の真正性が証明されたことになるので、目標ECU101は構成証明用チャレンジ要求を構成管理サーバに送信する(S808)。
【0092】
(図8:ステップS809〜S810)
構成管理サーバ103は、ステップS808で目標ECU101が送信した構成証明用チャレンジ要求を受信すると、乱数を発生させ(S809)、目標ECU101に対して構成証明用チャレンジデータとして送信する(S810)。乱数発生の手段は、目標ECU101と同様である。
【0093】
(図8:ステップS811〜S813)
構成管理サーバ103は、ステップS810で送信したチャレンジデータとECU鍵を用いて、ステップS806と同様の手順でレスポンスの期待値を計算しておく(S811)。目標ECU101は、ステップS810で構成管理サーバ103が送信したチャレンジデータとECU鍵を用いて、ステップS804と同様の手順でレスポンスを計算し(S812)、構成管理サーバ103に返信する(S813)。
【0094】
(図8:ステップS814〜S815)
構成管理サーバ103は、ステップS813で目標ECU101から返信された構成証明用レスポンスとステップS811で計算した期待値を比較する。両者が一致すれば、目標ECU101の構成証明が得られたことになる(S814)。その後、構成管理サーバ103は、目標ECU101に対してセッション終了通知を送信する(S815)。
【0095】
<実施の形態2:まとめ>
以上のように、本実施形態2に係る車載ネットワークシステム1000において、構成管理サーバ103は、車載ネットワークに202に接続される全ての車載ECUの識別情報(ECU−ID(部品番号)、ソフトウェアバージョン等)を管理する。この管理形態は、全車両の情報を集約する外部サーバなどを用いず、各車両が自己の識別情報を個別に保持する分散制御として構成される。したがって、情報管理形態としてロバストであり、個別車両の構成管理サーバ103が破られても、セキュリティ危機が全車両に波及することがない。
【0096】
また、本実施形態2に係る車載ネットワークシステム1000において、目標ECU101を車載ネットワーク202に参加させる際に、信頼できるネットワーク登録装置102の力を借りて、安全に構成証明用鍵(共通鍵)を配信することができる。これにより、上述のように簡単なチャレンジ&レスポンス認証で、構成管理サーバ103と目標ECU101が互いに相手方を認証し、構成の真正性を互いに証明し合うことができる。
【0097】
また、本実施形態2に係る車載ネットワークシステム1000においては、構成証明を実施する際に、高度な暗号化通信(一般の共通鍵暗号や公開鍵暗号)や共通鍵配信技術(KPS方式など)を使う必要がない。すなわち、現状のECUにおけるCPU/ROM/RAM等の計算リソースを構成証明のために浪費する必要がなくなり、ひいては実装コストが増加しない。したがって本手法は、構成証明機能を車載ネットワークシステム1000に簡便に付加し、ECUの改竄に対抗する手法として、非常にコストパフォーマンスに優れた方式であると言える。
【0098】
<実施の形態3>
本発明の実施形態3では、実施形態2で開示した車載ネットワークシステム1000の具体的なソフトウェア実装例について説明する。図9と図10は、図8で示したチャレンジ&レスポンス方式の構成証明手順を、ソフトウェア実装の観点でフローチャートとして開示したものである。したがって、機能として図8のシーケンスとは完全に等価というわけではなく、異常系処理と診断NG時の警告系処理を含んでいる。
【0099】
図9は、構成管理サーバ103の内部で実行される処理を示すフローチャートである。以下、図9の各ステップについて説明する。
【0100】
(図9:ステップS901〜S905:構成証明開始)
構成管理サーバ103は、データベース410より、検証すべき目標ECU101の共通鍵を読み出し、構成証明に備える(S901)。その後、該当する目標ECU101に対して構成証明要求を送信し(S902)、タイムアウト計測に備えてタイマを初期化する(S903)。構成管理サーバ103は、サーバ認証用チャレンジデータの到来を待ち受け(S904)、データが到来すればステップS906に遷移する。サーバ認証用チャレンジデータが到来せずタイムアウトと判定された場合は(S905)、目標ECU101が反応していないと判断し、ステップS917に遷移する。
【0101】
(図9:ステップS906〜S910:サーバ側認証)
構成管理サーバ103は、サーバ認証用チャレンジデータを受信すると、サーバ鍵を用いてレスポンスを計算し(S906)、目標ECU101にレスポンスを返信する(S907)。その後、ECU側の判定を待ち受けるためのタイムアウト計測に備えてタイマを初期化する(S908)。構成管理サーバ103は、目標ECU101から構成証明用チャレンジ要求を待ち受け(S909)、要求を受信すると、目標ECU101がサーバ認証を受け入れたということなので、ステップS911に遷移する。構成証明用チャレンジ要求が到来せずタイムアウトと判定された場合は(S910)、目標ECU101がサーバ認証を受け入れなかったか、または目標ECU101が改竄され手続きを知らない可能性があると判断し、ステップS917に遷移する。
【0102】
(図9:ステップS911〜S916:ECU側証明要求)
ステップS911〜S916は、目標ECU101の構成証明を実施するためのデータを準備するステップである。構成管理サーバ103は、乱数を発生させ(S911)、構成証明用チャレンジデータとして目標ECU101に送信する(S912)。その後、タイムアウト計測用タイマを初期化し(S913)、ステップS901で検索済みの目標ECU101のECU鍵を用いて、レスポンスの期待値を計算する(S914)。構成管理サーバ103は、目標ECU101から構成証明用レスポンスを待ち受け(S915)、レスポンスがあった場合はステップS918に遷移する。構成証明用レスポンスが到来せずタイムアウトと判定された場合は(S916)、目標ECU101が改竄され手続きを知らない可能性があると判断し、ステップS917に遷移する。
【0103】
(図9:ステップS917:ECU不正検出&警告処理)
構成管理サーバ103は、適当なインターフェースを介して、目標ECU101が改竄されている旨の警告信号を出力するか、またはその旨を記述した通信データを車載ネットワーク202に対してブロードキャストする。
【0104】
(図9:ステップS918〜S920:構成証明結果)
構成管理サーバ103は、ステップS914で計算した期待値と、目標ECU101から受信した構成証明用レスポンスとを比較する(S918)。両者が一致すれば構成証明が完了したということなので、目標ECU101にセッション終了通知を送信し(S919)、構成証明が終了したことを通知する。その後、全ての検査すべき車載ECUについて構成証明が完了したか否かをチェックする(S920)。完了している場合は図9の処理を終了し、未完である場合はステップS901に戻る。期待値と構成証明用レスポンスとが一致しなかった場合は、目標ECU101が他の車両のものと取り換えられたり、車載ネットワーク202に参加する処理を実行しないまま車載ネットワーク202に接続されたりするなど、不正な改竄が行われた可能性があると判断し、ステップS917に遷移する。
【0105】
図10は、目標ECU101の内部で実行される処理を示すフローチャートである。以下、図10の各ステップについて説明する。
【0106】
(図10:ステップS1001〜S1007:サーバ側認証開始)
目標ECU101は、構成管理サーバ103からの構成証明要求を待ち受け、要求が到着するとステップS1002に遷移する(S1001)。目標ECU101は、構成管理サーバ103が改竄されていないか(悪意の盗聴装置ではないか)を確認するために乱数を発生し(S1002)、サーバ認証用チャレンジデータとして送信する(S1003)。目標ECU101は、タイムアウト計測用タイマを初期化し(S1004)、サーバ鍵を用いて構成管理サーバ103からのレスポンスの期待値を計算する(S1005)。目標ECU101は、構成管理サーバ103からのサーバ認証用レスポンスを待ち受け(S1006)、返信を受け取るとステップS1008に遷移する。サーバ認証用レスポンスが到来せずタイムアウトと判定された場合は(S1007)、構成管理サーバ103が改竄されるか、または悪意の盗聴装置と交換されている可能性があると判断し、ステップS1018に遷移する。
【0107】
(図10:ステップS1008〜S1012:ECU側構成証明開始)
目標ECU101は、ステップS1005で計算した期待値と、構成管理サーバ103から受信したサーバ認証用レスポンスとを比較する(S1008)。両者が一致すれば、構成管理サーバ103の真正性が確認されたということなので、ステップS1009に遷移する。期待値とサーバ認証用レスポンスとが一致しなかった場合は、構成管理サーバ103が他の車両のものと取り換えられるか、または不正な改竄が行われた可能性があると判断し、ステップS1018に遷移する。目標ECU101は、構成管理サーバ103に対して、自局の真正性を証明するための構成証明用チャレンジデータを送信するよう要求する(S1009)。その後、構成管理サーバ103から構成証明用チャレンジデータを待ち受けるためのタイムアウト計測に備えてタイマを初期化する(S1010)。目標ECU101は、構成管理サーバ103から構成証明用チャレンジデータを待ち受け、返信を受け取るとステップS1013に遷移する。構成証明用チャレンジデータが到来せずタイムアウトと判定された場合は(S1012)、構成管理サーバ103が改竄され手続きを知らない可能性があると判断し、ステップS1018に遷移する。
【0108】
(図10:ステップS1013〜S1017:構成証明結果)
目標ECU101は、構成管理サーバ103から受信した構成証明用チャレンジデータとECU鍵を用いてレスポンスを計算し(S1013)、構成管理サーバに返信する(S1014)。また、構成管理サーバ103からの応答を監視するためのタイムアウト計測に備えてタイマを初期化する(S1015)。目標ECU101は、構成管理サーバ103からセッション終了通知を待ち受け、返信を受け取ると、構成管理サーバ103が構成証明を完了したことを意味しているので、図10の処理を終了する(S1016)。構成証明用チャレンジデータが到来せずタイムアウトと判定された場合は(S1017)、構成管理サーバ103が他の車両のものと取り換えられるか、または不正な改竄が行われた可能性があると判断し、ステップS1018に遷移する。
【0109】
(図10:ステップS1018:構成管理サーバ不正検出&警告処理)
目標ECU101は、適当なインターフェースを介して、構成管理サーバ103が改竄されている旨の警告信号を出力するか、またはその旨を記述した通信データを車載ネットワーク202に対してブロードキャストする。
【0110】
<実施の形態3:まとめ>
以上のように、本実施形態3に係る車載ネットワークシステム1000において、構成証明は、構成管理サーバ103と目標ECU101の間の相互認証によって実施される。これにより、構成管理サーバ103または目標ECU101が改竄されたことを検知し、その旨の警告を発信することができる。
【0111】
<実施の形態4>
図11は、実施形態1〜3で説明した構成証明手法を、構成証明以外の用途に応用した動作例を説明する図である。図11では、ECU101が2台存在し(ECU101aと101b)、これらECUの間でデジタル署名付きのメッセージを送受信する動作を想定する。
【0112】
ECU鍵は、構成管理サーバ103と特定の車載ECUのペア間のみで共有される情報であるが、サーバ鍵は複数の車載ECUが共有する情報である。したがって、サーバ鍵を用いて複数の車載ECU間でメッセージ認証符号(MAC:Message Authentication Code)を送受信し、メッセージの真正性を保証することが考えられる。
【0113】
サーバ鍵は、目標ECU101が車載ネットワーク202に参加するときに、構成管理サーバ103から安全に配布されたものであり、車載ネットワーク202に属する正規ECU以外には流出しない。よって、このサーバ鍵を用いてデジタル署名(メッセージ認証符号を添付すること)を実施すれば、構成管理サーバ103により認証を受けた車載ECUからのメッセージであることを、他ECUが確認することができる。
【0114】
ECU101aは、送りたいメッセージ1011aとサーバ鍵1012aを一方向性ハッシュ関数1013aに入力してメッセージ認証符号(MAC)1014aを生成する。メッセージ1011aとメッセージ認証符号(MAC)1014aをパッキング(S1101)して送信バッファ1015aに格納し、車載ネットワーク202に送り出す(S1102)。
【0115】
ECU101bは、ECU101aが送信した信号を受信(S1103)して受信バッファ1016bに格納し、送信側と申し合わせた規約によりアンパック(S1104)して、メッセージ1011bとメッセージ認証符号(MAC)1014bとに分離する。
【0116】
ECU101bは、メッセージ1011bとサーバ鍵1012b(サーバ鍵1012aと等しいと推定される)を一方向性ハッシュ関数1013bに入力して受信側メッセージ認証符号(MAC)を作成し(S1105)、MAC1014bと受信側メッセージ認証符号(MAC)を比較器1017bにより比較する。両者が一致する旨の判定結果1018bが得られれば、メッセージ1011bの内容が確かにECU101aによって作成されたものであり、途中で改竄されていないと判断できる。
【0117】
なお、一方向性ハッシュ関数1013aと1013bは、ECU間の規約にしたがって同一のアルゴリズムを採用するものとする。
【0118】
図11では、ネットワーク登録装置102により正規に車載ネットワーク202へ参加したECUが共通して保持するサーバ鍵を用いてメッセージ認証符号(MAC)を実現する実施例を開示したが、この用途はメッセージ認証符号に限られるものではなく、共通鍵暗号方式(例えば、DES方式、AES(Advanced Encryption Standard)方式など)による車載ECU間の暗号化通信に応用してもよい。
【0119】
<実施の形態4:まとめ>
以上のように、本発明による車載ECU間で共通鍵を共有する手法は、構成証明用途のみならず、任意の車載ECU間での高信頼度通信についても有効であることが分かる。
【0120】
<実施の形態5>
図12は、近年の代表的な高機能車両が備えている車載ネットワークのネットワークトポロジー例を示す図である。ネットワーク登録装置(ソフトウェア書換装置が兼任)102、構成管理サーバ103、各ECUなどの構成および動作は、実施形態1〜4と同様である。
【0121】
図12において、4群のネットワークが搭載されており、各々通信ゲートウェイ(ゲートウェイECU)201によってネットワークが束ねられている。図12では、ゲートウェイECU201を中心にしてスター型のネットワーク配置を採用しているが、ゲートウェイECU201を複数段設けてカスケード型の接続形態を採用してもよい。
【0122】
図12に示す車載ネットワークには、駆動系ネットワーク301、シャーシ/安全系ネットワーク305、ボディ/電装系ネットワーク309、AV/情報系ネットワーク313が搭載されている。
【0123】
駆動系ネットワーク301の配下には、エンジン制御ECU302、AT(Automatic Transmission)制御ECU303、HEV(Hybrid Electric Vehicle)制御ECU304が接続されている。シャーシ/安全系ネットワーク305の配下には、ブレーキ制御ECU306、シャーシ制御ECU307、ステアリング制御ECU308が接続されている。ボディ/電装系ネットワーク309の配下には、計器表示ECU310、エアコン制御ECU311、盗難防止制御ECU312が接続されている。AV/情報系ネットワーク313の配下には、ナビゲーションECU314、オーディオECU315、ETC/電話ECU316が接続されている。
【0124】
また、車両と外部との間で情報を送受信するため、車外通信部317が車外情報用ネットワーク322によってゲートウェイECU201に接続されている。車外通信部317には、ETC無線機318、VICS(Vehicle Information and Communication System)無線機319、TV/FM無線機320、電話用無線機321が接続されている。
【0125】
ネットワーク登録装置102は、車両が備えている接続用車両コネクタ104を介して、車外情報用ネットワーク322の1ノードとして接続するように構成されている。これに代えて、他のネットワーク(駆動系ネットワーク301、シャーシ/安全系ネットワーク305、ボディ/電装系ネットワーク309、AV/情報系ネットワーク313)またはゲートウェイECU201に単独で接続してもよい。すなわち、機械的な配置は無関係であって、直接もしくはゲートウェイECU201を介して目標ECUに対して電気信号が到達すればよい。
【0126】
電話用無線機321を通じてネットワーク越しに車外通信網からネットワーク登録装置102の機能を実施することもできる。例えば、構成管理サーバ103のデータベース検索や目標ECU101の構成証明用データのメンテナンスなどが考えられる。この場合においても、上述の実施形態1〜4と同様の手法を用いることができる。
【0127】
電話網越しやインターネット越しにECUのソフトウェアを書き換える手法は、リコールなどの不具合対応に際してその実施コストを下げる重要技術であって、将来的にありふれた行為になることが予想される。
【0128】
したがって、本発明で開示する技術を用いることによって、このソフトウェア書き換え後に引き続いて、リモートで構成管理サーバ103のデータベース内容を更新し、リモートでソフトウェア書き換え後の車載ECUを正しくネットワークに再登録することができる。
【0129】
図12では、構成管理サーバ103を通信ゲートウェイECU201の配下に直接接続したが、構成管理サーバ103のネットワーク上の位置は任意でよい。すなわち、電気信号的な接続が確保できるのであれば、他のネットワーク(駆動系ネットワーク301、シャーシ/安全系ネットワーク305、ボディ/電装系ネットワーク309、AV/情報系ネットワーク313、車外情報用ネットワーク322など)に直接接続してもよい。
【0130】
ただし、以下の2つの観点で通信ゲートウェイECU201が構成管理サーバ103の役割を兼ねることが望ましい。
(1)図1の認証シーケンスS111が失敗したとき、ネットワーク登録装置102からの通信を、目標ECU101が属する車載ネットワーク(駆動系ネットワーク301、シャーシ/安全系ネットワーク305、ボディ/電装系ネットワーク309、AV/情報系ネットワーク313)から電気的に切り離すことができる。この構成を用いることによって、いわゆるファイヤーウォール(防火壁)機能を通信ゲートウェイ201に付与することになるので、車載ネットワークに対する外部からの侵入リスクを低下させ、セキュリティをさらに向上させることができる。
(2)車両の不正改造・特定車載ECUの改竄などの目的で、構成管理サーバ103が車載ネットワークから除去される行為を防がなければならない。その目的では、通信ゲートウェイECU201と構成管理サーバ103が機能統合されており、1つのECUであることは望ましい。なぜなら、構成管理サーバ103を除去すると、複数の車載ネットワークにまたがる相互の通信が実施できなくなるからである。
【0131】
以上、本発明者によってなされた発明を実施形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【0132】
また、上記各構成、機能、処理部などは、それらの全部または一部を、例えば集積回路で設計することによりハードウェアとして実現することもできるし、プロセッサがそれぞれの機能を実現するプログラムを実行することによりソフトウェアとして実現することもできる。各機能を実現するプログラム、テーブルなどの情報は、メモリやハードディスクなどの記憶装置、ICカード、DVDなどの記憶媒体に格納することができる。
【符号の説明】
【0133】
101:目標ECU、102:ネットワーク登録装置、103:構成管理サーバ、104:接続用車両コネクタ、201:通信ゲートウェイ、202:車載ネットワーク、301:駆動系ネットワーク、302:エンジン制御ECU、303:AT制御ECU、304:HEV制御ECU、305:シャーシ/安全系ネットワーク、306:ブレーキ制御ECU、307:シャーシ制御ECU、308:ステアリング制御ECU、309:ボディ/電装系ネットワーク、310:計器表示ECU、311:エアコン制御ECU、312:盗難防止制御ECU、313:AV/情報系ネットワーク、314:ナビゲーションECU、315:オーディオECU、316:ETC/電話ECU、317:車外通信部、318:ETC無線機、319:VICS無線機、320:TV/FM無線機、321:電話用無線機、322:車外情報用ネットワーク、1000:車載ネットワークシステム。
【特許請求の範囲】
【請求項1】
車両の動作を制御する車載制御装置と、
前記車載制御装置が前記車両の車載ネットワークに参加する正当権限を有するか否かを認証する構成管理装置と、
を備え、
前記構成管理装置は、
前記車載制御装置を前記車載ネットワークに参加させる登録装置から、前記車載制御装置を前記車載ネットワークに参加させるよう要求する登録要求を受け取ると、前記登録装置に対する認証を実施した上で、前記車載制御装置に固有の構成証明データを作成して前記登録装置に返信し、
前記登録装置は、
前記構成管理装置から前記構成証明データを受け取って前記車載制御装置に中継し、
前記車載制御装置は、
前記登録装置から前記構成証明データを受け取ってメモリ内に格納する
ことを特徴とする車載ネットワークシステム。
【請求項2】
前記構成管理装置は、
前記構成証明データを用いて前記車載制御装置を認証し、
前記車載制御装置を認証する認証手順とは異なる認証手順によって前記登録装置を認証する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項3】
前記構成証明データは、
前記構成管理装置が前記車載制御装置を認証する際のパスワード、または
前記構成管理装置が前記車載制御装置を認証する際に実施するチャレンジ&レスポンス認証において前記車載制御装置がレスポンスを生成する際に用いる共通鍵
のうち少なくともいずれかを含む
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項4】
前記構成証明データは、
前記車載制御装置が前記車載ネットワーク上でメッセージ認証符号を送受信する際に、メッセージからデジタル署名を作成するために用いる共通鍵、または
前記車載制御装置が前記車載ネットワーク上で暗号化通信を実施するために用いる共通鍵
のうち少なくともいずれかを含む
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項5】
前記構成管理装置は、
前記車載制御装置毎、前記車載制御装置が備えるソフトウェアのバージョン毎、前記車両の車種毎、または前記車両を個体毎に識別する車両識別番号毎に異なる値を出力する一方向性関数を用いて、前記構成証明データを生成する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項6】
前記構成管理装置は、
前記車載ネットワークに参加している前記車載制御装置から、前記構成証明データまたは前記構成証明データを用いて生成された認証データを受信することにより、前記車載ネットワークに参加している前記車載制御装置を認証し、
前記車載ネットワークに参加している前記車載制御装置に対して前記構成証明データまたは前記認証データを送信するように要求してもその応答として前記構成証明データまたは前記認証データを受信することができない場合、前記車載ネットワークに参加している前記車載制御装置から定期的に前記構成証明データまたは前記認証データを受信することができない場合、または前記車載制御装置の認証に失敗した場合は、
前記車載制御装置が改竄された旨を示す警告信号を出力するか、または前記車載制御装置が改竄された旨を記述した通信パケットを前記車載ネットワークに対してブロードキャストする
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項7】
前記車載制御装置は、前記構成証明データまたは前記構成証明データを用いて生成された認証データを用いて前記構成管理装置を認証する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項8】
前記車載制御装置は、
前記構成管理装置から前記構成証明データまたは前記認証データを受信することにより、前記構成管理装置を認証し、
前記構成管理装置に対して前記構成証明データまたは前記認証データを送信するように要求してもその応答として前記構成証明データまたは前記認証データを受信することができない場合、前記構成管理装置から定期的に前記構成証明データまたは前記認証データを受信することができない場合、または前記構成管理装置の認証に失敗した場合は、
前記構成管理装置が改竄された旨を示す警告信号を出力するか、または前記構成管理装置が改竄された旨を記述した通信パケットを前記車載ネットワークに対してブロードキャストするか、または以後の前記構成管理装置からの指示に従わない
ことを特徴とする請求項7記載の車載ネットワークシステム。
【請求項9】
前記構成証明データは、前記構成管理装置と前記車載制御装置の間で送受信する通信データの種別を記述した識別番号を含み、
前記構成管理装置と前記車載制御装置は、前記識別番号を指定した通信データによって前記構成証明データを送受信する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項10】
前記構成管理装置は、
前記車載ネットワークに接続する装置間の通信を中継する通信ゲートウェイとして動作し、
前記登録装置の認証に失敗した場合は、前記登録装置と前記車載制御装置との間の通信を遮断する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項11】
前記登録装置は、前記車載制御装置が搭載しているソフトウェアを書き換える書換装置としての機能を備える
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項12】
前記登録装置は、前記車載ネットワークに一時的に接続する通信装置である
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項13】
前記登録装置は、前記車両の外部に配置され、前記車載ネットワークを経由して前記構成管理装置または前記車載制御装置と通信する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項14】
前記構成管理装置は、
前記車載ネットワークに接続する前記車載制御装置の種別および搭載しているソフトウェアのバージョンを管理するデータベースを備え、
前記登録装置からの要求に応じて前記データベースが格納しているデータを更新し、
前記登録装置または前記車載制御装置から前記データベースが格納しているデータに対する問い合わせを受け取って前記データベースが格納しているデータを返信する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項1】
車両の動作を制御する車載制御装置と、
前記車載制御装置が前記車両の車載ネットワークに参加する正当権限を有するか否かを認証する構成管理装置と、
を備え、
前記構成管理装置は、
前記車載制御装置を前記車載ネットワークに参加させる登録装置から、前記車載制御装置を前記車載ネットワークに参加させるよう要求する登録要求を受け取ると、前記登録装置に対する認証を実施した上で、前記車載制御装置に固有の構成証明データを作成して前記登録装置に返信し、
前記登録装置は、
前記構成管理装置から前記構成証明データを受け取って前記車載制御装置に中継し、
前記車載制御装置は、
前記登録装置から前記構成証明データを受け取ってメモリ内に格納する
ことを特徴とする車載ネットワークシステム。
【請求項2】
前記構成管理装置は、
前記構成証明データを用いて前記車載制御装置を認証し、
前記車載制御装置を認証する認証手順とは異なる認証手順によって前記登録装置を認証する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項3】
前記構成証明データは、
前記構成管理装置が前記車載制御装置を認証する際のパスワード、または
前記構成管理装置が前記車載制御装置を認証する際に実施するチャレンジ&レスポンス認証において前記車載制御装置がレスポンスを生成する際に用いる共通鍵
のうち少なくともいずれかを含む
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項4】
前記構成証明データは、
前記車載制御装置が前記車載ネットワーク上でメッセージ認証符号を送受信する際に、メッセージからデジタル署名を作成するために用いる共通鍵、または
前記車載制御装置が前記車載ネットワーク上で暗号化通信を実施するために用いる共通鍵
のうち少なくともいずれかを含む
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項5】
前記構成管理装置は、
前記車載制御装置毎、前記車載制御装置が備えるソフトウェアのバージョン毎、前記車両の車種毎、または前記車両を個体毎に識別する車両識別番号毎に異なる値を出力する一方向性関数を用いて、前記構成証明データを生成する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項6】
前記構成管理装置は、
前記車載ネットワークに参加している前記車載制御装置から、前記構成証明データまたは前記構成証明データを用いて生成された認証データを受信することにより、前記車載ネットワークに参加している前記車載制御装置を認証し、
前記車載ネットワークに参加している前記車載制御装置に対して前記構成証明データまたは前記認証データを送信するように要求してもその応答として前記構成証明データまたは前記認証データを受信することができない場合、前記車載ネットワークに参加している前記車載制御装置から定期的に前記構成証明データまたは前記認証データを受信することができない場合、または前記車載制御装置の認証に失敗した場合は、
前記車載制御装置が改竄された旨を示す警告信号を出力するか、または前記車載制御装置が改竄された旨を記述した通信パケットを前記車載ネットワークに対してブロードキャストする
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項7】
前記車載制御装置は、前記構成証明データまたは前記構成証明データを用いて生成された認証データを用いて前記構成管理装置を認証する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項8】
前記車載制御装置は、
前記構成管理装置から前記構成証明データまたは前記認証データを受信することにより、前記構成管理装置を認証し、
前記構成管理装置に対して前記構成証明データまたは前記認証データを送信するように要求してもその応答として前記構成証明データまたは前記認証データを受信することができない場合、前記構成管理装置から定期的に前記構成証明データまたは前記認証データを受信することができない場合、または前記構成管理装置の認証に失敗した場合は、
前記構成管理装置が改竄された旨を示す警告信号を出力するか、または前記構成管理装置が改竄された旨を記述した通信パケットを前記車載ネットワークに対してブロードキャストするか、または以後の前記構成管理装置からの指示に従わない
ことを特徴とする請求項7記載の車載ネットワークシステム。
【請求項9】
前記構成証明データは、前記構成管理装置と前記車載制御装置の間で送受信する通信データの種別を記述した識別番号を含み、
前記構成管理装置と前記車載制御装置は、前記識別番号を指定した通信データによって前記構成証明データを送受信する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項10】
前記構成管理装置は、
前記車載ネットワークに接続する装置間の通信を中継する通信ゲートウェイとして動作し、
前記登録装置の認証に失敗した場合は、前記登録装置と前記車載制御装置との間の通信を遮断する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項11】
前記登録装置は、前記車載制御装置が搭載しているソフトウェアを書き換える書換装置としての機能を備える
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項12】
前記登録装置は、前記車載ネットワークに一時的に接続する通信装置である
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項13】
前記登録装置は、前記車両の外部に配置され、前記車載ネットワークを経由して前記構成管理装置または前記車載制御装置と通信する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【請求項14】
前記構成管理装置は、
前記車載ネットワークに接続する前記車載制御装置の種別および搭載しているソフトウェアのバージョンを管理するデータベースを備え、
前記登録装置からの要求に応じて前記データベースが格納しているデータを更新し、
前記登録装置または前記車載制御装置から前記データベースが格納しているデータに対する問い合わせを受け取って前記データベースが格納しているデータを返信する
ことを特徴とする請求項1記載の車載ネットワークシステム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公開番号】特開2013−17140(P2013−17140A)
【公開日】平成25年1月24日(2013.1.24)
【国際特許分類】
【出願番号】特願2011−150357(P2011−150357)
【出願日】平成23年7月6日(2011.7.6)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.VICS
【出願人】(509186579)日立オートモティブシステムズ株式会社 (2,205)
【Fターム(参考)】
【公開日】平成25年1月24日(2013.1.24)
【国際特許分類】
【出願日】平成23年7月6日(2011.7.6)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.VICS
【出願人】(509186579)日立オートモティブシステムズ株式会社 (2,205)
【Fターム(参考)】
[ Back to top ]