JP2010011400A - 共通鍵方式の暗号通信システム - Google Patents

共通鍵方式の暗号通信システム Download PDF

Info

Publication number
JP2010011400A
JP2010011400A JP2008171538A JP2008171538A JP2010011400A JP 2010011400 A JP2010011400 A JP 2010011400A JP 2008171538 A JP2008171538 A JP 2008171538A JP 2008171538 A JP2008171538 A JP 2008171538A JP 2010011400 A JP2010011400 A JP 2010011400A
Authority
JP
Japan
Prior art keywords
ecu
vehicle
configuration
common key
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2008171538A
Other languages
English (en)
Inventor
Rei Otsuka
玲 大塚
Rie Shigetomi
利恵 繁富
Akira Yoshioka
顕 吉岡
Makoto Nishikawa
真 西川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
National Institute of Advanced Industrial Science and Technology AIST
Toyota Motor Corp
Original Assignee
National Institute of Advanced Industrial Science and Technology AIST
Toyota Motor Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by National Institute of Advanced Industrial Science and Technology AIST, Toyota Motor Corp filed Critical National Institute of Advanced Industrial Science and Technology AIST
Priority to JP2008171538A priority Critical patent/JP2010011400A/ja
Publication of JP2010011400A publication Critical patent/JP2010011400A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】車載環境に適合した態様で構成証明を実現することができる暗号通信システムの提供。
【解決手段】互いに通信する少なくとも２つ以上のＥＣＵが搭載される車両に適用される暗号通信システムであって、前記少なくとも２つ以上のＥＣＵの各ＥＣＵに対して、該各ＥＣＵ間の共通鍵又は該共通鍵の生成源を発行する発行手段と、前記各ＥＣＵの構成証明を行う構成証明手段とを備え、前記各ＥＣＵは、前記共通鍵又は共通鍵の生成源を用いた共通鍵方式の暗号により通信を行うと共に、前記構成証明手段により構成証明を受けないＥＣＵとの間で通信を確立しないように構成されることを特徴とする。
【選択図】 図１

Description

本発明は、共通鍵方式の暗号通信技術に関する。
従来から、ＫＰＳ方式を採用した暗号通信方法において、アルゴリズムの簡素化を図り、回路規模の小規模化を図る暗号通信システムにおける暗号化処理方法が提案されている（例えば、特許文献１参照）。
特開２０００−２８６８３０公報 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は素数のべき乗である。
Figure 2010011400
 利用者（ＥＣＵ）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参照）。
Figure 2010011400
 （８）センターサーバ３０では、さらに、その車両に搭載可能性のある全ての{ＥＣＵ種別、搭載プログラムのバージョン、同ハッシュ値}のリストを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参照）。
