(57)【要約】【課題】車載環境に適合した態様で構成証明を実現することができる暗号通信システムの提供。【解決手段】互いに通信する少なくとも２つ以上のＥＣＵが搭載される車両に適用される暗号通信システムであって、前記少なくとも２つ以上のＥＣＵの各ＥＣＵに対して、該各ＥＣＵ間の共通鍵又は該共通鍵の生成源を発行する発行手段と、前記各ＥＣＵの構成証明を行う構成証明手段とを備え、前記各ＥＣＵは、前記共通鍵又は共通鍵の生成源を用いた共通鍵方式の暗号により通信を行うと共に、前記構成証明手段により構成証明を受けないＥＣＵとの間で通信を確立しないように構成されることを特徴とする。【選択図】  図１
2010011400.tif 000002
【特許請求の範囲】
【請求項１】
互いに通信する少なくとも２つ以上のＥＣＵが搭載される車両に適用される暗号通信システムであって、
前記少なくとも２つ以上のＥＣＵの各ＥＣＵに対して、該各ＥＣＵ間の共通鍵又は該共通鍵の生成源を発行する発行手段と、
前記各ＥＣＵの構成証明を行う構成証明手段とを備え、
前記各ＥＣＵは、前記共通鍵又は共通鍵の生成源を用いた共通鍵方式の暗号により通信を行うと共に、前記構成証明手段により構成証明を受けないＥＣＵとの間で通信を確立しないように構成されることを特徴とする、暗号通信システム。
【請求項２】
前記発行手段は、車両外部の遠隔位置に配置され車両と通信可能に構成されるセンターサーバに設けられる、請求項１に記載の暗号通信システム。
【請求項３】
前記構成証明手段は、前記センターサーバに設けられる、請求項２に記載の暗号通信システム。
【請求項４】
前記構成証明手段は、前記複数のＥＣＵのうちの特定のＥＣＵに設けられる、請求項１又は２に記載の暗号通信システム。
【請求項５】
前記構成証明手段は、前記各ＥＣＵにそれぞれ設けられる、請求項１又は２に記載の暗号通信システム。
【請求項６】
前記共通鍵の生成源は、ＫＰＳ方式の鍵関数である、請求項１〜５のうちのいずれか１項に記載の暗号通信システム。
【請求項７】
請求項１〜６のうちのいずれか１項に記載の暗号通信システムで用いられるＥＣＵ。
【請求項８】
車載ＥＣＵであって、
他の車載ＥＣＵとの間の共通鍵又は該共通鍵の生成源を記憶する記憶手段と、
前記他の車載ＥＣＵが構成証明を受けたＥＣＵであるか否かを判断する判断手段と、
前記他の車載ＥＣＵが構成証明を受けていないＥＣＵであると判断した場合に、該他の車載ＥＣＵとの通信を無効化する通信無効化手段とを備える、車載ＥＣＵ。
【請求項９】
前記判断手段は、前記他の車載ＥＣＵが車載マスタＥＣＵにより構成証明を受けたＥＣＵであるか否かを判断する、請求項８に記載の車載ＥＣＵ。
【請求項１０】
請求項９に記載の車載ＥＣＵに接続される車載マスタＥＣＵであって、
他の車載ＥＣＵから構成証明のための情報を取得し、該取得した情報に基づいて、該他の車載ＥＣＵが正当な構成を有していることを証明する構成証明手段を備える、車載マスタＥＣＵ。
【請求項１１】
車載ＥＣＵであって、
他の車載ＥＣＵとの間の共通鍵又は該共通鍵の生成源を記憶する記憶手段と、
自身の車載ＥＣＵが正当な構成を有していることを証明する構成証明を受ける手段と、
前記構成証明を受けたことを表す情報を送信メッセージに付加した送信データを、前記記憶手段に記憶された共通鍵又は該共通鍵の生成源を用いて暗号化して、他の車載ＥＣＵに送信する通信手段とを備える、車載ＥＣＵ。
【請求項１２】
前記共通鍵の生成源は、ＫＰＳ方式の鍵関数である、請求項８、９、及び１１のうちのいずれか１項に記載の車載ＥＣＵ。
【請求項１３】
請求項８、９、及び１１のうちのいずれか１項に記載の車載ＥＣＵ又は請求項１０に記載の車載マスタＥＣＵに実装され、前記各手段の少なくとも１つを実現する耐タンパ性モジュール。
【請求項１４】
車両外部の遠隔位置に配置され車両と通信可能に構成されるセンターサーバであって、請求項８、９、及び１１のうちのいずれか１項に記載の車載ＥＣＵの記憶手段に記憶される共通鍵又は該共通鍵の生成源を生成し、該車載ＥＣＵに送信するセンターサーバ。
【請求項１５】
請求項８、９、及び１１のうちのいずれか１項に記載の車載ＥＣＵと、
車両外部の遠隔位置に配置され車両と通信可能に構成されるセンターサーバであって、前記車載ＥＣＵの記憶手段に記憶される共通鍵又は該共通鍵の生成源を生成し、該車載ＥＣＵに送信するセンターサーバとを備える、暗号通信システム。
【請求項１６】
車両に搭載されるＥＣＵ間の通信を制御する通信制御方法であって、
制御対象となる各ＥＣＵに共通鍵又は該共通鍵の生成源を記憶するステップと、
制御対象となる各ＥＣＵの構成証明を行う構成証明ステップと、
ＥＣＵ間で前記共通鍵又は共通鍵の生成源を用いた共通鍵方式に基づいて暗号通信を行うステップと、
前記構成証明ステップにより構成証明を受けないＥＣＵ間の通信を無効化するステップとを含む、通信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、共通鍵方式の暗号通信技術に関する。
【背景技術】
【０００２】
従来から、ＫＰＳ方式を採用した暗号通信方法において、アルゴリズムの簡素化を図り、回路規模の小規模化を図る暗号通信システムにおける暗号化処理方法が提案されている（例えば、特許文献１参照）。
【特許文献１】特開２０００−２８６８３０公報
【特許文献２】Trusted Computing Group, TPMSpecificationVersion 1.2, https://www.trustedcomputinggroup.org/downloads/specifications
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、近年、車両内の構成部品について電子制御対象となるものが急増している。また、それらをつなぐ通信部分についても標準化されたネットワーク技術の導入が進みつつある。この結果、車両内LANは、一般のオフィスや家庭にあるLAN と類似した姿になりつつある。ここで、車両内LANを悪意ある者による改竄や正当なユーザによる意図しない構成変更による悪影響等から守るためには、車両内に搭載されネットワーク化されているコンピュータノード(ＥＣＵ:Electronic Control Unit)が、製造者によって提供された正しい意図したプログラムで動作していることを保証する仕組み、すなわち構成証明が必要となる。
【０００４】
一般のPCでは、Trusted Computing Groupが提唱したTrusted Platform Module (TPM)を用いた構成証明手法が実用化されている（例えば、非特許文献２参照）。しかしながら、車両内に搭載されるＥＣＵは、一般のPC等に比べて低リソースなものがほとんどであること、msecオーダーといった短時間での応答を要求されるものがあることから、それをそのまま利用することは難しい。
【０００５】
そこで、本発明は、車載環境に適合した態様で構成証明を実現することができるノード間認証(Attestation)方式を用いる暗号通信システム及びこれに用いる車載ＥＣＵ並びに方法等の提供を目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するため、本発明は、互いに通信する少なくとも２つ以上のＥＣＵが搭載される車両に適用される暗号通信システムであって、
前記少なくとも２つ以上のＥＣＵの各ＥＣＵに対して、該各ＥＣＵ間の共通鍵又は該共通鍵の生成源を発行する発行手段と、
前記各ＥＣＵの構成証明を行う構成証明手段とを備え、
前記各ＥＣＵは、前記共通鍵又は共通鍵の生成源を用いた共通鍵方式の暗号により通信を行うと共に、前記構成証明手段により構成証明を受けないＥＣＵとの間で通信を確立しないように構成されることを特徴とする。
【０００７】
本発明において、構成証明手段により構成証明を受けないＥＣＵとの間で通信を確立しないように構成される態様は、任意であり、例えば、構成証明手段により構成証明を受けないＥＣＵからの通信データを破棄してもよいし、構成証明手段により構成証明を受けないＥＣＵがバスマスタにより遮断されることで実現されてもよい。
【０００８】
本発明において、前記発行手段は、車両外部の遠隔位置に配置され車両と通信可能に構成されるセンターサーバに設けられもよい。また、前記構成証明手段は、前記センターサーバに設けられてもよいし、前記構成証明手段は、前記複数のＥＣＵのうちの特定のＥＣＵに設けられてもよいし、前記構成証明手段は、前記各ＥＣＵにそれぞれ設けられてもよい。尚、特定のＥＣＵは、必ずしも１つである必要はなく、前記複数のＥＣＵがＮ個である場合、１個以上、Ｎ−１個以下であればよい。
【０００９】
本発明において、前記共通鍵の生成源は、好ましくは、ＫＰＳ方式の鍵関数である。
【００１０】
本発明による暗号通信システムは、既存のＥＣＵに特定の付加機能を付与したＥＣＵを用いて実現される。例えば、車載ＥＣＵは、他の車載ＥＣＵとの間の共通鍵又は該共通鍵の生成源を記憶する記憶手段と、
前記他の車載ＥＣＵが構成証明を受けたＥＣＵであるか否かを判断する判断手段と、
前記他の車載ＥＣＵが構成証明を受けていないＥＣＵであると判断した場合に、該他の車載ＥＣＵとの通信を無効化する通信無効化手段とを備えるものであってよい。この場合、前記判断手段は、好ましくは、前記他の車載ＥＣＵが車載マスタＥＣＵにより構成証明を受けたＥＣＵであるか否かを判断する。また、前記共通鍵の生成源は、好ましくは、ＫＰＳ方式の鍵関数である。
【００１１】
また、本発明のその他の局面では、車載マスタＥＣＵであって、
他の車載ＥＣＵから構成証明のための情報を取得し、該取得した情報に基づいて、該他の車載ＥＣＵが正当な構成を有していることを証明する構成証明手段を備える、車載マスタＥＣＵが提供される。本発明においても、前記共通鍵の生成源は、好ましくは、ＫＰＳ方式の鍵関数である。
【００１２】
また、本発明のその他の局面では、車載ＥＣＵであって、
他の車載ＥＣＵとの間の共通鍵又は該共通鍵の生成源を記憶する記憶手段と、
自身の車載ＥＣＵが正当な構成を有していることを証明する構成証明を受ける手段と、
前記構成証明を受けたことを表す情報を送信メッセージに付加した送信データを、前記記憶手段に記憶された共通鍵又は該共通鍵の生成源を用いて暗号化して、他の車載ＥＣＵに送信する通信手段とを備える、車載ＥＣＵが提供される。本発明においても、前記共通鍵の生成源は、好ましくは、ＫＰＳ方式の鍵関数である。
【００１３】
上述の本発明による車載ＥＣＵ（車載マスタＥＣＵを含む）は、前記各手段の少なくとも１つを実現する耐タンパ性モジュールを実装することで実現されてもよい。例えば、通常のＥＣＵに、前記各手段の少なくとも１つを実現する耐タンパ性モジュールを実装することで実現されてもよい。
【００１４】
また、本発明のその他の局面では、車両外部の遠隔位置に配置され車両と通信可能に構成されるセンターサーバであって、車載ＥＣＵの記憶手段に記憶される共通鍵又は該共通鍵の生成源を生成し、該車載ＥＣＵに送信するセンターサーが提供される。
【００１５】
また、本発明のその他の局面では、車両に搭載されるＥＣＵ間の通信を制御する通信制御方法であって、
制御対象となる各ＥＣＵに共通鍵又は該共通鍵の生成源を記憶するステップと、
制御対象となる各ＥＣＵの構成証明を行う構成証明ステップと、
ＥＣＵ間で前記共通鍵又は共通鍵の生成源を用いた共通鍵方式に基づいて暗号通信を行うステップと、
前記構成証明ステップにより構成証明を受けないＥＣＵ間の通信を無効化するステップとを含む、通信制御方法が提供される。
【発明の効果】
【００１６】
本発明によれば、車載環境に適合した態様で構成証明を実現することができる暗号通信システム及びこれに用いる車載ＥＣＵ並びに方法等が得られる。
【発明を実施するための最良の形態】
【００１７】
以下、図面を参照して、本発明を実施するための最良の形態の説明を行う。
【実施例１】
【００１８】
図１は、実施例１による暗号通信システム１の主要構成を示す図である。暗号通信システム１は、大きく分類して、車両側のシステム１０と、センターサーバ３０とからなる。センターサーバ３０は、車両とは離れた遠隔位置に設置され、車両側のシステム１０と無線及び／又は有線通信回線を介して通信可能である。センターサーバ３０は、高いセキュリティ性が確保された構成で任意の場所に設置されてよく、例えば情報提供・管理センターのようなセンター施設に設置されてもよいし、それに類する他の施設に設置されてもよい。
【００１９】
車両側のシステム１０では、例えばCAN（controller area network）やFlexRayなどの通信プロトコルに準拠した通信網を介して、車両内の各種のＥＣＵが接続される。
【００２０】
尚、車両内の各種のＥＣＵは、大きく、センサーＥＣＵと、判断・指示ＥＣＵと、アクチュエータＥＣＵとに分類できる。センサーＥＣＵは、車両の状態、周囲環境、あるいはユーザからの(インターフェースデバイスを通じた)指示情報を把握するためのセンサー群であり、判断・指示ＥＣＵは、ユーザからの指示、車両状態、周囲環境の情報に応じて、車両を適切な状態に導くための、何をどのように制御すればいいかを判断する頭脳の役割をするＥＣＵ群であり、アクチュエータＥＣＵは、判断・指示ＥＣＵからの目標値にしたがって、車両を適切な状態にするため、アクチュエータの動作量を目標値になるよう出力・制御するＥＣＵ群である。また、通信デバイスは、外部（センターサーバ３０を含む）からの値の入手(input)と外部への値の伝達(output)の両方の機能を持っており、前者の機能は上記のセンサーＥＣＵに、後者はアクチュエータＥＣＵに分類することが可能である。尚、センサーＥＣＵ、判断・指示ＥＣＵ及びアクチュエータＥＣＵの幾つかが組み合わせて１つのＥＣＵ筐体に組み込まれることもある。
【００２１】
ここで、このような車両側のシステム１０において、偽の情報を自車に車両内通信により与えてあるいは他車に車車間通信により与えて誤った動作をさせることを防止するためには、以下の機能が必要である。
（１）情報の発生源であるセンサーＥＣＵにおいて、取得した値を改竄されることなく車両内ネットワークへ送信すること。
（２）センサーＥＣＵから判断・指示ＥＣＵへの通信においてその値が改竄されないこと。
（３）判断・指示ＥＣＵにおいて、所定のセンサーＥＣＵから情報を入手すること(なりすまされたＥＣＵからの情報を受け取らないこと)。
（４）判断・指示ＥＣＵにおいて、多数のセンサーＥＣＵから得られる情報をもとに、適切にアクチュエータ群に対する指示量を算出できること。
（５）判断・指示ＥＣＵからアクチュエータＥＣＵへの通信においてその値が改竄されないこと。
（６）アクチュエータＥＣＵにおいて、所定の判断・指示ＥＣＵから情報を入手すること(なりすまされたＥＣＵからの情報を受け取らないこと)。
（７）アクチュエータＥＣＵにおいて、指示された量に対して適切にアクチュエータを出力・制御すること。
【００２２】
これらをまとめると、各ＥＣＵにおいて実現すべき、車両内通信におけるセキュリティに必要な機能は、（１）ソフトウェア構成の証明、（２）通信相手の認証、及び、（３）通信の秘匿あるいは改竄防止となる。
【００２３】
また、車両は多くの構成部品から形成されている機能組み合わせ型の製品である。また、走る、止まる、曲がるといったその基本機能を機械部品が動作することで実現していることから、使用にともなう経年劣化が大きい。そのため、予め想定して定期的に、あるいは消耗あるいは故障により不定期に、部品交換を頻繁に行うことによって機能を維持している。このような運用形態を考えると、前段落で述べた機能に加えて、部品交換等への拡張性も考慮することも望ましい。
【００２４】
次に、以上のような機能を実現できる本実施例１の概要を説明する。
【００２５】
車両側のシステム１０には、車両内に従来から存在するＥＣＵ群の他に構成証明のための情報をもつ専用のＥＣＵ:Master AttestationＥＣＵ２０(以下単にマスタＥＣＵ２０という)が導入される。マスタＥＣＵ２０は、予め適切な段階で信頼できるセンターサーバ３０との通信により、自車両に搭載される可能性のある全ＥＣＵの種別とプログラムの全バージョンに関する情報を得て、データベースとして保持する。各ＥＣＵは、起動時に自搭載プログラムのハッシュ値をマスタＥＣＵ２０に報告し、マスタＥＣＵ２０では保有データベースを参照し、それが許可されたバージョンのものであるかを確認する。確認された場合のみ、当該ＥＣＵに対しAttestation Tokenを発行する。各ＥＣＵはデータ送信時に全パケットにおいてAttestation Token を付加し、受信側ＥＣＵではAttestation Tokenを確認できた場合のみ、その通信内容を受理する。
【００２６】
車両側のシステム１０では、各ＥＣＵ間の秘匿通信を実現するにあたって共通鍵方式が利用される。ここで、公開鍵方式の利用も考え得るが、一般に公開鍵方式はより多くの計算リソースを要求するだけでなく、通信の際のパケットが冗長になるという問題がある。そこで、本実施例１では、共通鍵方式が採用される。ところで、共通鍵方式を利用する場合でも、次のような態様が考えられる。
（１）ある1台の車両に対してそれに搭載されるＥＣＵ群に１つの共通鍵
（２）全てのＥＣＵのペアに対し、異なる共通鍵。
尚、（１）を選択した場合、共通鍵が漏洩した場合には、なりすましたＥＣＵを搭載することで、当該車両内のＥＣＵのいずれに対しても誤った情報を送り込むことで誤動作を引き起こすことが可能となるので、好ましくは、（２）が選択される。また、（２）を選択した場合、好ましくは、KPS(Key Predistribution System)が採用される。
【００２７】
［KPS方式の説明］
ここで、簡単にKPSついて説明する。KPS方式は、通信相手の公開情報（例えばMACアドレスやserial
ID等）を元に共通鍵を生成する技術である。共通鍵方式で暗号化および認証を行う場合には、それぞれの利用者（ＥＣＵ）の間で固有の鍵を事前に共有しておく必要があり、n人の利用者（ＥＣＵ）が存在している場合には利用者（ＥＣＵ）は(n−1)個の鍵を保有しておく必要があるが、KPS方式では、共通鍵を生成する鍵関数（秘密鍵）を保持していれば、通信相手毎の鍵を管理する必要がない。KPS方式では、センターサーバ３０と利用者（ＥＣＵ）が存在し、センターサーバ３０が(T+1)×(T+1)の鍵生成行列A={aij}を乱数で生成する。ただし、aij=ajiであり、Tはセキュリティパラメータ（結託閾値）とする。各利用者（ＥＣＵ）kは、センターサーバ３０から利用者（ＥＣＵ）kに固有の鍵関数y=Fk(x)を初期化時に受け取る。この鍵関数y=Fk(x)は鍵生成行列から以下のようにして求められる。ここでqは素数のべき乗である。
【数１】
2010011400.tif 000003
利用者（ＥＣＵ）k1とk2の間の通信に必要なセッションキーKは、互いに相手の識別子であるk1,k2をMACアドレス等から得ることにより、次式より求められる。
K=Fk1(k2)=Fk2(k1)
このようにKPS方式は、通信相手のIDがMACアドレス等から得られる場合に、鍵関数y = Fk(x)を計算することにより直ちに通信相手との共有鍵を求めることができるため、極めて少ない通信オーバーヘッドで鍵を共有することができる。また、利用者（ＥＣＵ）は鍵関数y=Fk(x)を耐タンパ部などに格納してＥＣＵ内で安全に管理する必要があるが、万が一、鍵関数が漏洩したとしても、システム全体の安全性に関わる鍵生成行列が解読されるためには(T+1)個の鍵関数が漏洩する必要があり、T個までの漏洩では他の利用者へのなりすましは情報量的に不可能である。鍵漏洩の台数に関わるセキュリティパラメータTとして大きな数を設定すると、鍵関数の計算により多くの時間を要するが、安全性はTに比例して高まる。
【００２８】
［各ＥＣＵの機能］
各ＥＣＵは、構成証明機能を実現するためにそれぞれのＥＣＵがもともと持つ機能に加えて、
（１）自搭載プログラムのハッシュ値を計算する機能とそれを格納するレジスタ
（２）マスタＥＣＵに搭載されたプログラムのハッシュ値を格納するレジスタ
（３）ＥＣＵがi 番目の場合に、Fi(x)=Fx(i)となる多項式（鍵関数）を格納するレジスタ
（４）内積計算機能
（５）AES(Advanced Encryption
Standard)等の共通鍵暗号の暗号化／復号機能
（６）車両ID、センターサーバ３０との通信に必要な共通鍵の保持(予め規定した値を書き込み、ROMとして保持)を付加機能として有する。この付加部分は、好ましくは、耐タンパ性を有し、攻撃者による改竄、盗聴は不可能である。例えば、各ＥＣＵは、耐タンパ技術（内部回路の隠蔽処理）が施されたICチップを耐タンパ部（図１のTrusted Hardware）として有してよい。
【００２９】
［マスタＥＣＵ２０の機能］
マスタＥＣＵ２０上記の各ＥＣＵと同様の付加機能に加えて、自車に搭載される可能性のある全てのＥＣＵの｛種別、搭載プログラムのバージョン、同ハッシュ値｝のデータベースを保持する。
【００３０】
［センターサーバ３０の機能］
センターサーバ３０は、
（１）各車両それぞれに固有のKPS行列A={aij}の生成
（２）全車両の{車両ID Pi(i=0、1、2、...)、KPS行列A={aij}のデータベース
（３）全ＥＣＵ搭載プログラムの{種別、バージョン、ハッシュ値}のデータベース
（４）全ＥＣＵの{種別、ＥＣＵ毎のserial ID、共有鍵、搭載プログラムのバージョン}のデータベースの機能を持つ。なお、センターサーバ３０と各車両の各ＥＣＵとの間に信頼された通信パスを構築するため、全てのＥＣＵについて、個別の共有鍵を生成し、種別、その種別におけるserial ID、共有鍵をデータベースとして保持するが、このデータはＥＣＵ製造ベンダーにおいて各ＥＣＵ毎に予め乱数を書き込んで出荷し、そのデータを安全な経路で情報提供することを想定する。尚、serial ID及び共有鍵は、好ましくは、各ＥＣＵの耐タンパ部に書き込みされる。また、全ＥＣＵの{種別、ＥＣＵ毎のserial ID、共有鍵、搭載プログラムのバージョン}のデータベースは、バージョンアップ等のような各種の変更に応じて、ＥＣＵ製造ベンダー等からの安全な経路で提供された情報に基づいて、速やかに更新される。
【００３１】
［プロトコルの詳細］
本節では、実際の動作シナリオに沿って、製造時の初期設定、稼動開始時における構成証明、稼働中における認証と秘匿通信、部品交換後の初期設定の各ケースについて、プロトコルの詳細を説明する。なお、ここで下記のように表記する。
{m}k    メッセージmを鍵kでAES-CMAC等を例とする認証付き暗号で作成した暗号文
Sigk(m)    メッセージmに対して、HMAC等を例とする鍵付きハッシュ関数に共通鍵kを用いて得たハッシュ値
H(A)    Aのハッシュ値
Rx    ＥＣＵxが電源投入時に生成する使い捨ての乱数(X=mの時はマスタＥＣＵを示す)
Kx    ＥＣＵxに予め格納するセンターサーバ３０との共通鍵
H(progx)    ＥＣＵxの搭載プログラムの計測されたハッシュ値
Ver(prog)    搭載プログラムのバージョン
Typex    ＥＣＵxの種別
IDx    ＥＣＵxのserial
ID
C    counter
と表記する。
【００３２】
［製造時の初期設定（初期化プロセス）］
製造時の初期設定においては、まずセンターサーバ３０側で、
（１）車両IDに応じてKPS行列A={aij}を生成し、保管し、
（２）該当車両に搭載される可能性のある全ＥＣＵについてＥＣＵ製造ベンダー又は車両メーカーからの情報提供により、{typex、IDx、Kx}のデータベースの準備の準備作業を行った上で、下記に示すプロセスにより、マスタＥＣＵの初期化を行う。
【００３３】
マスタＥＣＵ２０における初期化プロセスは、図２に示すように、以下の通り実行される。
（１）マスタＥＣＵからセンターに、{typem、IDm、Ver(progm)}を送信する（図２のMsg-1参照）。
（２）センターサーバ３０では、受信したtypem、IDmによりデータベースを検索し、該当ＥＣＵとの共有鍵Kmを得る。
（３）センターサーバ３０にて、乱数Rを生成する。そして、生成した乱数Rを元に{R}KmをマスタＥＣＵに送信する（図２のMsg-2参照）。
（４）マスタＥＣＵでは受信した内容を予め保持しているKmで復号し、Rを得る。
（５）マスタＥＣＵでは、搭載プログラムのハッシュ値H(progm)を計測し、{車両ID、H(progm)}Rをセンターサーバ３０へ送信する（図２のMsg-3参照）。
（６）センターサーバ３０では、受信した内容をRで復号する。その結果、車両ID、H(progm)を得て、これを先に届いているtypem、Ver(progm)によりデータベースを検索して得られる値と一致するかを検証する。一致しない場合には応答しない。
（７）センターサーバ３０では、車両IDに対応するKPS行列A={aij}を得て、その中のマスタＥＣＵの鍵生成アルゴリズムFm(x)を以下のように計算し、{Fm(x)}RをマスタＥＣＵへ送信する（図２のMsg-4参照）。
【数２】
2010011400.tif 000004
（８）センターサーバ３０では、さらに、その車両に搭載可能性のある全ての{ＥＣＵ種別、搭載プログラムのバージョン、同ハッシュ値}のリストをRで暗号化して送信する（図２のMsg-5参照）。
（９）マスタＥＣＵでは、受信した内容をRで復号し、Fm(x)、{ＥＣＵ種別、搭載プログラムのバージョン、同ハッシュ値}のリストをデータベースへ格納する。Fm(x)やこのリストは、好ましくは、マスタＥＣＵの耐タンパ部に格納される。但し、このリストは、実装では不揮発メモリに格納されてもよい。
【００３４】
マスタＥＣＵ２０の初期化が完了した後、各ＥＣＵについても、図３に示すように、下記の手順により初期化を行う。
（１）ＥＣＵxは、マスタＥＣＵに対し車両IDを問い合わせする。
（２）マスタＥＣＵは問い合わせに対し車両IDを応答する（図３のMsg-6参照）。
（３）ＥＣＵxは、{typex、IDx、Ver(progx)}をセンターサーバ３０へ送信する（図３のMsg-7参照）。
（４）センターサーバ３０では、受信したtypex、IDxによりデータベースを検索し、ＥＣＵxとの共有鍵Kxを得る。
（５）センターサーバ３０にて、乱数Rxを生成する。そして、生成した乱数RxをKxで暗号化した{Rx}Kxを各ＥＣＵへ送信する（図３のMsg-8参照）。
（６）ＥＣＵxでは受信した内容をKxで復号し、Rxを得る。
（７）ＥＣＵxでは、{車両ID、H(progx)}Rxをセンターサーバ３０へ送信する（図３のMsg-9参照）。
（８）センターサーバ３０では、受信した内容をRxで復号する。その結果、車両ID、H(progx)を得て、typex、Ver(progx)によりデータベースを検索して得られる正規プログラムのハッシュ値と一致するかを検証する。一致しない場合には応答しない。
（９）センターサーバ３０では、車両IDに対応するKPS行列A={aij}を得て、ＥＣＵxの鍵生成アルゴリズムFx(y)を以下のように計算し、{Fx(y)}RxをＥＣＵxへ送信する（図３のMsg-10参照）。
【数３】
2010011400.tif 000005
（１０）さらに、当該車両のマスタＥＣＵの正規プログラムのハッシュ値{H(progm)}Rxを送信する（図３のMsg-11参照）。
（１１）ＥＣＵxでは受信した内容をRxで復号する。そして、{Fx(y)、H(progm)}を格納する。これらの{Fx(y)、H(progm)}は、好ましくは、ＥＣＵxの耐タンパ部に格納される。
【００３５】
以上の初期設定方法によれば、マスタＥＣＵやＥＣＵxが共通鍵KmやKxを有していない場合や、正規プログラム等を実装していない等の場合には、マスタＥＣＵやＥＣＵxに、今後の通信に必要となる鍵生成アルゴリズムFm(x)やFx(y)が供給されないので、車両側のシステム１０の構成の不正な変更等を無効化することができる。
【００３６】
［稼動開始時における構成証明］
稼動開始時、すなわちエンジンキーONによる電源投入時には、図４に示すように、下記のプロセスにより、各ＥＣＵにおいて構成証明が確認される。
（１）マスタＥＣＵmは、乱数R1、R2を生成する。尚、乱数R1、R2に加えて、第３の乱数R3が生成されてもよい。乱数R2は、好ましくは、マスタＥＣＵmの耐タンパ部に格納される。
（２）マスタＥＣＵmは、R1を車内全ＥＣＵへブロードキャストし（図４のMsg-12参照）、各ＥＣＵでは、R1を受信する。尚、このR1のブロードキャストは、ロストの可能性を考慮して、何度か実行されてもよい。また、R1と共に、マスタＥＣＵmのserial ID(IDm)がブロードキャストされてもよい。
（３）各ＥＣＵでは、使い捨ての乱数Rを生成する。
（４）ＥＣＵxでは、搭載プログラムのハッシュ値H(progx)を計測し、マスタＥＣＵに対して署名つきメッセージSigFx(m)(IDx、H(progx)、R1、R)を送信することで構成証明を開始する（図４のMsg-13参照）。
（５）マスタＥＣＵmでは、署名を検証した後、ＥＣＵxの搭載プログラムの計測されたハッシュ値を得る。そして、保持するデータベースを検索し、ＥＣＵxが搭載し得る正規搭載プログラムのハッシュ値リストに入っているかを確認する。これにより構成証明を完了する。
（６）マスタＥＣＵmでは、ＥＣＵxが搭載し得る正規搭載プログラムのハッシュ値リストに入っていることが確認された場合、{ステップ（１）で生成した乱数R2、復号して得たR、計測されたハッシュ値H(progm)}を、Fm(x)で暗号化したメッセージ{R2、R、H(progm)}Fm(x)を、返送する（図４のMsg-14参照）。この際、R2に加えて、第３の乱数R3が返送されてもよい。また、マスタＥＣＵmのserial ID(IDm)が平文で付加されてもよい。他方、ＥＣＵxが搭載し得る正規搭載プログラムのハッシュ値リストに入っていることが確認できない場合、上記の返送が実行されず、この結果、当該ＥＣＵxは構成証明を受けられないことになる。このような構成証明を受けられないＥＣＵxは、例えば故障と判断されてバスマスタにより遮断されることで、他のＥＣＵとの通信が事前に無効化されてもよい。
（７）ＥＣＵxでは、受信したメッセージをFx(m)で復号し、（７ａ）復号して得たH(progm) が初期化時に格納した値と一致していることを検証する。（７ｂ）R2をAttestation
Tokenとして保持する。R2は、好ましくは、ＥＣＵxの耐タンパ部に格納される。また、第３の乱数R3が返送された場合には、counterをｃ＝R3にセットしてもよい。なお、このR1、R2およびRは記録媒体には保存せず、稼動停止時には消滅させ、次の電源投入時に再生成する。
【００３７】
尚、上述の図４に示す初期化プロセスでは、不正のマスタＥＣＵmを考慮しているため、図４のMsg-14において、マスタＥＣＵmのロムのハッシュ値H(progm)が追加されているが、不正のマスタＥＣＵmを考慮しない場合には、H(progm)を送信しない構成も可能である。
【００３８】
［稼働中における認証と秘匿通信の実現］
車両内の通信は、各種の状況に応じて、情報の秘匿/認証、ユニキャスト/ブロードキャストの4種類の態様で実行されてもよい。以下それぞれについて説明する。
【００３９】
（１）署名つき通信（ユニキャスト）
送信側ＥＣＵxでは、{payload、c、SigFx(y)(payload、R2、c)}を受信側ＥＣＵyに送信する。尚、このメッセージには、送信側ＥＣＵxのserial ID（IDx)が平文で付加されてもよい。送信側ＥＣＵxでは、送信後、カウンタをインクリメントする。
【００４０】
受信側ＥＣＵyでは、受信した{payload、c}に、Attestation Tokenとして保持しているR2を付加して共通鍵Fy(x)により署名を計算し、当該計算で得た署名SigFy(x)(payload、R2、c)が、受信したSigFx(y)(payload、R2、c)と一致していることを確認する。一致している場合には、通常通り、例えば受信したメッセージに応答する等して、通信が有効化される。他方、一致していない場合、通信が無効化される。通信の無効化は、例えば受信したメッセージを破棄する（応答しない）ことで実現されてもよい。送信側ＥＣＵx又は受信側ＥＣＵyが構成証明を受けていないＥＣＵである場合には、R2が一致せず、その結果、署名が一致することがないので、当該送信側ＥＣＵxから当該受信側ＥＣＵyへの通信が無効化される。
【００４１】
尚、受信側ＥＣＵyでは、カウンタのチェックを実行してもよい。例えば送信側毎に用意されたカウンタ・テーブルにて受信したcの範囲をチェックしてもよい。例えば、各ＥＣＵは、相手毎に受信用カウンタ・テーブルを有し、メッセージを受信した際に、正常なメッセージであれば送信側ＥＣＵ毎にカウンタを保持する。そして、カウンタのチェックは、例えばCprevious＜Ccurrent＜Cprevious＋２３２を満たすか否かを判断することで、実行されてもよい。このようなカウンタはメッセージのフレッシュネスを保つために有用となる。尚、このようなカウンタのチェックは、後述するその他の通信形態においても、受信側ＥＣＵにおいて同様に実行されてもよい。
【００４２】
（２）秘匿通信（ユニキャスト）
送信側ＥＣＵxでは、{payload、R2、c}Fx(y)を受信側ＥＣＵyに送信する。尚、このメッセージには、送信側ＥＣＵxのserial ID（IDx)が平文で付加されてもよい。
【００４３】
受信側ＥＣＵyでは、受信内容をFy(x)で復号し、R2が保持していたものと一致するかを検証する。これにより、送信側ＥＣＵ又は受信側ＥＣＵが構成証明を受けていないＥＣＵである場合には、R2が一致せず、その結果、受信した内容が復号されないので、当該送信側ＥＣＵから当該受信側ＥＣＵへの通信が無効化される。ただし、受信側ＥＣＵyの耐タンパ部において、初期化プロセスでR2が得られていない状態では、復号処理をしないこととする。
【００４４】
（３）署名つき通信（ブロードキャスト）
送信側ＥＣＵでは、{payload、c、SigR2(payload、c)}を送信（ブロードキャスト）する。尚、このメッセージには、送信側ＥＣＵxのserial ID（IDx)が平文で付加されてもよい。
【００４５】
受信側ＥＣＵでは、受信したpayload、cと、稼動開始時に得たR2によりSigR2(payload、c)を計算し、受信したものと一致しているか確認する。同様に、一致している場合には、受信したpayloadに応答等して、通信が有効化される。他方、一致していない場合、受信したpayloadを破棄等して、通信が無効化される。これにより、送信側ＥＣＵ又は受信側ＥＣＵが構成証明を受けていないＥＣＵである場合には、R2が一致せず、その結果、署名が一致することがないので、当該送信側ＥＣＵから当該受信側ＥＣＵへの通信が無効化される。
【００４６】
（４）秘匿通信（ブロードキャスト）
送信側ＥＣＵでは、{payload、c}R2を送信（ブロードキャスト）する。尚、このメッセージには、送信側ＥＣＵxのserial ID（IDx)が平文で付加されてもよい。
【００４７】
受信側ＥＣＵでは、受信した内容を、稼動開始時に得たR2により復号する。これにより、送信側ＥＣＵ又は受信側ＥＣＵが構成証明を受けていないＥＣＵである場合には、R2が一致せず、その結果、受信した内容が復号されないので、当該送信側ＥＣＵから当該受信側ＥＣＵへの通信が無効化される。ただし、受信側ＥＣＵyの耐タンパ部では、初期化プロセスでR2が得られていない状態では、復号処理をしないこととする。
【００４８】
以上の各種通信においては、稼動開始時に構成証明を受けることによってのみ得られるAttestation Token（上記の例では、R2）を用いて互いを認証し合うので、改竄等により不正ないし不適当な構成を有するＥＣＵを確実に無効化することができる。
【００４９】
次に、ＥＣＵ交換後の初期設定方法について説明する。
【００５０】
マスタＥＣＵ２０以外のＥＣＵ交換が行われた場合には、基本的には、上述の製造時の初期設定と同様の処理を再度実行すればよい。即ち、マスタＥＣＵ以外のＥＣＵを交換する際には、単純に当該ＥＣＵについてのみ、上述の各ＥＣＵにおける初期化プロセスの内容を繰り返せばよい。
【００５１】
マスタＥＣＵを交換する場合には、その中に車両IDを搭載しているため、以下の手順が実行されてもよい。
（１）販売店等を通じて、車両ID
を申告した上で交換用マスタＥＣＵを発注する。
（２）製造者側で同ID をROMに格納した上で、マスタＥＣＵを出荷する。
（３）マスタＥＣＵを交換した上で、上述のマスタＥＣＵにおける初期化プロセスを再実行する。
（４）上述の各ＥＣＵにおける初期化プロセスの内容を全ＥＣＵについて再実行する。
【００５２】
［評価］
本願発明者は、本実施例１の評価のため、TPM方式を用いて同様の機能を実現した場合との比較を行った。両者で最も大きな相違は、本実施例１ではKPSを用いており、TPMはRSAによるPKIを利用していることである。TPMにおいてもっと計算リソースを要求するのは、署名(TPM_ORD_Sign)と復号((TPM_ORD_UnBind)であり、この両者について比較を行った。実験では、16byteのペイロードをIntel Core2Duo1.06GHzを搭載したPCで暗号化および復号する際の時間を比較した。図５に比較結果を示す。ここで、RSA1280は2020年に世界のトップクラスのスーパーコンピュータを用いて1年で解読可能と推測される暗号強度である。一方、T=300は、2020年頃のＥＣＵ数を600と仮定しその半数までのＥＣＵを破壊し鍵生成アルゴリズムを入手しても安全という想定で選択したセキュリティパラメータ値である。図５から、本実施例１の方が、TPMで使用しているRSAに比べて十分に高速であることが容易に読み取れる。
【００５３】
以上の通り、本実施例１によれば、車内通信におけるセキュリティに着目し、一般のPC等で利用されているTPMに比べ低リソースで動作する、車両内のＥＣＵの構成証明に適した手法と、構成が証明されたＥＣＵ間でのみ通信可能となるプロトコルを提供することができる。
【実施例２】
【００５４】
図６は、上述の実施例１と本実施例２の比較図であり、図６（Ａ）は、上述の実施例１の暗号通信システム１のシステム構成の概要を示し、図６（Ｂ）は、本実施例２の暗号通信システム２のシステム構成の概要を示す。実施例２は、マスタＥＣＵ２０が存在せず、その代わりにセンターサーバ３０が構成証明を行う点が、主に上述の実施例１と異なる。以下では、実施例２に特有の構成を重点的に説明するが、他の構成は、適宜、上述の実施例１と同様であってよい。
【００５５】
［製造時の初期設定（初期化プロセス）］
製造時の初期設定においては、まずセンターサーバ３０側で、
（１）該当車両に搭載される全ＥＣＵ間の共通鍵Kを、車両IDに応じて生成し、保管し
（２）該当車両に搭載される可能性のある全ＥＣＵについてＥＣＵ製造ベンダー又は車両メーカーからの情報提供により、{typex、IDx、Kx}のデータベースの準備の準備作業を行う。共通鍵Kは、該当車両に搭載される全ＥＣＵ分の鍵セットであり、例えばKABと記述する場合は、２つのＥＣＵx（X=A,B）間の共通鍵を表す。そして、各ＥＣＵについて、図７に示すように、下記の手順により初期化を行う。
（１）各ＥＣＵxは、{typex、IDx、Ver(progx)}をセンターサーバ３０へ送信する（図７のMsg-21参照）。
（２）センターサーバ３０では、受信したtypex、IDxによりデータベースを検索し、ＥＣＵxとの共有鍵Kxを得る。
（３）センターサーバ３０にて、乱数Rxを生成する。そして、生成した乱数RxをKxで暗号化した{Rx}Kxを各ＥＣＵへ送信する（図７のMsg-22参照）。
（４）各ＥＣＵxでは受信した内容をKxで復号し、Rxを得る。
（５）各ＥＣＵxでは、{車両ID、H(progx)}Rxをセンターサーバ３０へ送信する（図７のMsg-23参照）。
（６）センターサーバ３０では、受信した内容をRxで復号する。その結果、車両ID、H(progx)を得て、typex、Ver(progx)によりデータベースを検索して得られる正規プログラムのハッシュ値と一致するかを検証する。一致しない場合には応答しない。
（７）センターサーバ３０では、車両IDに対応する全ＥＣＵ分の共通鍵Kの暗号{K}RxをＥＣＵxへ送信する（図７のMsg-24参照）。
（８）各ＥＣＵxでは受信した内容をRxで復号する。そして、全ＥＣＵ分の共通鍵Kを格納する。Kは、好ましくは、ＥＣＵxの耐タンパ部に格納される。
【００５６】
以上の初期設定方法によれば、ＥＣＵxが共通鍵Kxを有していない場合や、正規プログラム等を実装していない等の場合には、ＥＣＵxに、今後の通信に必要となる共通鍵Kが供給されないので、車両側のシステム１０の構成の不正な変更等を無効化することができる。
【００５７】
［稼動開始時における構成証明］
稼動開始時、すなわちエンジンキーONによる電源投入時には、図８に示すように、下記のプロセスにより、各ＥＣＵにおいて構成証明が確認される。
（１）センターサーバ３０は、乱数R1、R2、R3を生成する。
（２）センターサーバ３０は、R1を車内全ＥＣＵへブロードキャストし（図８のMsg-25参照）、各ＥＣＵでは、R1を受信する。尚、このR1のブロードキャストは、ロストの可能性を考慮して、何度か実行されてもよい。
（３）各ＥＣＵでは、使い捨ての乱数R4を生成する。
（４）各ＥＣＵxでは、搭載プログラムのハッシュ値H(progx)を計測し、センターサーバ３０に対して署名つきメッセージSigKx(IDx、H(progx)、R1、R4)を送信することで構成証明を開始する（図８のMsg-26参照）。
（５）センターサーバ３０では、署名を検証した後、ＥＣＵxの搭載プログラムの計測されたハッシュ値を得る。保持するデータベースを検索し、ＥＣＵxが搭載し得る正規搭載プログラムのハッシュ値リストに入っているかを確認する。これにより構成証明を完了する。
（６）センターサーバ３０では、ＥＣＵxが搭載し得る正規搭載プログラムのハッシュ値リストに入っていることが確認された場合、{ステップ（１）で生成した乱数R2、R3、及び、復号して得たR4}を、Kxで暗号化したメッセージ{R2、R3、R4}Kxを、返送する（図８のMsg-27参照）。他方、ＥＣＵxが搭載し得る正規搭載プログラムのハッシュ値リストに入っていることが確認できない場合、上記の返送が実行されず、この結果、当該ＥＣＵxは構成証明を受けられないことになる。このような構成証明を受けられないＥＣＵxは、例えばバスマスタにより遮断されることで、他のＥＣＵとの通信が事前に無効化されてもよい。
（７）ＥＣＵxでは、受信したメッセージをKxで復号し、R2をAttestation Tokenとして保持する。R2は、好ましくは、ＥＣＵxの耐タンパ部に格納される。また、counterをｃ＝R3にセットしてもよい。なお、このR1、R2およびR4は記録媒体には保存せず、稼動停止時には消滅させ、次の電源投入時に再生成する。
【００５８】
［稼働中における認証と秘匿通信の実現］
車両内の通信は、各種の状況に応じて、情報の秘匿/認証、ユニキャスト/ブロードキャストの4種類の態様で実行されてもよい。以下それぞれについて説明する。
【００５９】
（１）署名つき通信（ユニキャスト）
送信側ＥＣＵxでは、上述の初期化プロセスで得た受信側ＥＣＵyとの共通鍵Kxyを用いて、{payload、c、SigKxy(payload、R2、c)}を受信側ＥＣＵyに送信する。尚、このメッセージには、送信側ＥＣＵxのserial ID（IDx)が平文で付加されてもよい。送信側ＥＣＵxでは、送信後、カウンタをインクリメントする。
【００６０】
受信側ＥＣＵyでは、受信した{payload、c}に、Attestation Tokenとして保持しているR2を付加して、同様に上述の初期化プロセスで得た共通鍵Kxyにより署名を計算し、受信したSigKxy(payload、R2、c)と一致していることを確認する。一致している場合には、通常通り、例えば受信したメッセージに応答する等して、通信が有効化される。他方、一致していない場合、通信が無効化される。通信の無効化は、例えば受信したメッセージを破棄する（応答しない）ことで実現されてもよい。これにより、送信側ＥＣＵx又は受信側ＥＣＵyが構成証明を受けていないＥＣＵである場合には、R2が一致せず、その結果、署名が一致することがないので、当該送信側ＥＣＵxから当該受信側ＥＣＵyへの通信が無効化される。
【００６１】
尚、受信側ＥＣＵyでは、上述の実施例1と同様、カウンタのチェックを実行してもよい。このようなカウンタのチェックは、後述するその他の通信形態においても、受信側ＥＣＵにおいて同様に実行されてもよい。
【００６２】
（２）秘匿通信（ユニキャスト）
送信側ＥＣＵxでは、{payload、R2、c}Kxyを受信側ＥＣＵyに送信する。尚、このメッセージには、送信側ＥＣＵxのserial ID（IDx)が平文で付加されてもよい。
【００６３】
受信側ＥＣＵyでは、受信内容をKxyで復号し、R2が保持していたものと一致するかを検証する。これにより、送信側ＥＣＵ又は受信側ＥＣＵが構成証明を受けていないＥＣＵである場合には、R2が一致せず、その結果、受信した内容が復号されないので、当該送信側ＥＣＵから当該受信側ＥＣＵへの通信が無効化される。ただし、受信側ＥＣＵyの耐タンパ部では、初期化プロセスでR2が得られていない状態では、復号処理をしないこととする。
【００６４】
（３）署名つき通信（ブロードキャスト）
送信側ＥＣＵでは、稼動開始時に得たR2を用いて、{payload、c、SigR2(payload、c)}を送信（ブロードキャスト）する。尚、このメッセージには、送信側ＥＣＵxのserial ID（IDx)が平文で付加されてもよい。
【００６５】
受信側ＥＣＵでは、受信したpayload、cと、稼動開始時に得たR2によりSigR2(payload、c)を計算し、受信したものと一致しているか確認する。同様に、一致している場合には、受信したpayloadに応答等して、通信が有効化される。他方、一致していない場合、受信したpayloadを破棄等して、通信が無効化される。これにより、送信側ＥＣＵ又は受信側ＥＣＵが構成証明を受けていないＥＣＵである場合には、R2が一致せず、その結果、署名が一致することがないので、当該送信側ＥＣＵから当該受信側ＥＣＵへの通信が無効化される。
【００６６】
（４）秘匿通信（ブロードキャスト）
送信側ＥＣＵでは、稼動開始時に得たR2を用いて、{payload、c}R2を送信（ブロードキャスト）する。尚、このメッセージには、送信側ＥＣＵxのserial ID（IDx)が平文で付加されてもよい。
【００６７】
受信側ＥＣＵでは、受信した内容を、稼動開始時に得たR2により復号する。これにより、送信側ＥＣＵ又は受信側ＥＣＵが構成証明を受けていないＥＣＵである場合には、R2が一致せず、その結果、受信した内容が復号されないので、当該送信側ＥＣＵから当該受信側ＥＣＵへの通信が無効化される。ただし、受信側ＥＣＵyの耐タンパ部では、初期化プロセスでR2が得られていない状態では、復号処理をしないこととする。
【００６８】
以上の各種通信においては、稼動開始時に構成証明を受けることによってのみ得られるAttestation Token（上記の例では、R2）を用いて互いを認証し合うので、改竄等により不正ないし不適当な構成を有するＥＣＵを確実に無効化することができる。
【実施例３】
【００６９】
図９は、実施例３の暗号通信システム３のシステム構成の概要を示す。実施例３は、マスタＥＣＵ２０が存在せず、その代わりに各ＥＣＵ間で構成証明を行う点が、主に上述の実施例１と異なる。以下では、実施例３に特有の構成を重点的に説明するが、他の構成は、適宜、上述の実施例１と同様であってよい。
【００７０】
［製造時の初期設定（初期化プロセス）］
製造時の初期設定においては、まずセンターサーバ３０側で、
（１）該当車両に搭載される全ＥＣＵ間の共通鍵Kを、車両IDに応じて生成し、保管し
（２）該当車両に搭載される可能性のある全ＥＣＵについてＥＣＵ製造ベンダー又は車両メーカーからの情報提供により、{typex、IDx、Kx}のデータベースの準備の準備作業を行う。共通鍵Kは、該当車両に搭載される全ＥＣＵ分の鍵セットであり、例えばKABと記述する場合は、２つのＥＣＵx（X=A,B）間の共通鍵を表す。そして、各ＥＣＵについて、図１０に示すように、下記の手順により初期化を行う。
（１）各ＥＣＵxは、{typex、IDx、Ver(progx)}をセンターサーバ３０へ送信する（図１０のMsg-31参照）。
（２）センターサーバ３０では、受信したtypex、IDxによりデータベースを検索し、ＥＣＵxとの共有鍵Kxを得る。
（３）センターサーバ３０にて、乱数Rxを生成する。そして、生成した乱数RxをKxで暗号化した{Rx}Kxを各ＥＣＵへ送信する（図１０のMsg-32参照）。
（４）各ＥＣＵxでは受信した内容をKxで復号し、Rxを得る。
（５）各ＥＣＵxでは、{車両ID、H(progx)}Rxをセンターサーバ３０へ送信する（図１０のMsg-33参照）。
（６）センターサーバ３０では、受信した内容をRxで復号する。その結果、車両ID、H(progx)を得て、typex、Ver(progx)によりデータベースを検索して得られる正規プログラムのハッシュ値と一致するかを検証する。一致しない場合には応答しない。
（７）センターサーバ３０では、車両IDに対応する全ＥＣＵ分の共通鍵Kの暗号{K}RxをＥＣＵxへ送信する（図１０のMsg-34a参照）。
（８）センターサーバ３０では、さらに、その車両に搭載可能性のある全ての{ＥＣＵ種別、搭載プログラムのバージョン、同ハッシュ値}のリストをRxで暗号化して送信する（図１０のMsg-34b参照）。
（９）各ＥＣＵxでは、受信した内容をRxで復号。{K}、{ＥＣＵ種別、搭載プログラムのバージョン、同ハッシュ値}のリストをデータベースへ格納する。{K}やこのリストは、好ましくは、各ＥＣＵxの耐タンパ部に格納される。但し、このリストは、実装では不揮発メモリに格納されてもよい。
【００７１】
［稼動開始時における構成証明］
稼動開始時、すなわちエンジンキーONによる電源投入時には、図１１に示すように、下記のプロセスにより、各ＥＣＵにおいて構成証明が確認される。ここでは、形式的に、構成証明を受ける側のＥＣＵをＥＣＵxとし、構成証明を行う側のＥＣＵをＥＣＵｙとして説明する。尚、各ＥＣＵは、ＥＣＵx及びＥＣＵｙのいずれとしても機能することができる。
（１）ＥＣＵｙは、乱数R1、R2、R3を生成する。
（２）ＥＣＵｙは、R1を車内全ＥＣＵｘへブロードキャストし（図１１のMsg-35参照）、各ＥＣＵｘでは、R1を受信する。尚、このR1のブロードキャストは、ロストの可能性を考慮して、何度か実行されてもよい。
（３）各ＥＣＵｘでは、使い捨ての乱数R4を生成する。
（４）各ＥＣＵxでは、搭載プログラムのハッシュ値H(progx)を計測し、ＥＣＵｙに対して署名つきメッセージSigKx(IDx、H(progx)、R1、R4)を送信することで構成証明を開始する（図１１のMsg-36参照）。
（５）ＥＣＵｙでは、署名を検証した後、ＥＣＵxの搭載プログラムの計測されたハッシュ値を得る。保持するデータベースを検索し、ＥＣＵxが搭載し得る正規搭載プログラムのハッシュ値リストに入っているかを確認する。これにより構成証明を完了する。
（６）ＥＣＵｙでは、ＥＣＵxが搭載し得る正規搭載プログラムのハッシュ値リストに入っていることが確認された場合、{ステップ（１）で生成した乱数R2、R3、及び、復号して得たR4}を、Kxで暗号化したメッセージ{R2、R3、R4}Kxを、返送する（図１１のMsg-37参照）。他方、ＥＣＵxが搭載し得る正規搭載プログラムのハッシュ値リストに入っていることが確認できない場合、上記の返送が実行されず、この結果、当該ＥＣＵxは構成証明を受けられないことになる。このような構成証明を受けられないＥＣＵxは、例えばバスマスタにより遮断されることで、他のＥＣＵとの通信が事前に無効化されてもよい。
（７）ＥＣＵxでは、受信したメッセージをKxで復号し、R2をＥＣＵｙとの通信用のAttestation Tokenとして保持する。R2は、ＥＣＵｙ毎(即ち自身のＥＣＵ以外の全てのＥＣＵのそれぞれに対して)保持される。R2は、好ましくは、ＥＣＵxの耐タンパ部に格納される。また、counterをｃ＝R3にセットしてもよい。なお、このR1、R2およびR4は記録媒体には保存せず、稼動停止時には消滅させ、次の電源投入時に再生成する。
【００７２】
［稼働中における認証と秘匿通信の実現］
車両内の通信は、各種の状況に応じて、情報の秘匿/認証、ユニキャストの２種類の態様で実行されてもよい。以下それぞれについて説明する。
【００７３】
（１）署名つき通信（ユニキャスト）
送信側ＥＣＵxでは、通信したい相手のＥＣＵyに係るR2を用いて、{payload、c、SigKxy(payload、R2、c)}を受信側ＥＣＵyに送信する。尚、このメッセージには、送信側ＥＣＵxのserial ID（IDx)が平文で付加されてもよい。送信側ＥＣＵxでは、送信後、カウンタをインクリメントする。
【００７４】
受信側ＥＣＵyでは、受信した{payload、c}に、Attestation Tokenとして保持しているR2を付加して共通鍵Kxyにより署名を計算し、受信したSigKxy(payload、R2、c)と一致していることを確認する。一致している場合には、通常通り、例えば受信したメッセージに応答する等して、通信が有効化される。他方、一致していない場合、通信が無効化される。通信の無効化は、例えば受信したメッセージを破棄する（応答しない）ことで実現されてもよい。これにより、送信側ＥＣＵx又は受信側ＥＣＵyが構成証明を受けていないＥＣＵである場合には、R2が一致せず、その結果、署名が一致することがないので、当該送信側ＥＣＵxから当該受信側ＥＣＵyへの通信が無効化される。
【００７５】
尚、受信側ＥＣＵyでは、上述の実施例1と同様、カウンタのチェックを実行してもよい。このようなカウンタのチェックは、後述するその他の通信形態においても、受信側ＥＣＵにおいて同様に実行されてもよい。
【００７６】
（２）秘匿通信（ユニキャスト）
送信側ＥＣＵxでは、通信したい相手のＥＣＵyに係るR2（上述の稼動開始時における構成証明で得たR2）を用いて、{payload、R2、c}Kxyを受信側ＥＣＵyに送信する。尚、このメッセージには、送信側ＥＣＵxのserial ID（IDx)が平文で付加されてもよい。
【００７７】
受信側ＥＣＵyでは、受信内容をKxyで復号し、R2が保持していたものと一致するかを検証する。これにより、送信側ＥＣＵ又は受信側ＥＣＵが構成証明を受けていないＥＣＵである場合には、R2が一致せず、その結果、受信した内容が復号されないので、当該送信側ＥＣＵから当該受信側ＥＣＵへの通信が無効化される。ただし、受信側ＥＣＵyの耐タンパ部では、初期化プロセスでR2が得られていない状態では、復号処理をしないこととする。
【００７８】
以上の各種通信においては、稼動開始時に構成証明を受けることによってのみ得られるAttestation Token（上記の例では、R2）を用いて互いを認証し合うので、改竄等により不正ないし不適当な構成を有するＥＣＵを確実に無効化することができる。
【００７９】
尚、本実施例３において、図１１に示すＥＣＵyに対するＥＣＵxの構成証明は、ＥＣＵxからＥＣＵyへの通信に先立って、通信毎に実行されてもよいし、初回の通信時に一回実行され、以後、稼動が終了されない限り(即ち車両の電源がオフにならない限り)、その後の各通信時には省略されてもよい。また、ＥＣＵyに対するＥＣＵxの構成証明は、ＥＣＵxに対するＥＣＵyの構成証明と同時に実行されてもよい。このような構成証明の態様は、通信を行うペアのＥＣＵ同士で個別に実行されてもよい。
【００８０】
以上、本発明の好ましい実施例について詳説したが、本発明は、上述した実施例に制限されることはなく、本発明の範囲を逸脱することなく、上述した実施例に種々の変形及び置換を加えることができる。
【００８１】
例えば、上述の実施例では、稼動開始時に構成証明が実行されているが、稼動開始時以外の適切なタイミングで構成証明が実行されてもよい。例えば、稼動開始後の所定時間経過毎若しくは車両の所定距離走行毎に構成証明が実行されてもよい。或いは、車両が所定時間以上停止していることが検出された場合等、特定の状況が検出された場合に、構成証明が実行(再実行)されてもよい。
【００８２】
また、上述の実施例１において、マスタＥＣＵ２０は、既存のＥＣＵ（例えばＥＦＩ・ＥＣＵ）の機能を拡張することで実現されてもよい。
【００８３】
また、上述の実施例１では、１つの車両にマスタＥＣＵが１つだけ設定されているが、１つの車両に複数のマスタＥＣＵが設定されてもよい。例えば、マスタＥＣＵは、通信プロトコル毎（例えば高速通信用バスとその他のバス）に設定されてもよいし、情報系システムや走行系システムといったシステムの種類毎に設定されてもよい。
【００８４】
また、上述の実施例では、各ＥＣＵ（マスタＥＣＵ２０を含む）の耐タンパ部が、上述の各種機能を実現しているが、上述の各種機能の一部は、各ＥＣＵの他の構成要素（ＣＰＵやメモリ等）により実現されてもよい。
【００８５】
また、上述の実施例１では、KPS方式が用いられ、実施例２，３では、通常的な共通鍵Ｋを用いているが、逆に、上述の実施例１において、KPS方式に代えて、通常的な共通鍵Ｋを用いてもよいし、実施例２，３において、通常的な共通鍵Ｋに代えて、KPS方式を用いてもよい。更に、上述の実施例１，２，３において、１つの車両に搭載される全てのＥＣＵに対して唯一の共通鍵を用いる構成を採用してもよい。
【図面の簡単な説明】
【００８６】
【図１】実施例１による暗号通信システム１の主要構成を示す図である。
【図２】マスタＥＣＵ２０の初期化プロセスの手順を示す図である。
【図３】各ＥＣＵの初期化プロセスの手順を示す図である。
【図４】稼動開始時における構成証明の手順を示す図である。
【図５】実施例１の評価結果(効果)を示す表図である。
【図６】図６（Ａ）は、実施例１の暗号通信システム１のシステム構成の概要を示し、図６（Ｂ）は、実施例２の暗号通信システム２のシステム構成の概要を示す図である。
【図７】実施例２における各ＥＣＵの初期化プロセスの手順を示す図である。
【図８】実施例２における構成証明の手順を示す図である。
【図９】実施例３の暗号通信システム３の概要を示すシステム構成図である。
【図１０】実施例３における各ＥＣＵの初期化プロセスの手順を示す図である。
【図１１】実施例３における構成証明の手順を示す図である。
【符号の説明】
【００８７】
１，２，３    暗号通信システム
２０    マスタＥＣＵ
３０    センターサーバ
【図１】
2010011400.tif 000006
【図２】
2010011400.tif 000007
【図３】
2010011400.tif 000008
【図４】
2010011400.tif 000009
【図５】
2010011400.tif 000010
【図６】
2010011400.tif 000011
【図７】
2010011400.tif 000012
【図８】
2010011400.tif 000013
【図９】
2010011400.tif 000014
【図１０】
2010011400.tif 000015
【図１１】
2010011400.tif 000016