Figure 2010011400
 （１０）さらに、当該車両のマスタＥＣＵの正規プログラムのハッシュ値{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方式を用いてもよい。更に、上述の実施例１，２，３において、１つの車両に搭載される全てのＥＣＵに対して唯一の共通鍵を用いる構成を採用してもよい。
実施例１による暗号通信システム１の主要構成を示す図である。 マスタＥＣＵ２０の初期化プロセスの手順を示す図である。 各ＥＣＵの初期化プロセスの手順を示す図である。 稼動開始時における構成証明の手順を示す図である。 実施例１の評価結果(効果)を示す表図である。 図６（Ａ）は、実施例１の暗号通信システム１のシステム構成の概要を示し、図６（Ｂ）は、実施例２の暗号通信システム２のシステム構成の概要を示す図である。 実施例２における各ＥＣＵの初期化プロセスの手順を示す図である。 実施例２における構成証明の手順を示す図である。 実施例３の暗号通信システム３の概要を示すシステム構成図である。 実施例３における各ＥＣＵの初期化プロセスの手順を示す図である。 実施例３における構成証明の手順を示す図である。
符号の説明
１，２，３ 暗号通信システム
２０ マスタＥＣＵ
３０ センターサーバ

Claims (16)

  1. 互いに通信する少なくとも２つ以上のＥＣＵが搭載される車両に適用される暗号通信システムであって、
    前記少なくとも２つ以上のＥＣＵの各ＥＣＵに対して、該各ＥＣＵ間の共通鍵又は該共通鍵の生成源を発行する発行手段と、
    前記各ＥＣＵの構成証明を行う構成証明手段とを備え、
    前記各ＥＣＵは、前記共通鍵又は共通鍵の生成源を用いた共通鍵方式の暗号により通信を行うと共に、前記構成証明手段により構成証明を受けないＥＣＵとの間で通信を確立しないように構成されることを特徴とする、暗号通信システム。
  2. 前記発行手段は、車両外部の遠隔位置に配置され車両と通信可能に構成されるセンターサーバに設けられる、請求項１に記載の暗号通信システム。
  3. 前記構成証明手段は、前記センターサーバに設けられる、請求項２に記載の暗号通信システム。
  4. 前記構成証明手段は、前記複数のＥＣＵのうちの特定のＥＣＵに設けられる、請求項１又は２に記載の暗号通信システム。
  5. 前記構成証明手段は、前記各ＥＣＵにそれぞれ設けられる、請求項１又は２に記載の暗号通信システム。
  6. 前記共通鍵の生成源は、ＫＰＳ方式の鍵関数である、請求項１〜５のうちのいずれか１項に記載の暗号通信システム。
  7. 請求項１〜６のうちのいずれか１項に記載の暗号通信システムで用いられるＥＣＵ。
  8. 車載ＥＣＵであって、
    他の車載ＥＣＵとの間の共通鍵又は該共通鍵の生成源を記憶する記憶手段と、
    前記他の車載ＥＣＵが構成証明を受けたＥＣＵであるか否かを判断する判断手段と、
    前記他の車載ＥＣＵが構成証明を受けていないＥＣＵであると判断した場合に、該他の車載ＥＣＵとの通信を無効化する通信無効化手段とを備える、車載ＥＣＵ。
  9. 前記判断手段は、前記他の車載ＥＣＵが車載マスタＥＣＵにより構成証明を受けたＥＣＵであるか否かを判断する、請求項８に記載の車載ＥＣＵ。
  10. 請求項９に記載の車載ＥＣＵに接続される車載マスタＥＣＵであって、
    他の車載ＥＣＵから構成証明のための情報を取得し、該取得した情報に基づいて、該他の車載ＥＣＵが正当な構成を有していることを証明する構成証明手段を備える、車載マスタＥＣＵ。
  11. 車載ＥＣＵであって、
    他の車載ＥＣＵとの間の共通鍵又は該共通鍵の生成源を記憶する記憶手段と、
    自身の車載ＥＣＵが正当な構成を有していることを証明する構成証明を受ける手段と、
    前記構成証明を受けたことを表す情報を送信メッセージに付加した送信データを、前記記憶手段に記憶された共通鍵又は該共通鍵の生成源を用いて暗号化して、他の車載ＥＣＵに送信する通信手段とを備える、車載ＥＣＵ。
  12. 前記共通鍵の生成源は、ＫＰＳ方式の鍵関数である、請求項８、９、及び１１のうちのいずれか１項に記載の車載ＥＣＵ。
  13. 請求項８、９、及び１１のうちのいずれか１項に記載の車載ＥＣＵ又は請求項１０に記載の車載マスタＥＣＵに実装され、前記各手段の少なくとも１つを実現する耐タンパ性モジュール。
  14. 車両外部の遠隔位置に配置され車両と通信可能に構成されるセンターサーバであって、請求項８、９、及び１１のうちのいずれか１項に記載の車載ＥＣＵの記憶手段に記憶される共通鍵又は該共通鍵の生成源を生成し、該車載ＥＣＵに送信するセンターサーバ。
  15. 請求項８、９、及び１１のうちのいずれか１項に記載の車載ＥＣＵと、
    車両外部の遠隔位置に配置され車両と通信可能に構成されるセンターサーバであって、前記車載ＥＣＵの記憶手段に記憶される共通鍵又は該共通鍵の生成源を生成し、該車載ＥＣＵに送信するセンターサーバとを備える、暗号通信システム。
  16. 車両に搭載されるＥＣＵ間の通信を制御する通信制御方法であって、
    制御対象となる各ＥＣＵに共通鍵又は該共通鍵の生成源を記憶するステップと、
    制御対象となる各ＥＣＵの構成証明を行う構成証明ステップと、
    ＥＣＵ間で前記共通鍵又は共通鍵の生成源を用いた共通鍵方式に基づいて暗号通信を行うステップと、
    前記構成証明ステップにより構成証明を受けないＥＣＵ間の通信を無効化するステップとを含む、通信制御方法。
JP2008171538A 2008-06-30 2008-06-30 共通鍵方式の暗号通信システム Pending JP2010011400A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008171538A JP2010011400A (ja) 2008-06-30 2008-06-30 共通鍵方式の暗号通信システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008171538A JP2010011400A (ja) 2008-06-30 2008-06-30 共通鍵方式の暗号通信システム

Publications (1)

Publication Number Publication Date
JP2010011400A true JP2010011400A (ja) 2010-01-14

Family

ID=41591277

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008171538A Pending JP2010011400A (ja) 2008-06-30 2008-06-30 共通鍵方式の暗号通信システム

Country Status (1)

Country Link
JP (1) JP2010011400A (ja)

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013524587A (ja) * 2010-03-31 2013-06-17 ローベルト ボツシユ ゲゼルシヤフト ミツト ベシユレンクテル ハフツング 認証された音声暗号化のための方法および装置
JP2013219710A (ja) * 2012-04-12 2013-10-24 Toyota Motor Corp 車載制御装置の認証システム及び車載制御装置の認証方法
JP2014138380A (ja) * 2013-01-18 2014-07-28 Toyota Motor Corp 車両不正状態検出方法、車載システムにおける制御方法、およびシステム
US9132790B2 (en) 2011-07-06 2015-09-15 Hitachi Automotive Systems, Ltd. In-vehicle network system
WO2015186829A1 (ja) * 2014-06-05 2015-12-10 Kddi株式会社 送信ノード、受信ノード、通信ネットワークシステム、メッセージ作成方法およびコンピュータプログラム
WO2015186825A1 (ja) * 2014-06-05 2015-12-10 Kddi株式会社 通信ネットワークシステム、送信ノード、受信ノード、メッセージ検査方法およびコンピュータプログラム
KR101580548B1 (ko) * 2014-07-24 2015-12-28 콘티넨탈 오토모티브 시스템 주식회사 차량용 ecu에 대한 보안 알고리즘 관리 방법
JP2016116075A (ja) * 2014-12-15 2016-06-23 トヨタ自動車株式会社 車載通信システム
JP2016152623A (ja) * 2015-02-18 2016-08-22 ローベルト ボッシュ ゲゼルシャフト ミット ベシュレンクテル ハフツング 操作から保護する方法
JP2016163265A (ja) * 2015-03-04 2016-09-05 Kddi株式会社 鍵管理システム、鍵管理方法およびコンピュータプログラム
WO2017060979A1 (ja) * 2015-10-06 2017-04-13 富士通株式会社 実装ユニット、実装ユニット検証方法及び実装ユニット検証プログラム
CN106603483A (zh) * 2015-10-19 2017-04-26 丰田自动车株式会社 车辆系统和认证方法
JP2017092807A (ja) * 2015-11-13 2017-05-25 株式会社東芝 検査装置、通信システム、移動体および検査方法
JP2017163470A (ja) * 2016-03-11 2017-09-14 日本電気株式会社 暗号通信システム、暗号通信方法、セキュリティチップ、通信装置およびその制御方法と制御プログラム
JP2017532598A (ja) * 2014-09-24 2017-11-02 コーニンクレッカ フィリップス エヌ ヴェＫｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ． 公開鍵暗号化システム
JP2018007049A (ja) * 2016-07-04 2018-01-11 株式会社日立製作所 情報共有システム、計算機、及び、情報共有方法
JP2018026822A (ja) * 2014-06-05 2018-02-15 Kddi株式会社 通信ネットワークシステム及びメッセージ検査方法
JP2018078484A (ja) * 2016-11-10 2018-05-17 Kddi株式会社 再利用システム、鍵生成装置、データ保安装置、車載コンピュータ、再利用方法、及びコンピュータプログラム
JP2018107622A (ja) * 2016-12-26 2018-07-05 トヨタ自動車株式会社 暗号通信システム
JP2018116669A (ja) * 2017-01-13 2018-07-26 株式会社オートネットワーク技術研究所 車載装置、中継装置及びコンピュータプログラム
WO2020145086A1 (ja) * 2019-01-09 2020-07-16 国立大学法人東海国立大学機構 車載通信システム、車載通信制御装置、車載通信装置、通信制御方法及び通信方法
WO2020209248A1 (ja) * 2019-04-12 2020-10-15 株式会社東海理化電機製作所 通信システム及び通信機
JP2021027575A (ja) * 2019-08-06 2021-02-22 プファイファー・ヴァキューム・ゲーエムベーハー 真空装置
JP2021083110A (ja) * 2020-02-19 2021-05-27 ベイジン バイドゥ ネットコム サイエンス テクノロジー カンパニー リミテッドＢｅｉｊｉｎｇ Ｂａｉｄｕ Ｎｅｔｃｏｍ Ｓｃｉｅｎｃｅ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ． 車内電子制御ユニットのアップグレード方法、装置、機器及び車両システム
CN113544671A (zh) * 2019-04-12 2021-10-22 株式会社东海理化电机制作所 通信系统和通信机
JP2022527759A (ja) * 2019-03-25 2022-06-06 マイクロン テクノロジー，インク． 車両の電子制御ユニットの検証
JP7327731B2 (ja) 2019-08-20 2023-08-16 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 車載システムにおけるセキュリティ保護方法およびデバイス

Cited By (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013524587A (ja) * 2010-03-31 2013-06-17 ローベルト ボツシユ ゲゼルシヤフト ミツト ベシユレンクテル ハフツング 認証された音声暗号化のための方法および装置
US9132790B2 (en) 2011-07-06 2015-09-15 Hitachi Automotive Systems, Ltd. In-vehicle network system
DE112012002836B4 (de) * 2011-07-06 2021-07-01 Hitachi Automotive Systems, Ltd. Fahrzeugbasiertes Netzwerksystem
JP2013219710A (ja) * 2012-04-12 2013-10-24 Toyota Motor Corp 車載制御装置の認証システム及び車載制御装置の認証方法
JP2014138380A (ja) * 2013-01-18 2014-07-28 Toyota Motor Corp 車両不正状態検出方法、車載システムにおける制御方法、およびシステム
US10681540B2 (en) 2014-06-05 2020-06-09 Kddi Corporation Communication network system, transmission node, reception node, and message checking method
WO2015186829A1 (ja) * 2014-06-05 2015-12-10 Kddi株式会社 送信ノード、受信ノード、通信ネットワークシステム、メッセージ作成方法およびコンピュータプログラム
WO2015186825A1 (ja) * 2014-06-05 2015-12-10 Kddi株式会社 通信ネットワークシステム、送信ノード、受信ノード、メッセージ検査方法およびコンピュータプログラム
JP2016012917A (ja) * 2014-06-05 2016-01-21 Kddi株式会社 通信ネットワークシステム、送信ノード、受信ノード、メッセージ検査方法およびコンピュータプログラム
JP2016012912A (ja) * 2014-06-05 2016-01-21 Kddi株式会社 送信ノード、受信ノード、通信ネットワークシステム、メッセージ作成方法およびコンピュータプログラム
JP2018026822A (ja) * 2014-06-05 2018-02-15 Kddi株式会社 通信ネットワークシステム及びメッセージ検査方法
KR101580548B1 (ko) * 2014-07-24 2015-12-28 콘티넨탈 오토모티브 시스템 주식회사 차량용 ecu에 대한 보안 알고리즘 관리 방법
JP2017532598A (ja) * 2014-09-24 2017-11-02 コーニンクレッカ フィリップス エヌ ヴェＫｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ． 公開鍵暗号化システム
JP2016116075A (ja) * 2014-12-15 2016-06-23 トヨタ自動車株式会社 車載通信システム
CN105897423A (zh) * 2015-02-18 2016-08-24 罗伯特·博世有限公司 用于操纵保护的方法
JP2016152623A (ja) * 2015-02-18 2016-08-22 ローベルト ボッシュ ゲゼルシャフト ミット ベシュレンクテル ハフツング 操作から保護する方法
JP2016163265A (ja) * 2015-03-04 2016-09-05 Kddi株式会社 鍵管理システム、鍵管理方法およびコンピュータプログラム
WO2017060979A1 (ja) * 2015-10-06 2017-04-13 富士通株式会社 実装ユニット、実装ユニット検証方法及び実装ユニット検証プログラム
JPWO2017060979A1 (ja) * 2015-10-06 2018-07-26 富士通株式会社 実装ユニット、実装ユニット検証方法及び実装ユニット検証プログラム
US10785034B2 (en) 2015-10-06 2020-09-22 Fujitsu Limited Implementation unit, implementation unit verification method, and computer-readable recording medium
CN106603483A (zh) * 2015-10-19 2017-04-26 丰田自动车株式会社 车辆系统和认证方法
JP2017079369A (ja) * 2015-10-19 2017-04-27 トヨタ自動車株式会社 車両システムおよび認証方法
CN106603483B (zh) * 2015-10-19 2020-05-01 丰田自动车株式会社 车辆系统和认证方法
JP2017092807A (ja) * 2015-11-13 2017-05-25 株式会社東芝 検査装置、通信システム、移動体および検査方法
US11070365B2 (en) 2016-03-11 2021-07-20 Nec Corporation Encryption communication system, encryption communication method, security chip, communication apparatus, and control method and control program of communication apparatus
JP2017163470A (ja) * 2016-03-11 2017-09-14 日本電気株式会社 暗号通信システム、暗号通信方法、セキュリティチップ、通信装置およびその制御方法と制御プログラム
JP2018007049A (ja) * 2016-07-04 2018-01-11 株式会社日立製作所 情報共有システム、計算機、及び、情報共有方法
WO2018087963A1 (ja) * 2016-11-10 2018-05-17 Kddi株式会社 再利用システム、鍵生成装置、データ保安装置、車載コンピュータ、再利用方法、及びコンピュータプログラム
US11082228B2 (en) 2016-11-10 2021-08-03 Kddi Corporation Reuse system, key generation device, data security device, in-vehicle computer, reuse method, and computer program
JP2018078484A (ja) * 2016-11-10 2018-05-17 Kddi株式会社 再利用システム、鍵生成装置、データ保安装置、車載コンピュータ、再利用方法、及びコンピュータプログラム
JP2018107622A (ja) * 2016-12-26 2018-07-05 トヨタ自動車株式会社 暗号通信システム
JP2018116669A (ja) * 2017-01-13 2018-07-26 株式会社オートネットワーク技術研究所 車載装置、中継装置及びコンピュータプログラム
JP7132132B2 (ja) 2019-01-09 2022-09-06 国立大学法人東海国立大学機構 車載通信システム、車載通信制御装置、車載通信装置、コンピュータプログラム、通信制御方法及び通信方法
JP2020113852A (ja) * 2019-01-09 2020-07-27 国立大学法人東海国立大学機構 車載通信システム、車載通信制御装置、車載通信装置、コンピュータプログラム、通信制御方法及び通信方法
CN113273144A (zh) * 2019-01-09 2021-08-17 国立大学法人东海国立大学机构 车载通信系统、车载通信控制装置、车载通信装置、通信控制方法及通信方法
WO2020145086A1 (ja) * 2019-01-09 2020-07-16 国立大学法人東海国立大学機構 車載通信システム、車載通信制御装置、車載通信装置、通信制御方法及び通信方法
CN113273144B (zh) * 2019-01-09 2022-10-25 国立大学法人东海国立大学机构 车载通信系统、车载通信控制装置、车载通信装置、通信控制方法及通信方法
JP2022527759A (ja) * 2019-03-25 2022-06-06 マイクロン テクノロジー，インク． 車両の電子制御ユニットの検証
US11870779B2 (en) 2019-03-25 2024-01-09 Micron Technology, Inc. Validating an electronic control unit of a vehicle
WO2020209248A1 (ja) * 2019-04-12 2020-10-15 株式会社東海理化電機製作所 通信システム及び通信機
CN113544671A (zh) * 2019-04-12 2021-10-22 株式会社东海理化电机制作所 通信系统和通信机
JP7465127B2 (ja) 2019-04-12 2024-04-10 株式会社東海理化電機製作所 通信システム及び通信機
JP2021027575A (ja) * 2019-08-06 2021-02-22 プファイファー・ヴァキューム・ゲーエムベーハー 真空装置
JP7327731B2 (ja) 2019-08-20 2023-08-16 ホアウェイ・テクノロジーズ・カンパニー・リミテッド 車載システムにおけるセキュリティ保護方法およびデバイス
JP2021083110A (ja) * 2020-02-19 2021-05-27 ベイジン バイドゥ ネットコム サイエンス テクノロジー カンパニー リミテッドＢｅｉｊｉｎｇ Ｂａｉｄｕ Ｎｅｔｃｏｍ Ｓｃｉｅｎｃｅ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ． 車内電子制御ユニットのアップグレード方法、装置、機器及び車両システム

Similar Documents

Publication Publication Date Title
JP2010011400A (ja) 共通鍵方式の暗号通信システム
JP6454918B2 (ja) 車載コンピュータシステム、車両、管理方法、及びコンピュータプログラム
US10382485B2 (en) Blockchain-assisted public key infrastructure for internet of things applications
CN111010410B (zh) 一种基于证书身份认证的拟态防御系统及证书签发方法
JP5310761B2 (ja) 車両ネットワークシステム
JP5136012B2 (ja) データ送付方法
CN110708388B (zh) 用于提供安全服务的车身安全锚节点设备、方法以及网络系统
WO2009147734A1 (ja) 車両、メンテナンス装置、メンテナンスサービスシステム及びメンテナンスサービス方法
TW201735578A (zh) 受控的安全碼認證
TW201732669A (zh) 受控的安全碼鑑認
CN112448941B (zh) 认证系统和用于认证微控制器的方法
CN106790045B (zh) 一种基于云环境分布式虚拟机代理装置及数据完整性保障方法
JP6192673B2 (ja) 鍵管理システム、鍵管理方法およびコンピュータプログラム
JP5861597B2 (ja) 認証システムおよび認証方法
CN113138775B (zh) 车载诊断系统固件保护方法及系统
US11516194B2 (en) Apparatus and method for in-vehicle network communication
JP2013219710A (ja) 車載制御装置の認証システム及び車載制御装置の認証方法
JP2017011491A (ja) 認証システム
KR102236282B1 (ko) 차량용 통신 데이터 인증 방법 및 시스템
US20220209946A1 (en) Key revocation for edge devices
Giri et al. An integrated safe and secure approach for authentication and secret key establishment in automotive Cyber-Physical systems
WO2017126322A1 (ja) 車載コンピュータシステム、車両、鍵生成装置、管理方法、鍵生成方法、及びコンピュータプログラム
JP6188744B2 (ja) 管理システム、車両及び管理方法
JP2013142963A (ja) 車載制御装置の認証システム
Wolf Vehicular security mechanisms