特許第6052563号(P6052563)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ パナソニックIPマネジメント株式会社の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6052563
(24)【登録日】2016年12月9日
(45)【発行日】2016年12月27日
(54)【発明の名称】端末装置
(51)【国際特許分類】
   H04L 9/32 20060101AFI20161219BHJP
   G09C 1/00 20060101ALI20161219BHJP
   H04L 9/36 20060101ALI20161219BHJP
   H04W 12/04 20090101ALI20161219BHJP
   H04W 4/04 20090101ALI20161219BHJP
【FI】
   H04L9/00 675B
   G09C1/00 640D
   H04L9/00 685
   H04W12/04
   H04W4/04 111
   H04W4/04 113
【請求項の数】2
【全頁数】49
(21)【出願番号】特願2015-254258(P2015-254258)
(22)【出願日】2015年12月25日
(62)【分割の表示】特願2013-163291(P2013-163291)の分割
【原出願日】2012年5月10日
(65)【公開番号】特開2016-136721(P2016-136721A)
(43)【公開日】2016年7月28日
【審査請求日】2015年12月25日
(31)【優先権主張番号】特願2011-105551(P2011-105551)
(32)【優先日】2011年5月10日
(33)【優先権主張国】JP
(31)【優先権主張番号】特願2011-105938(P2011-105938)
(32)【優先日】2011年5月11日
(33)【優先権主張国】JP
(31)【優先権主張番号】特願2011-137865(P2011-137865)
(32)【優先日】2011年6月21日
(33)【優先権主張国】JP
(31)【優先権主張番号】特願2011-236374(P2011-236374)
(32)【優先日】2011年10月27日
(33)【優先権主張国】JP
(73)【特許権者】
【識別番号】314012076
【氏名又は名称】パナソニックIPマネジメント株式会社
(74)【代理人】
【識別番号】100105924
【弁理士】
【氏名又は名称】森下 賢樹
(74)【代理人】
【識別番号】100123102
【弁理士】
【氏名又は名称】宗田 悟志
(72)【発明者】
【氏名】堀 吉宏
【審査官】 脇岡 剛
(56)【参考文献】
【文献】 特開2004−247799(JP,A)
【文献】 特開2001−251296(JP,A)
(57)【特許請求の範囲】
【請求項1】
複数のパケット信号を周期的に報知する無線装置からのパケット信号を受信する受信部と、
前記パケット信号に含まれる公開鍵を含む証明書を検証するための第1検証部と、
前記パケット信号に含まれる公開鍵を用いて当該パケット信号に含まれる署名付きメッセージを検証するための第2検証部と、
前記第1検証部で検証された前記パケット信号に含まれる証明書を特定する情報を保持するダイジェスト保持部と、を備え、
前記ダイジェスト保持部は、前記第1の検証で検証に成功した場合、検証に成功した証明書を特定する情報を保持し、
前記第1検証部は、前記ダイジェスト保持部に保持される証明書を特定する情報によって特定される証明書を含むパケット信号が受信されると、当該パケット信号に含まれる公開鍵を含む証明書の検証をスキップし、
前記第2検証部は、前記第1検証部が検証に成功または検証をスキップし、且つ、前記ダイジェスト保持部に保持される証明書を特定する情報を含む複数のパケット信号のうち、少なくとも1つの当該パケット信号に含まれる署名付きメッセージの検証に成功した場合、その他のパケット信号のうちの少なくとも1つのパケット信号に含まれる署名付きメッセージの検証をスキップすることを特徴とする端末装置。
【請求項2】
前記第2検証部は、当該パケット信号のうちの少なくともひとつのパケット信号の署名付きメッセージの検証をスキップするとき、当該署名付きメッセージを承認と判定することを特徴とする請求項1に記載の端末装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信技術に関し、特に所定の情報が含まれた信号を送受信する端末装置に関する。
【背景技術】
【0002】
自動車向け無線通信の形態は、路車間通信、車車間通信(車路車間通信を含む)に大別される。いずれの通信も、交差点での出会い頭の衝突やコーナー先の渋滞による追突防止などに活用できる。たとえば、車車間通信においてGPS(Global Positioning System)などによって現在の位置情報をリアルタイムに検出し、その位置情報を車載器同士で交換しあうことによって、交差点での衝突防止を図ることができる。路車間通信では、交差点や路側に路側機が設置され、この路側機から車載器に上記のような運転支援情報が送信される。
【0003】
無線通信は有線通信に比較して通信の傍受や第三者のなりすましによる不正な介入が容易であるため、無線通信ではそれらへの対策が有線通信より重要となる。通信内容の秘匿性を確保するには、通信データに対して暗号方式を利用したメッセージ認証を行う手法が有効である。暗号方式には、大別すると公開鍵暗号方式と共通鍵暗号方式がある。前者は後者と比較し、セキュリティは高いがデータ量が多く、かつ、処理負荷が大きいため実装コストが高くなる。すなわち、両者はトレードオフの関係にある。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2005−202913号公報
【特許文献2】特開2007−104310号公報
【特許文献3】特開平8−331075号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
本発明はこうした状況に鑑みてなされたものであり、その目的は、通信システムのセキュリティを効率的に確保するための技術を提供することにある。
【課題を解決するための手段】
【0006】
本発明のある態様の端末装置は、無線装置から報知される複数のパケット信号を受信する受信部と、パケット信号に含まれる公開鍵を含む証明書を検証するための第1検証部と、第1検証部で検証されたパケット信号に含まれる証明書を特定する情報と、公開鍵を保持するダイジェスト保持部と、を備える。第1検証部は、ダイジェスト保持部に保持される証明書を特定する情報によって特定される証明書を含むパケット信号が受信されると、当該パケット信号に含まれる暗号鍵を含む証明書の検証をスキップする。
【0007】
本発明の別の態様の端末装置は、暗号化されたパケット信号を受信する受信部と、パケット信号を復号する復号部と、を備える。パケット信号は、共通鍵暗号方式により暗号化されており、基地局装置から報知されるパケット信号と、他の端末装置から報知されるパケット信号とで異なる運用方式により暗号化される。
【0008】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【0009】
本発明によれば、通信システムのセキュリティを効率的に確保することができる。
【図面の簡単な説明】
【0010】
図1】本発明の実施例1に係る通信システムの構成を示す図である。
図2図2(a)−(d)は、通信システムにおいて規定されるスーパーフレームのフォーマットを示す図である。
図3図3(a)−(b)は、サブフレームの構成を示す図である。
図4図4(a)−(f)は、通信システムにおいて規定される各レイヤのフレームのフォーマットを示す図である。
図5】RSUパケットの具体例を示す図である。
図6】端末装置に4つのRSU用コアが搭載される場合において、各RSU用コアの処理例を示す図である。
図7】RSUパケットに含まれるセキュリティフレームのデータ構造の一例を示す図である。
図8】RSUパケットに含まれるセキュリティフレームのデータ構造の別の例を示す図である。
図9】実施例1に係る基地局装置の構成を示す図である。
図10】実施例1に係る、車両に搭載された端末装置の構成を示す図である。
図11】検証部の構成例1を示す図である。
図12】構成例1に係る検証部が用いられる端末装置のRSUパケットの受信処理を示すフローチャートである。
図13】検証部の構成例2を示す図である。
図14】構成例2に係る検証部が用いられる端末装置のRSUパケットの受信処理を示すフローチャートである。
図15】構成例2に係る検証部が用いられる端末装置の公開鍵証明書の検証処理を示すフローチャートである。
図16】構成例2に係る検証部が用いられる端末装置の電子署名付きメッセージの検証処理を示すフローチャートである。
図17】RSUパケットに含まれるセキュリティフレームのデータ構造の変形例1を示す図である。
図18】RSUパケットに含まれるセキュリティフレームのデータ構造の変形例2を示す図である。
図19】RSUパケットに含まれるセキュリティフレームのデータ構造の変形例3を示す図である。
図20図20(a)−(c)は、RSUパケットに含まれるセキュリティフレームのデータ構造の変形例4を示す図である。
図21図21(a)−(b)は、RSUパケットに含まれるセキュリティフレームのデータ構造の変形例5を示す図である。
図22図22(a)−(c)は、RSUパケットに含まれるセキュリティフレームのデータ構造の変形例6を示す図である。
図23】セキュリティフレームのデータ構造の一例を示す図である。
図24】実施例2に係る基地局装置の構成を示す図である。
図25】実施例2に係る、車両に搭載された端末装置の構成を示す図である。
図26】実施例2に係る通信システムを用いた路車間通信における通常のメッセージ送受信手順を説明するための図である。
図27】実施例2に係る通信システムを用いた路車間通信における路車間マスタ鍵の更新手順を説明するための図である。
図28】路車間通信において生成されるパケットに含まれるセキュリティフレームのデータ構造の一例を示す図である。
図29】実施例2に係る通信システムを用いた車車間通信における通常のメッセージ送受信手順を説明するための図である。
図30】車車間通信において生成されるパケットに含まれるセキュリティフレームのデータ構造の一例を示す図である。
図31】共通鍵テーブルのフォーマットを示す図である。
図32】共通鍵テーブルの運用方法の一例を示す図である。
図33】共通鍵テーブルの追加または更新を説明するための図である。
図34】実施例2に係る通信システムを用いた路車間通信における共通鍵テーブルの追加または更新手順を説明するための図である。
図35図35(a)−(b)は、実施例3に係る、端末装置に保持された共通鍵テーブルを示す図である(その1)。
図36図36(a)−(b)は、実施例3に係る、端末装置に保持された共通鍵テーブルを示す図である(その2)。
図37図37(a)−(b)は、実施例3に係る共通鍵テーブルの切替の様子を示す図である(その1)。
図38図38(a)−(b)は、実施例3に係る共通鍵テーブルの切替の様子を示す図である(その2)。
図39図39(a)−(b)は、実施例3に係る共通鍵テーブルの緊急更新の様子を示す図である。
図40図40(a)−(b)は、実施例3に係る共通鍵テーブルの緊急更新後の切替の様子を示す図である。
図41】実施例3に係る送信用鍵テーブルの第1切替例を示す図である。
図42】実施例3に係る送信用鍵テーブルの第2切替例を示す図である。
図43】実施例3に係る共通鍵テーブルの追加または更新を説明するための図である。
【発明を実施するための形態】
【0011】
(実施例1)
本発明の実施例1の基礎となった知見は、次の通りである。路車間通信では、車車間通信より公共性が強いため、なりすましやデータ改ざんを防ぐ要請がより大きくなると共に、発信元の正当性の確認ができることが望ましいとされる。そこで、路側機(基地局装置)から車載器(端末装置)に、公開鍵証明書および電子署名付きのデータを格納したパケット信号を報知するシステムが検討されている。
【0012】
しかしながら、すべてのパケット信号に含まれる公開鍵証明書および電子署名の検証を実行するには高速な処理が必要となり、端末装置に高速のハードウエアを搭載する必要性が発生する。これらの検証処理には公開鍵暗号方式が用いられるため、演算量が多くなり回路規模が増大する要因となる。
【0013】
実施例1はこうした状況に鑑みてなされたものであり、その目的は、セキュリティを向上させつつ、パケット信号を受信する際の処理負荷を軽減させる技術を提供することにある。
【0014】
実施例1の一態様の概要は、次の通りである。実施例1のある態様の端末装置は、「無線装置」から報知される複数のパケット信号を受信する受信部と、前記パケット信号に含まれる「公開鍵を含む証明書」を検証するための第1検証部と、前記第1検証部で検証された前記パケット信号に含まれる証明書を特定する情報と、公開鍵を保持するダイジェスト保持部と、を備える。前記第1検証部は、前記ダイジェスト保持部に保持される証明書を特定する情報によって特定される証明書を含むパケット信号が受信されると、当該パケット信号に含まれる公開鍵を含む証明書の検証をスキップする。「無線装置」は、基地局装置であってもよいし、端末装置であってもよい。「公開鍵を含む証明書」は、認証局などの第三者により発行される、公開鍵の正当性とその公開鍵の所有主体を結びつけるものである。
【0015】
「公開鍵を含む証明書」をパケット信号に含めることにより、セキュリティを向上させることができる。また、「公開鍵を含む証明書」の検証処理を適宜スキップすることにより処理負荷を軽減できる。
【0016】
前記パケット信号に含まれる署名付きメッセージを検証するための第2検証部と、前記ダイジェスト保持部に保持される証明書を特定する情報によって特定される証明書を含むパケット信号に対する前記第2検証部での検証結果を保持するステータス管理部と、をさらに備えてもよい。前記第2検証部は、前記ダイジェスト保持部に保持される証明書を特定する情報によって特定される証明書を含むパケット信号を検証すると、検証結果を前記ステータス管理部に保持させ、さらに、前記ステータス管理部に検証の成功が保持されている間、当該パケット信号のうちの少なくともひとつのパケット信号の署名付きメッセージの検証をスキップしてもよい。
【0017】
署名付きメッセージをパケット信号に含めることにより、セキュリティを向上させることができる。また、署名付きメッセージの検証処理を適宜スキップすることにより処理負荷を軽減できる。
【0018】
前記第2検証部は、当該パケット信号のうちの少なくともひとつのパケット信号の署名付きメッセージの検証をスキップするとき、当該署名付きメッセージを承認と判定してもよい。これによると、処理負荷をさらに軽減できる。
【0019】
ひとつの無線装置から無線装置信号受信期間に受信される複数のパケット信号のうち、前記証明書が少なくとも無線装置信号受信期間の先頭のパケット信号に含まれていてもよい。前記証明書を特定する特定情報が前記証明書を含まないパケット信号に含まれていてもよい。前記第2検証部は、ひとつの無線装置信号受信期間に受信される複数のパケット信号のうち、先頭のパケット信号に含まれる署名付きメッセージの検証が成功した場合、前記特定情報によって特定される証明書、または、前記特定情報を含む受信したパケット信号の署名付きメッセージの検証をスキップしてもよい。これによると、セキュリティ向上と処理負荷軽減のバランスを図ることができる。
【0020】
ひとつの無線装置から無線信号受信期間に受信される複数のパケット信号のうち、電子署名が少なくとも無線装置信号受信期間の先頭のパケット信号に含まれていてもよい。メッセージ認証コードが少なくとも無線装置信号受信期間の先頭のパケット信号以外のパケット信号に含まれていてもよい。本端末装置は、パケット信号に含まれる電子署名付きメッセージを検証するための第2検証部と、前記パケット信号以外のパケット信号に含まれるメッセージ認証コード付きメッセージを検証するための第3検証部と、をさらに備えてもよい。これによると、セキュリティ向上と処理負荷軽減のバランスを図ることができる。
【0021】
本発明の実施例1を具体的に説明する前に、概要を述べる。本発明の実施例1は、交差点や路側などに設置された基地局装置から車両に搭載された端末装置に、情報を提供するために実行される路車間通信、および車両に搭載された端末装置から他の車両に情報を提供するために実行される車車間通信を用いたITS(Intelligent Transport Systems)などの通信システムに関する。
【0022】
ITSでは、IEEE802.11などの無線LAN規格に類した無線通信を用いることが検討されている。そのような無線通信では、CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)と呼ばれるアクセス制御機能が使用されている。そのため、当該無線通信では、基地局装置および複数の端末装置によって同一の無線チャネルが共有される。このようなCSMA/CAでは、キャリアセンスによって他のパケット信号が送信されていないことを確認した後に、パケット信号がブロードキャストにより送信される(以下、パケット信号のブロードキャストによる送信を「報知」という)。
【0023】
車車間通信として、端末装置は、それが搭載されている車両の速度や位置などを示す車両情報を格納したパケット信号を報知する。そのパケット信号を受信した端末装置は、そのパケット信号に格納された情報をもとに車両の接近などを認識する。また、路車間通信として、基地局装置は、交差点情報および渋滞情報などが格納されたパケット信号を報知する。
【0024】
交差点情報には、交差点の位置情報、基地局装置が設置された交差点の路線情報、撮影画像、交差点内の車両や歩行者の位置情報など、交差点の状況に関する情報が含まれる。端末装置は、この交差点情報をモニタに表示する。また、この交差点情報をもとに交差点の状況を認識し、出会い頭・右折・左折による、車両、自転車、歩行者との衝突防止を目的とした視覚情報あるいは音声メッセージをユーザに通知してもよい。渋滞情報には、基地局装置が設置された走路の混雑状況、道路工事、事故に関する情報が含まれる。端末装置は、この渋滞情報をもとに進行方向の渋滞をユーザに伝達する。また、その渋滞を迂回するための迂回路を提示してもよい。
【0025】
図1は、本発明の実施例1に係る通信システム500の構成を示す。これは、一つの交差点を上方から見た場合に相当する。通信システム500は、基地局装置20、第1車両100aに搭載された端末装置10a、第2車両100bに搭載された端末装置10bを含む。エリア202は基地局装置20の電波圏内を示し、エリア外204は基地局装置20の電波圏外を示す。図面の上側が「北」に対応し、第1車両100aは「南」から「北」に進んでおり、第2車両100bは「東」から「西」に進んでいる。基地局装置20は外部ネットワーク200を介して外部の装置と通信が可能である。
【0026】
図2(a)−(d)は、通信システム500において規定されるスーパーフレームのフォーマットを示す。図2(a)は、スーパーフレームの構成を示す。スーパーフレームは、第1サブフレームから第Nサブフレームと示されるN個のサブフレームによって形成されている。たとえば、スーパーフレームの長さが100msecであり、Nが8である場合、12.5msecの長さのサブフレームが規定される。Nは、8以外であってもよい。
【0027】
図2(b)は、第1基地局装置20aによって生成されるスーパーフレームの構成を示す。第1基地局装置20aは、基地局装置20のうちの任意の一つに相当する。第1基地局装置20aは、第1サブフレームの先頭部分に路車送信期間を設定する。また、第1基地局装置20aは、第1サブフレームにおいて路車送信期間に続いて車車送信期間を設定する。車車送信期間とは、端末装置10がパケット信号を報知する期間である。つまり、第1サブフレームの先頭期間である路車送信期間において第1基地局装置20aは必ずこの期間にパケット信号を報知する。逆に、第1基地局装置20aの電波到達距離内に配置される他の基地局装置20、および、この電波到達距離内にいる端末装置10は、この期間にパケット信号を報知することはない。第1サブフレームの路車送信期間に後続する車車送信期間において端末装置10がパケット信号を報知可能であるように規定される。さらに、第1基地局装置20aは、第2サブフレームから第Nサブフレームに車車送信期間のみを設定する。
【0028】
図2(c)は、第2基地局装置20bによって生成されるスーパーフレームの構成を示す。第2基地局装置20bは、第1基地局装置20aとは異なった基地局装置20に相当する。第2基地局装置20bは、第2サブフレームの先頭部分に路車送信期間を設定する。また、第2基地局装置20bは、第2サブフレームにおける路車送信期間の後段、第1サブフレーム、第3サブフレームから第Nサブフレームに車車送信期間を設定する。
【0029】
図2(d)は、第3基地局装置20cによって生成されるスーパーフレームの構成を示す。第3基地局装置20cは、第1基地局装置20aや第2基地局装置20bとは異なった基地局装置20に相当する。第3基地局装置20cは、第3サブフレームの先頭部分に路車送信期間を設定する。また、第3基地局装置20cは、第3サブフレームにおける路車送信期間の後段、第1サブフレーム、第2サブフレーム、第4サブフレームから第Nサブフレームに車車送信期間を設定する。このように、複数の基地局装置20は、互いに異なったサブフレームを選択し、選択したサブフレームの先頭部分に路車送信期間を設定する。このように、基地局装置20は、自身がパケット信号(情報)を報知するために1つのサブフレームの路車送信期間を独占することで、固有の報知期間をスーパーフレーム内に設けている。スーパーフレーム内に設定可能なサブフレームは有限(本実施例では8個)ではあるが、複数の基地局装置20の電波到達距離を考慮して、スーパーフレームを選択すれば、基地局装置20の設置台数を制限することはない。逆に、スーパーフレーム内のすべてのサブフレームに対して基地局装置20が設置されるものとは限らない。
【0030】
図3(a)−(b)は、サブフレームの構成を示す。図3(a)に示すように、サブフレームは、路車送信期間、車車送信期間の順に構成される。路車送信期間では基地局装置20がパケット信号を報知し、車車送信期間では端末装置10がパケット信号を報知可能である。図3(b)は、路車送信期間におけるパケット信号の配置を示す。図示のごとく、路車送信期間(以下、RSU(Road Side Unit)期間という)において、複数の路車間通信のパケット信号(以下、RSUパケットという)が並べられている。ここで、前後のRSUパケットは、SIFS(Short Interframe Space)だけ離れている。
【0031】
図4(a)−(f)は、通信システム500において規定される各レイヤのフレームのフォーマットを示す。図4(a)は、物理レイヤのフレームフォーマットを示す。図示のごとく、フレームには、PLCPプリアンブル、PLCPヘッダ、PSDU(Physical Layer Service Data Unit)、テールが順に配置される。図4(b)は、MACレイヤのフレームフォーマットを示す。このフレームは、図4(a)のPSDUに格納される。図示のごとく、フレームには、MACヘッダ、MSDU(MAC Layer Service Data Unit)、FCS(Frame Check Sequence)が順に配置される。図4(c)は、LLCレイヤのフレームフォーマットを示す。このフレームは、図4(b)のMSDUに格納される。図示のごとく、フレームには、LLCヘッダ、LSDU(LLC Layer Service Data Unit)が順に配置される。
【0032】
図4(d)は、車車間・路車間共用通信制御情報レイヤのフレームフォーマットを示す。このフレームは、図4(c)のLSDUに格納される。図示のごとく、フレームには、IRヘッダ、APDU(Application Protocol Data Unit)が順に配置される。図4(e)は、セキュリティレイヤのフレームフォーマットを示す。このフレームは、図4(d)のAPDUに格納される。図示のごとく、フレームには、セキュリティヘッダ(Security Header)、ペイロード(Payload)、セキュリティフッタ(Security Footer)が順に配置される。図4(f)は、アプリケーションレイヤのフレームフォーマットを示す。このフレームは、図4(e)のペイロードに格納されており、アプリケーションデータによって構成される。以下では、MACレイヤのフレームをMACフレームといい、セキュリティレイヤのフレームをセキュリティフレームという。また、フレームフォーマットをデータ構造という。
【0033】
図5は、N=4とし、1つのRSU期間を1台の基地局装置20が占有して使用する場合のRSUパケットの具体例を示す。本具体例は、相互に電波到達範囲が重なる基地局装置20が最大4台設置可能とする場合で、スーパーフレーム期間(本具体例では100msec)に4つのRSU期間が存在する。本具体例では、1つのRSU期間に7つのRSUパケットが送信される。各RSUパケットのセキュリティフレームは、セキュリティヘッダ、アプリケーションデータを格納するペイロード、セキュリティフッダで構成される。ヘッダには公開鍵証明書が格納され、フッダには電子署名が格納される。なお、セキュリティフレームより下位レイヤのヘッダは省略して描いている。本具体例では、スーパーフレーム期間に、端末装置10は最大4台の基地局装置20から、すなわち4つのサブフレームに配置された4つのRSU期間に対して、RSUパケットを処理する機能が必要となる。ここで、端末装置10は保持する各RSU期間に対するRSUパケットの処理系をRSUパケット用コアと呼ぶ。よって、本具体例に対応した端末装置10は4つのRSU用コアを備えている。なお、公開鍵暗号方式による署名検証に用いる検証処理機能はRSUパケット用コア毎に配置してもよいし、複数のRSUパケット用コアで共有してもよい。
【0034】
図6は、端末装置10に4つのRSU用コア(RSU1用コア〜RSU4用コア)が搭載される場合において、各RSU用コアの処理例を示す。図6では車両100が「西」から「東」に進行する。車両100が通過するエリアの近傍には、5つの基地局装置(以下、路側機ともいう)(図6では第1基地局装置20a、第2基地局装置20b、第3基地局装置20c、第4基地局装置20d、第5基地局装置20e)が設置されている。
【0035】
図6において、期間TvはRSU用コアが処理を停止している期間を示し、期間Tcは公開鍵証明書の検証を実行している期間を示し、期間Tmは電子署名付きメッセージの検証を実行している期間を示す。また、円は、各基地局装置20の電波圏内を示し、各円内のRSU1〜RSU4は、それぞれが図5のRSU期間1〜RSU期間4を利用していることを示している。車両100が第1基地局装置20aの電波圏内に入ると、RSU1用コアは、第1基地局装置20aから報知されるRSUパケットの公開鍵証明書の検証を実行する。その公開鍵証明書の検証が成功すると、RSUパケットの電子署名付きメッセージの検証を実行する。車両100が第1基地局装置20aの電波圏外に出ると、第1基地局装置20aから報知されるRSUパケットの検証処理を終了する。その後、車両100が第5基地局装置20eの電波圏内に入ると、RSU1用コアは、第5基地局装置20eから報知されるRSUパケットの公開鍵証明書の検証を実行する。その公開鍵証明書の検証が成功すると、RSUパケットの電子署名付きメッセージの検証を実行する。車両100が第5基地局装置20eの電波圏外に出ると、第5基地局装置20eから報知されるRSUパケットの検証処理を終了する。RSU2用コア〜RSU4用コアも、RSU1用コアと同様の処理を実行する。
【0036】
図7は、RSUパケットに含まれるセキュリティフレームのデータ構造の一例を示す。このデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ID」、「nonce」、「データ長」および「公開鍵証明書」が配置され、その後に「ペイロード」が配置され、最後にセキュリティフッダとして「電子署名」が配置される。この例では、暗号対象は「公開鍵証明書」、「ペイロード」および「電子署名」であり、署名対象は「ペイロード」である。
【0037】
「バージョン」はフレームフォーマットのバージョンを示す。「メッセージ形式」はメッセージ形式を指定する。メッセージ形式には、平文データ形式、認証付きデータ形式および認証付き暗号化データ形式がある。
【0038】
「鍵ID」は基地局装置20と端末装置10間で共有されている通信鍵を識別するための情報である。データ形式が認証付き暗号化データ形式である場合、当該通信鍵で「公開鍵証明書」、「ペイロード」および「電子署名」が暗号化される。当該通信鍵には、事前に共有された共通鍵暗号方式の共通鍵で、たとえば、AES(Advanced Encryption Standard)鍵を用いることができる。図7の例では、CTR(CounTeR)モードにより暗号化される。
【0039】
「nonce」は、通信鍵を用いた暗号化において暗号結果を攪乱するために用いる通信毎にユニークな値または、その一部がセットされる。この値は乱数であってもよいし、送信時刻であってもよい。さらに、乱数または送信時刻に発信元の機器IDが追加されてもよい。「nonce」に、送信時刻のみをセットした場合には、通信毎に使用するユニークな値として、「nonce」にセットした送信時刻と基地局装置20の固有値、たとえば、公開鍵証明書に含まれるシリアル番号、あるいは機器IDを用いて通信毎にユニークな値として利用する。なお、「nonce」に乱数をセットした場合であっても、「nonce」にセットした乱数と、基地局装置20の固有値を通信毎にユニークな値として利用してもよい。「データ長」は暗号対象のデータのデータ長(より具体的にはバイト数)を設置する。なお、「公開鍵証明書」のデータ長が固定長であるならば、「ペイロード」のデータ長をセットしてもよい。
【0040】
「公開鍵証明書」は基地局装置20に固有の公開鍵に対する公開鍵証明書をセットする。公開鍵証明書は公開鍵とその公開鍵の所有主体を結びつける証明書である。公開鍵証明書には、署名者の識別情報、機器ID(公開鍵証明書の識別情報)、有効期限、公開鍵(鍵生成アルゴリズム、サイズなどを含む)、署名者の署名などが含まれる。本実施例では、署名者は認証局(CA:Certificate Authority)とする。当該署名は、たとえば、RSA、DSA(Digital Signature Algorithm)、ECDSA(Elliptic Curve−DSA)などの公開鍵暗号方式により生成される。本実施例ではECDSAを採用する。
【0041】
「電子署名」には、「ペイロード」に対する署名がセットされる。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。なお、「電子署名」に署名がセットされるのは、データ形式が、認証付きデータ形式、または、認証付き暗号化データ形式の時である。認証付き暗号化データ形式の時は、「電子署名」に署名をセットした後、「公開鍵証明書」、「ペイロード」、「電子署名」は暗号化される。
【0042】
図8は、RSUパケットに含まれるセキュリティフレームのデータ構造の別の例を示す。図8に示すデータ構造は、図7に示すデータ構造と比較し、「公開鍵証明書」を暗号対象としない。これに伴い、「公開鍵証明書」が「データ長」より前に配置される。図8に示すデータ構造では、「公開鍵証明書」が「nonce」の直前に配置される。以下では、図7のセキュリティフレームのメッセージ形式を認証付き暗号化データ形式とした場合の処理について記載する。また、メッセージ形式を認証付きデータ形式とした場合、暗号化および復号に関する処理を省くだけである。メッセージ形式を平文データ形式とした場合には、さらに署名の生成および検証を省くのみである。この時、セキュリティフッダの「電子署名」にどんな値をセットしてもよい。さらには、セキュリティフッダを省略するようにしてもよい。また、図8のセキュリティフレームでは、メッセージ形式を認証付きデータ形式とした場合に、「公開鍵証明書」を暗号対象から外すだけである。図7では、「公開鍵証明書」、「ペイロード」および「電子署名」が暗号化される。図8では「ペイロード」および「電子署名」が暗号化されるとしたが、情報を秘匿し、情報の流失を防ぐには、少なくとも「ペイロード」が暗号化されていればよい。
【0043】
図9は、実施例1に係る基地局装置20の構成を示す。基地局装置20は、アンテナ21、RF部22、変復調部23、MACフレーム処理部24、セキュリティ処理部25、データ生成部26、ネットワーク通信部27、記憶部28および制御部29を備える。セキュリティ処理部25は署名部251と、暗号部252を含む。
【0044】
MACフレーム処理部24、セキュリティ処理部25、データ生成部26、ネットワーク通信部27、記憶部28および制御部29の構成は、ハードウエア的には、任意のプロセッサ、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【0045】
RF部22は、受信処理として、端末装置10および他の基地局装置20からのパケット信号をアンテナ21にて受信する。RF部22は、受信した無線周波数のパケット信号に対して周波数変換を実行し、ベースバンドのパケット信号を生成する。RF部22は、ベースバンドのパケット信号を変復調部23に出力する。一般的に、ベースバンドのパケット信号は、同相成分と直交成分によって形成されるため、二つの信号線が示されるべきであるが、図を簡略化するため、図9では一つの信号線だけを示している。RF部22は、受信系の構成要素として、図示しないLNA(Low Noise Amplifier)、ミキサ、AGC、A/D変換部などを含む。
【0046】
RF部22は、送信処理として、生成したパケット信号を基地局装置20から送信する。RF部22は、変復調部23から入力されるベースバンドのパケット信号に対して周波数変換を実行し、無線周波数のパケット信号を生成する。RF部22は、自身に割り当てられたRSU期間において、無線周波数のパケット信号をアンテナ21から送信する。RF部22は、送信系の構成要素として、図示しないPA(Power Amplifier)、ミキサ、D/A変換部などを含む。
【0047】
変復調部23は、受信処理として、RF部22からのベースバンドのパケット信号に対して、復調を実行する。変復調部23は、復調して得たデジタルデータを、MACフレーム処理部24に出力する。また、変復調部23は、送信処理として、MACフレーム処理部24からのMACフレームに対して、変調を実行する。変復調部23は、変調した結果をベースバンドのパケット信号としてRF部22に出力する。
【0048】
本実施例に係る通信システム500では、OFDM(Orthogonal Frequency Division Multiplexing)変調方式を採用する。この場合、変復調部23は受信処理としてFFT(Fast Fourier Transform)を実行し、送信処理としてIFFT(Inverse Fast Fourier Transform)を実行する。
【0049】
MACフレーム処理部24は、受信処理として、変復調部23からのデジタルデータから、MACフレームを取り出し、取り出したMACフレームから、セキュリティフレームを取り出し、セキュリティ処理部25に出力する。また、MACフレーム処理部24は、送信処理として、セキュリティ処理部25からのセキュリティフレームに対して、MACヘッダ、LLCヘッダおよびIR情報ヘッダを付加し、MACフレームを生成し、変復調部23に出力する。また、他の基地局装置20または端末装置10からのパケット信号が衝突しないようパケット信号の送受信タイミングを制御する。
【0050】
ネットワーク通信部27は、外部ネットワーク200に接続される。ネットワーク通信部27は、外部ネットワーク200から工事や渋滞などに関する道路情報を受けつける。
【0051】
また、ネットワーク通信部27は、セキュリティ処理部25による処理結果を外部ネットワーク200へ出力したり、記憶部28に蓄積して、定期的に外部ネットワーク200へ出力したりする。データ生成部26は、アプリケーションデータを生成する。たとえば、アプリケーションデータに道路情報をセットする。そして、アプリケーションデータの内容によって、データ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部25に出力する。記憶部28は、種々の情報を記憶する。制御部29は、基地局装置20全体の処理を制御する。
【0052】
セキュリティ処理部25は、セキュリティフレームを生成または解釈する。本実施例では、基地局装置20からのパケット送信に注目するため、セキュリティフレームを生成する処理に注目する。セキュリティ処理部25は、MACフレーム処理部24に出力すべきセキュリティフレームを、データ生成部26から受け取ったアプリケーションデータ、認証局から受け取った秘密鍵、公開鍵証明書などを利用して生成する。
【0053】
セキュリティ処理部25は、署名部251および暗号部252を含む。署名部251は、本実施例では図示しない認証局が発行する秘密鍵と、この秘密鍵と対をなす公開鍵を含む公開鍵証明書を内部に記憶している。この秘密鍵と公開鍵証明書は、基地局装置20に固有とすることで、共通鍵暗号方式に比べてセキュリティを高くすることができる。署名部251は、自身が保持する秘密鍵を用いて、署名対象に対する署名を生成する。暗号部252は、暗号対象を端末装置10と共有している通信鍵を用いて暗号化する。図7に示すデータ構造では、「公開鍵証明書」、「ペイロード」および「電子署名」を暗号化する。
【0054】
図10は、実施例1に係る、車両100に搭載された端末装置10の構成を示す。端末装置10は、アンテナ11、RF部12、変復調部13、MACフレーム処理部14、セキュリティ処理部15、受信処理部161、通知部162、データ生成部17、記憶部18および制御部19を備える。セキュリティ処理部15は、検証部151および復号部152を含む。
【0055】
MACフレーム処理部14、セキュリティ処理部15、受信処理部161、通知部162、データ生成部17、記憶部18および制御部19の構成は、ハードウエア的には、任意のプロセッサ、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【0056】
アンテナ11、RF部12、変復調部13およびMACフレーム処理部14は、図9のアンテナ21、RF部22、変復調部23およびMACフレーム処理部24の構成および動作は基本的に共通する。以下、これらの構成要素については、相違点を中心に説明する。
【0057】
受信処理部161は、セキュリティ処理部15から受け取ったデータと、データ生成部17から受け取った自車の車両情報にもとづき、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また、データが画像情報であれば通知部162に表示するよう処理する。
【0058】
通知部162は、図示しないモニタ、ランプ、スピーカなどのユーザへの通知手段を含む。受信処理部161からの指示にしたがって、図示しない他の車両の接近などを当該通知手段を介して運転者に通知する。また、渋滞情報、交差点などの画像情報などをモニタに表示する。
【0059】
データ生成部17は、図示しないGPS受信機、ジャイロスコープ、車速センサなどから供給される情報にもとづき、端末装置10が搭載された車両100の現在位置、進行方向、移動速度などを特定する。なお、現在位置は、緯度・経度によって示される。これらの情報の特定方法は一般的な公知の技術により実現可能であるため、ここでは説明を省略する。データ生成部17は、特定した情報をもとに他の端末装置10や基地局装置20に報知すべきデータを生成し、セキュリティ処理部15に出力する。また、特定した情報を受信処理部161に自車の車両情報として出力する。記憶部18は、種々の情報を記憶する。制御部19は、端末装置10全体の処理を制御する。
【0060】
セキュリティ処理部15は、セキュリティフレームを生成または解釈する。本実施例では、基地局装置20からのパケット受信に注目するため、そのパケット信号に格納されたセキュリティフレームを解釈する処理に注目する。セキュリティ処理部15は、検証部151および復号部152を含む。復号部152は、セキュリティフレームの「鍵ID」により特定される通信鍵を用いて、暗号対象を復号する。図7に示すデータ構造では、「公開鍵証明書」、「ペイロード」および「電子署名」を復号する。検証部151は「公開鍵証明書」および「電子署名」を検証する。なお、検証部151は公開鍵証明書を検証するために、本実施例では図示しない認証局が発行する公開鍵証明書を検証する認証鍵を内部に記憶している。この認証鍵は、認証局において公開鍵証明書の署名を生成するのに用いた秘密鍵と対をなす公開鍵である。
【0061】
図11は、検証部151の構成例1を示す。構成例1に係る検証部151は、証明書検証部151a、メッセージ検証部151b、ダイジェスト保持部151c、認証鍵保持部151dを含む。構成例1では、各RSU用コアにおける単位RSU期間に受信されたRSUパケットの公開鍵証明書または電子署名付きメッセージの検証を、スーパーフレーム期間内に終了させる公開鍵の署名検証処理能力を検証部151が持っていることを前提とする。
【0062】
ダイジェスト保持部151cは、証明書検証部151aによる検証が成功した公開鍵証明書のダイジェスト、公開鍵、機器IDを保持する。説明の便宜上、これらの情報をまとめてRSU検証情報と呼ぶ。ダイジェスト保持部151cは、各RSU期間(サブスロット)毎にRSU検証情報を保持する。すなわち、RSU用コアの数だけRSU検証情報を保持する。公開鍵証明書のダイジェストとして、ここでは公開鍵証明書に含まれる署名を当てるとするが、以下の処理では、証明書の全体あるいは一部のハッシュ値、公開鍵または/かつ公開鍵証明書に含まれる署名、機器ID(公開鍵証明書の識別番号)をダイジェストの代用としてもよい。すなわち証明書を特定できる情報であれば、いずれであってもよい。このようにするとダイジェスト保持部151cに保持するデータ量が削減される。なお、RSU検証情報は、少なくとも検証に成功した公開鍵証明書を特定できればよいので、公開鍵証明書のダイジェスト、公開鍵、機器ID、公開鍵証明書の識別番号の全てを必ずしも必要とはしないし、これらに限定する必要はない。公開鍵証明書から取得できる情報であればいずれであっても構わない。ステータスは、当該RSU期間における検証の状態を表す状態情報である。認証鍵保持部151dは、証明書検証部151aによって公開鍵証明書を検証するための認証鍵を保持する。
【0063】
証明書検証部151aは、基地局装置20から報知されるパケット信号に含まれる公開鍵証明書に含まれる署名を、認証鍵保持部151dに保持される認証鍵を用いて検証する。この認証鍵は予め組み込まれていてもよいし、安全な手段で事後的に取得し、認証鍵保持部151dに保持したものであってもよい。
【0064】
公開鍵証明書に含まれる署名に対する検証が成功すれば、当該公開鍵証明書に含まれる基地局装置20が生成した公開鍵は、当該認証局により証明された真性なものであると推定できる。しかしながら、この署名には公開鍵暗号方式(本実施例ではECDSA)が用いられるため、すべてのRSUパケットにおいて公開鍵証明書の検証を実行すると処理負荷が増大する。そこで、公開鍵証明書の検証を適宜、スキップする。
【0065】
以下では特に断りがない限り、ダイジェスト保持部151cにRSU検証情報に関する処理はパケット信号を受信したRSU期間に対応するRSU検証情報に対する処理である。証明書検証部151aは、基地局装置20から報知されるパケット信号を受信すると、そのRSUパケットに含まれる公開鍵証明書から取り出したダイジェストと、ダイジェスト保持部151cに保持されるダイジェストとの比較をする。両者が異なる場合、証明書検証部151aは当該パケット信号に含まれる公開鍵証明書の検証を実行する。公開鍵証明書の検証が成功した場合、ダイジェスト保持部151cに保持されるRSU検証情報を検証した公開鍵証明書のものに更新する。公開鍵証明書の検証が失敗した場合、処理を終了する。両者が対応(より厳密には、一致)する場合、当該パケット信号に含まれる公開鍵証明書の検証をスキップする。すなわち、正式な検証を実行せずに公開鍵証明書のダイジェストの一致をもって検証成功とみなす。これは、公開鍵証明書のダイジェストあるいは、公開鍵や機器IDが一致している間は、同一の基地局装置20から報知されたパケット信号と推定できるためである。すなわち、ある基地局装置20から報知されたパケット信号に含まれる公開鍵証明書の検証が一度成功すれば、その基地局装置20から報知される後続のパケット信号の信頼性は高いと判断できる。なお、メッセージ検証では、ダイジェスト保持部151cに保持されている公開鍵と機器IDを利用して、メッセージの検証処理を実行する。受け取ったRSUパケットに含まれる公開鍵証明書から、公開鍵や機器IDを取得しないのは、公開鍵証明書の改ざん攻撃に対抗するためである。
【0066】
メッセージ検証部151bは、証明書検証部151aにおいて公開鍵証明書の検証が成功した場合、または、認証をスキップした場合、基地局装置20から報知されるパケット信号に含まれる認証付きメッセージを検証する。検証には、ダイジェスト保持部151cに保持されている公開鍵と機器IDを用いる。本実施例では電子署名付きメッセージ形式における「ペイロード」の完全性と真正性の検証をする。電子署名付き暗号化メッセージ形式では、暗号を解いた(復号した)後、同様な処理を行う。この電子署名は、当該パケット信号に含まれる公開鍵証明書に格納される公開鍵と対をなす秘密鍵により生成されているため、当該公開鍵を用いた当該電子署名付きメッセージに対する検証が成功すれば、当該メッセージは基地局装置20により生成された完全かつ真正なものであるとすることができる。
【0067】
しかしながら、この電子署名にも公開鍵暗号方式(本実施例ではECDSA)が用いられるため、すべてのRSUパケットにおいて電子署名付きメッセージの検証を実行すると処理負荷が増大する。そこで、検証部151の処理能力に応じて、電子署名付きメッセージの検証を適宜、スキップする。なお、RSUパケットの数が少ない場合や、処理能力に余裕がある場合、すべての電子署名付きメッセージの検証を実行してもよい。検証部151の処理能力はハードウエアの規模やスペックを増大させるほど向上するため、データの信頼性と回路規模はトレードオフの関係となる。
【0068】
メッセージ検証部151bは、ダイジェスト保持に151cに保持されるステータスが「メッセージ検証済」であり、公開鍵証明書のダイジェストが対応(より厳密には、一致)しているパケット信号が受信されている間、当該パケット信号のうちの少なくともひとつのパケット信号の電子署名付きメッセージの検証をスキップする。たとえば、公開鍵証明書のダイジェストが一致している複数のパケット信号について、当該複数のパケット信号に含まれる少なくともひとつ(たとえば、先頭のパケット信号)の電子署名付きメッセージの検証が成功すると、その他のパケット信号に含まれる電子署名付きメッセージを検証することなく、当該電子署名付きメッセージを承認と判定してもよい。
【0069】
より具体的には、メッセージ検証部151bは、同じサブフレームのRSU期間に受信される複数のパケット信号のうち、先頭のパケット信号に含まれる電子署名付きメッセージの検証が成功し、かつパケット信号以外の任意のひとつのパケット信号に含まれる電子署名付きメッセージの検証が成功した場合、当該RSU期間に受信されるすべてのパケット信号に含まれる電子署名付きメッセージを承認と判定してもよい。
【0070】
図12は、構成例1に係る検証部151が用いられる端末装置10のRSUパケットの受信処理を示すフローチャートである。RF部12はRSUパケットを受信する(S10)。このRSUパケットは変復調部13、MACフレーム処理部14を経て、セキュリティ処理部15に出力される。証明書検証部151aは、ダイジェスト保持部151cに保持される公開鍵証明書のダイジェストと、受信されたRSUパケットに含まれる公開鍵証明書のダイジェストを比較し、一致するか否か判定する(S11)。
【0071】
ダイジェストが一致しない場合(S11のN)、証明書検証部151aは受信されたRSUパケットに含まれる公開鍵証明書に格納される署名を検証する(S12)。なお、ダイジェストが一致しない場合は初期状態や基地局装置20が切り替わったときに発生する。
【0072】
当該検証が成功した場合(S12のY)、当該公開鍵証明書のダイジェスト、および公開鍵をダイジェスト保持部151cに上書きする(S13)。証明書検証部151aは、該当RSU期間内のパケット認証を不定と判定し、受信処理部161に報告する(S14)。なお、不定とは認証処理の結果が確定していない状態を指す。受信処理部161は、認証が不定のパケットに含まれるデータを、予め設定された規則にしたがい処理する。たとえば、認証されるまでそのデータに対する処理を停止していてもよいし、未認証である旨のフラグを立てて通知部162に渡してもよいし、メッセージに含まれる情報の重要度に応じて両者を使い分けしてもよい。通知部162は未認証である旨のフラグが立っている情報を受領した場合、未認証の情報であることをユーザに認識させる態様で、その情報をユーザに通知することができる。
【0073】
ステップS12にて上記検証が失敗した場合(S12のN)、該当RSU期間内のパケット認証を否認と判定し、受信処理部161に報告する(S15)。ステップS12〜ステップS15の処理が、図6における期間Tcの処理である。ステップS11にてダイジェストが一致する場合(S11のY)、電子署名付きメッセージの検証をすべきパケット信号を選択する(S16)。上述したように、この検証対象は該当RSU期間内の先頭パケットであってもよいし、先頭以外のパケットであってもよい。また、検証対象とすべきパケットの数は一つであってもよいし、複数であってもよい。
【0074】
メッセージ検証部151bは選択されたパケットに含まれる電子署名付きメッセージを検証する(S17)。当該検証が成功した場合(S17のY)、メッセージ検証部151bは、該当RSU期間内のパケット認証を承認と判定し、受信処理部161に報告する(S18)。当該検証が失敗した場合(S17のN)、メッセージ検証部151bは、該当RSU期間内のパケット認証を否認と判定し、受信処理部161に報告する(S19)。ステップS16〜ステップS19の処理が、図6における期間Tmの処理である。
【0075】
端末装置10の受信処理の継続中(S20のN)、ステップS10〜ステップS19までの処理が繰り返し実行される。当該受信処理が終了すると(S20のY)、ステップS10〜ステップS19までの処理も終了する。
【0076】
図13は、検証部151の構成例2を示す。構成例2に係る検証部151は、構成例1に係る検証部151にステータス管理部151eが追加された構成である。ステータス管理部151eは、ダイジェスト保持部151cに保持されるRSU検証情報のそれぞれに対応した処理の進行状態を示すステータスの管理を行う。構成例2では、単位RSU期間に受信されるRSUパケットの公開鍵証明書および電子署名付きメッセージの検証を、その単位RSU期間に終了させることが保証されないことを前提とする。すなわち、構成例2に係る検証部151の処理能力が構成例1に係る検証部151の処理能力より低く、換言すれば、回路規模が小さく設計される。
【0077】
図14は、構成例2に係る検証部151が用いられる端末装置10のRSUパケットの受信処理を示すフローチャートである。RF部12はRSUパケットを受信する(S30)。このRSUパケットは変復調部13、MACフレーム処理部14を経て、セキュリティ処理部15に出力される。証明書検証部151aは、ダイジェスト保持部151cに保持される公開鍵証明書のダイジェストと、受信されたRSUパケットに含まれる公開鍵証明書のダイジェストを比較し、一致するか否か判定する(S31)。
【0078】
ダイジェストが一致しない場合(S31のN)、証明書検証部151aは、該当RSU期間内のパケットの公開鍵証明書の検証が必要であると判断し、パケット認証は不定として、受信処理部161に報告する(S32)。その後、証明書検証部151aに公開鍵証明書の検証開始をステータス管理部151eに指示する(S33)。ダイジェストが一致する場合(S31のY)、メッセージの検証開始をステータス管理部151eに指示し、ステータス管理部151eはステータスを判定する(S34、S38)。当該ステータスは後述する図15図16に示すフローチャートにより管理される。
【0079】
ステータスが「証明書検証失敗」または「メッセージ検証失敗」の場合、ステータス管理部151eは該当RSU期間内のパケット認証を否認と判定し、受信処理部161に報告する(S35)。ステータスが「証明書検証中」、「証明書検証成功」または「メッセージ検証中」の場合、ステータス管理部151eは該当RSU期間内のパケット認証を不定と判定し、受信処理部161に報告する(S36)。ステータスが「メッセージ検証成功」の場合、ステータス管理部151eは該当RSU期間内のパケット認証を承認と判定し、受信処理部161に報告する(S37)。当該報告の後、「証明書検証成功」の場合(S38の証明書検証成功)、ステータス管理部151eは、メッセージ検証部151bに電子署名付きメッセージの検証開始を指示する(S39)。
【0080】
端末装置10の受信処理の継続中(S40のN)、ステップS30〜ステップS39までの処理が繰り返し実行される。当該受信処理が終了すると(S40のY)、ステップS30〜ステップS39までの処理も終了する。
【0081】
図15は、構成例2に係る検証部151が用いられる端末装置10の公開鍵証明書の検証処理を示すフローチャートである。当該検証処理は、ステータス管理部151eによる公開鍵証明書の検証開始指示を受けて開始する(図14のS33)。まず、ステータス管理部151eはステータスを「証明書検証中」に設定する(S331)。ステータス管理部151eは公開鍵証明書の検証が終了したか否か判定する(S332)。終了しない間(S332のN)、ステータスを「証明書検証中」に維持する。当該検証が終了すると(S332のY)、ステータス管理部151eは当該検証が成功したか否か判定する(S333)。当該検証が成功した場合(S333のY)、証明書検証部151aは、当該公開鍵証明書のダイジェスト、および公開鍵をダイジェスト保持部151cに上書きする(S334)。ステータス管理部151eはステータスを「証明書検証成功」に変更する(S335)。上記検証が失敗した場合(S333のN)、ステータス管理部151eはステータスを「証明書検証失敗」に変更する(S336)。
【0082】
図16は、構成例2に係る検証部151が用いられる端末装置10の電子署名付きメッセージの検証処理を示すフローチャートである。当該検証処理は、ステータス管理部151eによる電子署名付きメッセージの検証開始指示を受けて開始する(図14のS39)。まず、ステータス管理部151eはステータスを「メッセージ検証中」に変更する(S391)。ステータス管理部151eは電子署名付きメッセージの検証が終了したか否か判定する(S392)。終了しない間(S392のN)、ステータスを「メッセージ検証中」に維持する。当該検証が終了すると(S392のY)、ステータス管理部151eは当該検証が成功したか否か判定する(S393)。当該検証が成功した場合(S393のY)、ステータス管理部151eはステータスを「メッセージ検証成功」に変更する(S394)。上記検証が失敗した場合(S393のN)、ステータス管理部151eはステータスを「メッセージ検証失敗」に変更する(S395)。
【0083】
なお、図14のステップS32およびステップS33と図15の処理が、図6における期間Tcの処理にあたり、図14のステップS34〜ステップS39および図16の処理が、図6における期間Tmの処理にあたる。図14図16のフローチャートに示す検証処理によれば、単位RSU期間内に、その期間に含まれる公開鍵証明書および電子署名付きメッセージの検証が終了しない場合でも、矛盾なく検証処理を実行できる。
【0084】
以上説明したように実施例1によれば、セキュリティを向上させつつ、パケット信号を受信する際の処理負荷を軽減できる。すなわち、公開鍵暗号方式を用いた、公開鍵証明書および電子署名をパケット信号に含めることにより、セキュリティを向上させることができる。また、公開鍵証明書の検証処理を適宜スキップすることにより処理負荷を軽減できる。電子署名付きメッセージの検証処理も適宜スキップすることにより処理負荷をさらに軽減できる。この処理負荷を軽減するほど、回路規模を小さくでき、コストも削減できる。したがって、路車間通信の高信頼性が要求されるITSにおいて、本実施例に係る端末装置10を採用すれば、高信頼性と低コストを両立でき、ITSの普及にもつながる。
【0085】
以上、実施例1を説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【0086】
図17は、RSUパケットに含まれる図7のセキュリティフレームのフォーマットの変形例1を示す。変形例1に係るデータ構造は、図7に示すデータ構造に「MAC」を追加した構成である。図17に示すデータ構造では「電子署名」の後に「MAC」が追加され、セキュリティフッダは、「電子署名」と「MAC」によって構成される。「MAC」は、共通鍵とMAC対象に所定のMAC(Message Authentication Code:メッセージ認証コード)アルゴリズムを適用して生成される。図17に示すデータ構造では、MAC対象は「nonce」、「データ長」、「公開鍵証明書」、「ペイロード」および「電子署名」であり、共通鍵は基地局装置20と端末装置10間で共有されている通信鍵である。図17の例では、「MAC」は、AES(Advanced Encryption Standard)アルゴリズムと「鍵ID」により特定される通信鍵を用いたCBC(Cipher Block Chaining)−MACの値を代入する。認証付き暗号化データの場合は、CCM(Counter with CBC−MAC)モードにより生成されることとなる。
【0087】
「MAC」は「電子署名」より簡易な認証方法であり、データ量も少なく、かつ、高速処理が可能である。基地局装置20のセキュリティ処理部15は、「電子署名」と「MAC」の両方を生成する。端末装置10の検証部151は、RSU期間の先頭パケットに含まれる公開鍵証明書および電子署付きメッセージの検証を実行し、それらの検証が成功した場合、当該RSU期間の先頭パケットに後続するパケットについては公開鍵証明書のダイジェストの比較と、MAC付きメッセージの検証を実行する。MAC付きメッセージの検証は、電子署名付きメッセージの検証より負荷が軽くハードウエア化に適した処理であること、認証付き暗号化データの場合に使用する暗号化と同一の暗号アルゴリズムを最小とするため暗号処理の追加がないことにより、セキュリティ低下を抑制しつつ、回路規模を小さくできる。図11および図13のメッセージ検証部151bは、メッセージ検証のスキップに代えてMACの検証を行う。MAC検証に成功した場合、パケット認証を承認とする。MAC検証に失敗した場合、パケット認証を否認と報告する。このように、全ての検証をスキップに代えてMAC検証を行うことで、各メッセージの完全性と真正性の確認ができるようになるので、セキュリティ低下を招くことなく、署名検証の負荷を軽減することができる。
【0088】
変形例1に係るデータ構造では、「公開鍵証明書」を暗号化の対象外としている。この場合、図8のデータ構造のように「データ長」と「公開証明書」を転置して、「データ長」に対して「ペイロード」あるいは、暗号対象データのバイト数を代入するようにしてもよい。また、図7同様に「公開鍵証明書」も暗号化の対象に含めるようにしてもよい。
【0089】
図18は、RSUパケットに含まれるセキュリティフレームのデータ構造の変形例2を示す。変形例1に係るデータ構造は、認証用のデータとして、「電子署名」と「MAC」の両方が格納されるため、セキュリティフレームのデータ量が増大する。そこで、RSU期間の先頭パケット以外のパケットのセキュリティフレームのデータ量を低減する手法を考える。
【0090】
変形例2に係るデータ構造は、1つのRSU期間の先頭のRSUパケットのみ「電子署名」と「MAC」の両方をセキュリティフッダに格納し、後続のRSUパケットは「MAC」のみとする。変形例1に係るデータ構造と比較すると、先頭のパケットは同じ構造である。後続のパケットは、「電子署名」が削除され、「公開鍵証明書」の代わりに「公開鍵証明書のダイジェスト」が用いられる構成である。なお、通信路におけるパケット位置が通信システム500内で管理されている場合、「公開鍵証明書のダイジェスト」も省略可能である。また、前述のごとく、「公開鍵証明書のダイジェスト」は、公開鍵証明書を特定可能な情報であれば代用が可能である。例えば、公開鍵証明書に含まれる機器IDや、公開鍵証明書の識別情報、公開鍵証明書の署名およびその一部などがそれに当たる。変形例2に係るデータ構造のセキュリティフレームは、RSU期間の先頭パケット以外のパケットに用いられる。
【0091】
変形例2に係る先頭のRSUパケットのデータ構造も、変形例1に係るデータ構造と同様に、「公開鍵証明書」を暗号化の対象外としている。この場合、図8のデータ構造のように「データ長」と「公開証明書」を転置して、「データ長」に対して「ペイロード」あるいは、暗号対象データのバイト数を代入するようにしてもよい。また、図7同様に「公開鍵証明書」あるいは「公開鍵証明書のダイジェスト」も暗号化の対象に含めるようにしてもよい。
【0092】
また、変形例2に係るデータ構造における後続のRSUパケットについては、「公開鍵証明書のダイジェスト」を暗号化の対象外としているが、「公開鍵証明書のダイジェスト」も暗号化の対象に含めるようにしてもよいし、「データ長」と「公開鍵証明書のダイジェスト」を転置して、「データ長」に対して「ペイロード」あるいは、暗号対象データのバイト数を代入するようにしてもよい。また、1つのRSU期間の先頭のRSUパケットか、後続のRSUパケットかによってセキュリティフレームのデータ構造を分けるように説明したが、1つの基地局装置20が複数のRSU期間を使用する場合、1つの基地局装置20が、スーパーフレームに送信する全てのRSUパケットの1つに「公開鍵証明書」と「電子署名」が含まれているようにしてもよい。この場合、スーパーフレームに送信する先頭のRSUパケットと、それ以外の後続のRSUパケットでセキュリティフレームのデータ構造が分けられる。
【0093】
図19は、RSUパケットに含まれるセキュリティフレームのデータ構造の変形例3を示す。変形例3に係るデータ構造は、1つのRSU期間の先頭のRSUパケットは、図7のセキュリティフレームと同じ構造とし、後続のRSUパケットは変形例2の後続のRSUパケットと同じ構造とする。スーパーフレーム期間内に各RSU用コアに対する公開鍵の署名検証(ECDAS検証)処理能力を持つ場合に最も有効である。セキュリティフレームのデータ構造の変形例2および変形例3においても、変形例1と同様で、図11および図13のメッセージ検証部151bは、メッセージ検証のスキップに代えてMACの検証を行う。MAC検証に成功した場合、パケット認証を承認とする。MAC検証に失敗した場合、パケット認証を否認と報告するようにすればよい。
【0094】
変形例3に係るデータ構造における先頭のRSUパケットを、図8のセキュリティフレームと同じ構造としてもよい。また、変形例3に係るデータ構造における後続のRSUパケットについては、「公開鍵証明書のダイジェスト」を暗号化の対象外としているが、「公開鍵証明書のダイジェスト」も暗号化の対象に含めるようにしてもよいし、「データ長」と「公開鍵証明書のダイジェスト」を転置して、「データ長」に対して「ペイロード」あるいは、暗号対象データのバイト数を代入するようにしてもよい。また、変形例2と同様、1つの基地局装置20が複数のRSU期間を使用する場合、スーパーフレームに送信する先頭のRSUパケットと、それ以外の後続のRSUパケットでセキュリティフレームのデータ構造を分けるようにしてもよい。
【0095】
変形例1および変形例2は、端末装置10が、基地局装置20の電波到達距離内に入ると、最初にRSU期間の先頭のRSUパケットを選択して検証を行う。この時、公開鍵証明書およびメッセージの検証によって、基地局装置20の正当性とパケット信号に含まれるアプリケーションデータの完全性と真正性が確認される。承認された場合、当該RSUパケットが正規の基地局装置20から発信された正規のパケット信号であることが確認されたことになる。また、通信の性格上、当該RSUパケットが送信されたRSU期間は、正規の基地局装置20は送信期間であることが確定する。以降のRSUパケットでは、公開鍵証明書のダイジェストの一致確認とMAC検証によってパケット信号に含まれるアプリケーションデータの完全性と真正性を確認する。一方、端末装置10が、基地局装置20の電波到達距離外に出て、同じサブフレームを使用する別の基地局装置20の電波到達距離内に入ると、公開鍵証明書のダイジェストが一致しないので、再び、署名の検証を行うこととなる。変形例3は、RSU期間単位で処理を閉じる。RSU期間の先頭RSUパケットに対して、公開鍵証明書およびメッセージの検証を行い、基地局装置20の正当性とパケット信号に含まれるアプリケーションデータの完全性と真正性を確認する。後続のRSUパケットに対しては公開鍵証明書のダイジェストの一致確認とMAC検証によってパケット信号に含まれるアプリケーションデータの完全性と真正性を確認する。
【0096】
次に、変形例4を説明する。図18に示した変形例2では、各RSUパケットにMACが含まれている。変形例4では、先頭以外のRSUパケットに対して、MACを配置させず、それらのMACも先頭パケットにまとめて配置させる。つまり、先頭パケットには、RSU期間に含まれた各RSUパケットに対するMACが含まれている。図20(a)−(c)は、RSUパケットに含まれるセキュリティフレームのデータ構造の変形例4を示す。図20(a)は、図3(b)に示された路車送信期間、つまり図5に示されたRSU期間に含まれた複数のRSUパケットのうち、先頭パケットのフォーマットを示す。
【0097】
これは、図5のRSUパケット1に相当する。図示のごとく、「Ver」、「メッセージ形式」、「パケットID」、「公開鍵証明書」、「鍵ID」、「MACリスト」、「電子署名」、「Nonce」、「データ長」、「ペイロード」が順に配置される。「Ver」、「メッセージ形式」、「公開鍵証明書」、「鍵ID」、「電子署名」、「Nonce」、「データ長」、「ペイロード」は、これまでと同一であるので、ここでは説明を省略する。パケットIDでは、RSU期間に含まれる複数のRSUパケットを識別するための番号が示される。具体的には、RSU期間に含まれる複数のRSUパケットの先頭から順に、パケットIDが「0」、「1」、・・・のように規定される。そのため、先頭パケットでは、パケットIDとして「0」が示される。
【0098】
「MACリスト」の構成は、図20(b)に示される。図示のごとく、「パケット数」、「MAC(P0)」、「MAC(P1)」、・・・、「MAC(Pn−1)」が含まれる。「パケット数」は、RSU期間に含まれるRSUパケット数を示す。したがって、MACリストに列挙されている「MAC(Pi)」(0≦i<n、iは自然数)の数nが代入される。「MAC(P0)」は、パケットID「0」に対するMACを示し、「MAC(P1)」は、パケットID「1」に対するMACを示す。「パケット数」がnである場合、「MAC(Pn−1)」までが含まれる。図20(a)に戻る。ここでは、「MACリスト」、「電子署名」が署名対象であり、「Nonce」、「データ長」、「ペイロード」がMAC対象であり、ペイロードが暗号対象である。なお、暗号化はなされなくてもよい。
【0099】
図20(c)は、後続のRSUパケットのフォーマットを示す。これは、図5のRSUパケット2からRSUパケット7のそれぞれに相当する。図示のごとく、「Ver」、「メッセージ形式」、「パケットID」、「公開鍵証明書ダイジェスト」、「鍵ID」、「Nonce」、「データ長」、「ペイロード」が順に配置される。パケット数がnである場合、パケットIDでは、「1」、「2」、・・・「n−1」が示される。図20(c)では、図18の後続の先頭RSUパケットとは異なり、鍵IDが含まれない。これは、変形例4においてすべてのRSUパケットに対するMACは、先頭パケットに含まれており、かつ共通の鍵IDの通信鍵がMACの生成に使用されているからである。
【0100】
基地局装置20のセキュリティ処理部15は、すべてのRSUパケットに対する「MAC」を生成し、次いで、生成したMACを含む「MACリスト」に対する「電子署名」を生成する。セキュリティ処理部15は、それらを先頭パケットに含める。端末装置10の検証部151は、RSU期間の先頭パケットに含まれる公開鍵証明書および公開鍵証明書に含まれる公開鍵を使用して電子署付き「MACリスト」の検証を実行することによって、基地局装置20の正当性とパケット信号に含まれるアプリケーションデータの真正性を確認する。それらの検証が成功した場合、つまり承認された場合、当該RSUパケットが正規の基地局装置20から発信された正規のパケット信号であることが確認されたことになる。また、前述のごとく、当該RSUパケットが送信されたRSU期間は、正規の基地局装置20は送信期間であることが確定する。当該RSU期間の先頭パケットにおける公開鍵暗号方式による2つの検証に成功した後は、先頭のパケットについては公開鍵証明書のダイジェストの比較と、MAC(P0)を用いたメッセージの検証を、後続するパケットでは、公開鍵暗号方式による2つの検証が成功した、あるいは、公開鍵証明書のダイジェストの比較に成功した先頭パケットに含まれるMAC(Pi)、(0<i<n、iは自然数)を用いたメッセージ認証を実行する。
【0101】
変形例4によれば、MACを先頭パケットに集約するので、先頭パケット以外のRSUパケットの伝送効率を向上できる。また、すべてのRSUパケットの鍵IDを共通にするので、すべてのRSUパケット全体の伝送効率を向上できる。また、公開鍵暗号方式による認証処理の高速化を受けて、変形例3と同じように、RSU期間単位で処理を閉じることもできる。
【0102】
次に、変形例5を説明する。変形例5では、変形例4と比較して、「ペイロード」が電子署名の対象であり、「MACリスト」および「電子署名」が暗号対象である点が異なる。図21(a)−(b)は、RSUパケットに含まれるセキュリティフレームのデータ構造の変形例5を示す。図21(a)は、先頭パケットのフォーマットを示し、図21(b)は、先頭パケット以外のRSUパケットのフォーマットを示す。図21(a)では、図20(a)と比較して、MAC対象および暗号対象が異なるので、「MACリスト」と「電子署名」の位置が異なっている。一方、図21(b)は、図20(b)と同様である。変形例4に対して、基地局装置20および端末装置10では、署名処理、暗号処理を除いて変形例3と同様の処理がなされればよいので、ここでは説明を省略する。変形例4によれば、MACリストが暗号対象にされるので、セキュリティ特性を向上できる。
【0103】
なお、変形例4および変形例5のRSU期間の後続するパケットに、当該パケットを発信する基地局装置20を簡易に確認するために「公開鍵証明書ダイジェスト」を含めているが、省略しても構わない。該RSU期間の先頭パケットにおける公開鍵暗号方式による2つの検証に成功した時に使用した公開鍵証明書のダイジェストと、先頭のパケットに含まれる公開鍵証明書のダイジェストとを比較して、一致した場合に、MAC(Pi)(0≦i<n、iは自然数)を取り出す。したがって、取り出したMACは、正規の基地局装置20から発信された正当な値であると判断する。この場合、RSU期間の後続するパケットに対する公開鍵証明書のダイジェスト比較は省略される。
【0104】
次に、変形例6を説明する。変形例6は、RSU期間に含まれた複数のRSUパケットすべてに対してひとつの電子署名とひとつのMACを生成する。図22(a)−(c)は、RSUパケットに含まれるセキュリティフレームのデータ構造の変形例6を示す。図22(a)は、先頭パケットのフォーマットを示し、図22(b)は、RSU期間に含まれた複数のRSUパケットのうち、先頭パケットと最後のRSUパケット以外のRSUパケットのフォーマットを示す。さらに、図22(c)は、最後のRSUパケットのフォーマットを示す。図22(a)における「パケット総数」は、RSU期間に含まれたRSUパケットの総数を示し、「ペイロード長」は、図22(a)−(c)に含まれたペイロードの合計バイト数を示す。一方、図22(a)−(c)の「データ長」は、当該パケットにおける暗号対象のバイト数を示す。また、図22(a)および図22(b)において、電子署名およびMACは含まれない。一方、図22(c)のみに電子署名およびMACが含まれる。
【0105】
変形例6のセキュリティフレームのデータ構造では、先頭パケットのみに「パケット総数」を含めているが、すべてのパケットに対して、「パケット総数」を含めてもよい。例えば、先頭パケットと同様に、「パケットID」と「パケット総数」を並べて配置すればよい。
【0106】
基地局装置20のセキュリティ処理部15は、分割前のペイロードに対して、電子署名およびMACを生成した後、ペイロードを複数に分割する。分割数は、RSU期間に含まれるRSU数に相当する。セキュリティ処理部15は、分割したペイロードをもとに、図22(a)−(c)に示されたフォーマットのRSUパケットを生成する。その際、前述のごとく、最後のRSUパケットのみに電子署名およびMACが配置される。端末装置10の検証部151は、パケットIDをもとに、RSU期間に含まれた複数のRSUパケットを合成する。以下、合成したRSUパケットは連結パケットと呼ばれる。検証部151は、連結パケットに含まれる公開鍵証明書および電子署付きメッセージの検証を実行することによって、基地局装置20の正当性とパケット信号に含まれるアプリケーションデータの真正性を確認する。それらの検証が成功した場合、つまり承認された場合、当該連結パケットが正規の基地局装置20から発信された正規のパケット信号であることが確認されたことになる。さらに、検証部151は、公開鍵証明書のダイジェストの比較と、MAC付きメッセージの検証を実行する。変形例5によれば、複数のRSUパケットのすべてに対して、ひとつの電子署名とひとつのMACが配置されるので、伝送効率を向上できる。
【0107】
さらに、すべてのパケットに対してMACを配置した変形例1、2、4、5および、1つのRSU期間におけるすべてのパケット結合した変形例6のセキュリティフレームのデータ構造を採用することで、公開鍵暗号による検証処理を実装しないで共通鍵暗号のみ、すなわち、暗号化データの復号とMAC検証のみに対応した低コストの端末装置10を提供することも可能となる。この端末装置10は、なりすまし検知、改ざんの検知の効果を得ることができる。
【0108】
また、変形例1、2、5および6では、「電子署名」をMAC対象としたが、必ずしもMAC対象に含める必要はない。含めない場合でも同様な効果が得られる。なお、本発明におけるセキュリティフレームの一例、別の例、変形例1〜6において、主に「ペイロード」を暗号対象として暗号化するように説明したが、必ずしも暗号化する必要はなく、「ペイロード」を秘匿する必要がない場合には暗号化を行わないで平文としてよい。
【0109】
実施例1および変形例において、「鍵ID」が配置されているが、それの代わりに暗号化された通信鍵が配置されていてもよい。
【0110】
(実施例2)
本発明の実施例2の基礎となった知見は、次の通りである。リアルタイム性を重視する必要がある路車間通信および車車間通信では、共通鍵暗号化方式を採用することが有力である。しかしながら、路車間通信および車車間通信を同じ共通鍵で運用すると、その鍵が漏洩した場合、路車間通信および車車間通信の両方のセキュリティが破れてしまう。
【0111】
実施例2はこうした状況に鑑みてなされたものであり、その目的は、共通鍵暗号化方式を用いた通信システムのセキュリティを効率的に向上させる技術を提供することにある。
【0112】
実施例2の一態様の概要は、次の通りである。実施例2のある態様の端末装置は、暗号化されたパケット信号を受信する受信部と、前記パケット信号を復号する復号部と、を備える。前記パケット信号は共通鍵暗号方式により暗号化されており、基地局装置から報知されるパケット信号と、他の端末装置から報知されるパケット信号とで異なる運用方式により暗号化される。
【0113】
この態様によれば、共通鍵暗号化方式を用いた通信システムにおいて、路車間通信と車車間通信とで異なる運用方式を併用することにより、通信システム全体のセキュリティを効率的に向上させることができる。
【0114】
前記基地局装置から報知されるパケット信号は、前記他の端末装置から報知されるパケット信号よりセキュリティレベルの高い運用方式により暗号化されてもよい。これによると、高い信頼性が要求されるデータが含まれることが多い前者のパケット信号を、後者のパケット信号よりセキュリティレベルの高い運用方式により暗号化することにより、通信システム全体の処理負荷の増大を抑制しつつ、セキュリティ確保を図ることができる。
【0115】
前記基地局装置から報知されるパケット信号は、パケット送信のたびに生成される通信鍵により暗号化されてもよい。前記他の端末装置から報知されるパケット信号は、端末装置間で共有されている、複数の通信鍵を含む鍵テーブル内のいずれかの通信鍵により暗号化されてもよい。これによると、高い信頼性が要求されるデータが含まれることが多い前者のパケット信号を、後者のパケット信号よりセキュリティレベルの高い運用方式により暗号化することにより、通信システム全体の処理負荷の増大を抑制しつつ、セキュリティ確保を図ることができる。
【0116】
前記基地局装置と本端末装置間でマスタ鍵が共有されてもよい。前記基地局装置から報知されるパケット信号には、前記マスタ鍵により暗号化された通信鍵が含まれてもよい。前記他の端末装置から報知されるパケット信号は、前記鍵テーブル内から選択された通信鍵の識別情報が含まれてもよい。これによると、高い信頼性が要求されるデータが含まれることが多い前者のパケット信号を、後者のパケット信号よりセキュリティレベルの高い運用方式により暗号化することにより、通信システム全体の処理負荷の増大を抑制しつつ、セキュリティ確保を図ることができる。
【0117】
前記基地局装置から報知されるパケット信号に含まれるメッセージに、公開鍵暗号方式により暗号化された電子署名が付加されてもよい。これによると、前記基地局装置から報知されるパケット信号のセキュリティを向上させることができる。
【0118】
図23は、セキュリティフレームのデータ構造の一例を示す。これは、図4(e)の内容を詳細にした図である。セキュリティヘッダには、バージョン(VER)、メッセージタイプ(MT)、鍵情報、Nonceおよびデータ長を含む。バージョン(VER)はフレームフォーマットのバージョンを示し、固定値(=0)である。バージョン(VER)のデータ長は1バイトである。メッセージタイプ(MT)はメッセージのタイプ、データ認証方式などを指定する。メッセージタイプ(MT)のデータ長は0.5バイトである。当該データ長の最上位ビット(MSB)は管理アプリフラグであり、管理フィールドの有無を示す。「0」が無し、「1」が有りを示す。ビット2はデータ認証方式を示す。「0」がメッセージ認証コード(MAC:Message Authentication Code)方式、「1」が電子署名方式を示す。ビット1および最下位ビット(LSB)はメッセージ形式を示す。「0」が認証無しデータ、「1」が認証付きデータ、「2」が認証付き暗号化データ、「3」が予約を示す。
【0119】
鍵情報は、フラグ、マスタ鍵、通信鍵および鍵IDを含む。マスタ鍵、通信鍵および鍵IDはオプションである。フラグは鍵情報内の後続フィールドの有無を示す。フラグのデータ長は0.5バイトである。最上位ビット(MSB)がマスタ鍵(暗号化されていてもよい)、ビット2が通信鍵(暗号化されていてもよい)、ビット1が鍵ID、最下位ビット(LSB)が予約(=0)を示す。各ビットにおいて「0」が無しを示し、「1」が有りを示す。したがって、すべてのビットが「0」の場合、当該フィールドは省略されることを示す。マスタ鍵は直前のマスタ鍵で暗号化された新マスタ鍵を示す。マスタ鍵のデータ長は16バイトである。通信鍵は最新のマスタ鍵で暗号化された通信鍵を示す。通信鍵のデータ長は16バイトである。鍵IDは鍵テーブルを参照するための識別番号を示す。鍵IDのデータ長は1バイトである。Nonceは発信元情報および発信日時を含む。発信元情報は発信元の機器IDを示す。発信元情報のデータ長は4バイトである。発信日時はメッセージの送信日時またはカウンタ値を示す。発信日時のデータ長は6バイトである。データ長はペイロードのバイト長を示す。データ長は1〜2バイトの範囲である。なお、実施例1同様、Nonceは乱数であってもよい。
【0120】
ペイロードは通信鍵による秘匿およびメッセージ認証対象となる。ペイロードは管理アプリおよびサービスアプリを含む。管理アプリは、セキュリティ管理アプリケーションデータを示し、オプションである。サービスアプリはアプリケーションデータを示す。管理アプリおよびサービスアプリのデータ長は可変である。
【0121】
セキュリティフッタはデータ認証を含む。データ認証はMACまたは電子署名を示す。データ認証のデータ長は前者のとき12バイトで、後者のとき56バイトである。
【0122】
図24は、実施例2に係る基地局装置20の構成を示す。基地局装置20は、アンテナ21、RF部22、変復調部23、MACフレーム処理部24、セキュリティ処理部25、データ生成部26、ネットワーク通信部27、記憶部28および制御部29を備える。セキュリティ処理部25は暗復号部256、暗号部257および鍵更新部258を含む。以下、図9の実施例1に係る基地局装置20と重複する説明を省略し、それとの相違点を説明する。
【0123】
ネットワーク通信部27は、外部ネットワーク200に接続される。ネットワーク通信部27は、外部ネットワーク200から工事や渋滞などに関する道路情報を受けつける。また、本実施例では後述するシステム運用管理装置から提供される、路車間通信用のマスタ鍵(以下、路車間マスタ鍵という)、機器ネガリスト、暗号化更新鍵テーブルおよびテーブル更新鍵を受けつける。なお、機器ネガリストとはシステム運用管理装置から提供される共通鍵テーブルを追加または更新すべきでない端末装置10のリストをいう。機器ネガリストに登録される機器は、機器に不具合が発見され、メーカによる回収が進められている機器や、盗難届が出されている機器などが該当する。
【0124】
また、ネットワーク通信部27は、セキュリティ処理部25による処理結果を外部ネットワーク200へ出力したり、記憶部28に蓄積して、定期的に外部ネットワーク200へ出力したりする。
【0125】
記憶部28は、種々の情報(たとえば、路車間マスタ鍵、共通鍵テーブル、テーブル更新鍵)を記憶する。本実施例では、外部ネットワーク200から取得される道路情報、後述するシステム運用管理装置から提供される、新しい路車間マスタ鍵、機器ネガリスト、暗号化更新鍵テーブルおよびテーブル更新鍵、ならびに端末装置10から提供される機器IDおよび共通鍵テーブルID(以下適宜、テーブルIDという)を一時的に記憶する。制御部29は、基地局装置20全体の処理を制御する。データ生成部26は、センサやカメラ(図示されない)などからの情報や、記憶部28に記憶されている情報を利用してサービスアプリケーションデータを生成する。そして、サービスアプリケーションデータの内容によって、メッセージ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部25に出力する。
【0126】
セキュリティ処理部25は、セキュリティフレームを生成または解釈する。セキュリティ処理部25は、送信処理として、データ生成部26からサービスアプリケーションデータを受け取ると、MACフレーム処理部24に出力すべきセキュリティフレームを、受け取ったサービスアプリケーションデータと記憶部28に記憶されているデータをもとに生成する。たとえば、図23に示すペイロードのサービスアプリに、データ生成部26から受け取ったサービスアプリケーションデータをセットし、そのデータ長をセキュリティヘッダのデータ長にセットする。また、セキュリティヘッダの鍵情報の通信鍵に、路車間マスタ鍵で暗号化された通信鍵(乱数)をセットする。また、当該通信鍵(乱数)を用いて求めたMACをセキュリティフッタにセットする。そして、その他のセキュリティヘッダを付加してセキュリティフレームを生成する。その後、指定されたメッセージ形式が認証付き暗号化データの場合、ペイロードおよびMACを当該通信鍵(乱数)を用いて暗号化することで、メッセージを秘匿することも可能である。
【0127】
セキュリティ処理部25は、受信処理として、MACフレーム処理部24からのセキュリティフレームを受けつける。セキュリティ処理部25は、セキュリティフレームのうちのセキュリティヘッダの内容を確認する。メッセージタイプが認証付きデータである場合、暗復号部256にてメッセージの検証処理を実行する。メッセージタイプが認証付き暗号化データである場合、暗復号部256にてメッセージの復号処理を実行し、検証処理を実行する。なお、メッセージタイプが平文である場合、これらの処理は省略される。
【0128】
セキュリティ処理部25は、暗復号部256、暗号部257および鍵更新部258を含む。本実施例では、基地局装置20からのパケット送信に注目するため、送信処理として実行されるセキュリティフレームを生成する処理に注目する。受信処理として行われるセキュリティフレームを解釈する処理については、後述する端末装置10の受信処理と同じである。暗復号部256は、通信鍵を用いてペイロードを対象としたMACを生成する。MACは、AES−CBCモードを利用したCBC−MACアルゴリズムを適用して生成される。なお、MACの生成には、Nonceやデータ長も利用される。次いで、メッセージ形式が認証付き暗号化データの場合、通信鍵を用いてペイロードとセキュリティフッダの暗号化が行われる。暗号化は、AES_CTR(CounTeR)モードを適用する。本実施例では、暗復号部256は、メッセージ形式が認証付き暗号化データの場合には、通信鍵(乱数)を用いたAES−CCMモードを適用したため、ペイロードに対するMACの付加およびペイロードとMACの暗号化を行う。なお、AES―CCMモードを適用せずに、ペイロードより暗号化を行った後、MACの付加を行ってもよいし、MACの付加および暗号化のいずれか一方のみを行ってもよい。なお、ペイロードを対象としたMACの生成、および、ペイロードとセキュリティフッダの暗号化には、通信鍵の他に、Nonceやデータ長が利用される。CBC−MACおよびCCMモードのアルゴリズムによるものであり、Nonceの使用により、ペイロードと通信鍵が同じであっても、異なったMAC、暗号化の結果が得られる。
【0129】
暗号部257は、基地局装置20より端末装置10に対して送信する鍵を暗号化する。具体的には、暗復号部256で使用した通信鍵(乱数)を路車間マスタ鍵で暗号化する。また、暗号部257は、路車間通信で使用する路車間マスタ鍵を更新する際、現路車間マスタ鍵で新路車間マスタ鍵を暗号化する。また、暗号部257は、車車間通信で使用する共通鍵テーブルを更新する際、現テーブル更新鍵で新テーブル更新鍵を暗号化する。
【0130】
鍵更新部258は、路車間マスタ鍵の更新処理を行う。また、端末装置10が保持すべき共通鍵テーブルの更新処理を行う。これらの更新処理の詳細は後述する。
【0131】
図25は、実施例2に係る、車両100に搭載された端末装置10の構成を示す。端末装置10は、アンテナ11、RF部12、変復調部13、MACフレーム処理部14、セキュリティ処理部15、受信処理部161、通知部162、データ生成部17、記憶部18および制御部19を備える。セキュリティ処理部15は、暗復号部156、復号部157および鍵更新部158を含む。以下、図10の実施例1に係る端末装置10と重複する説明を省略し、それとの相違点を説明する。
【0132】
データ生成部17は、図示しないGPS受信機、ジャイロスコープ、車速センサなどから供給される情報にもとづき、端末装置10が搭載された車両100の現在位置、進行方向、移動速度などを特定する。なお、現在位置は、緯度・経度によって示される。これらの情報の特定方法は一般的な公知の技術により実現可能であるため、ここでは説明を省略する。データ生成部17は、特定した情報をもとに他の端末装置10や基地局装置20に報知すべきデータを生成し、生成したデータ(以下、アプリケーションデータという)をセキュリティ処理部15に出力する。そして、アプリケーションデータの内容によって、メッセージ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部15に出力する。また、特定した情報を受信処理部161に自車の車両情報として出力する。
【0133】
記憶部18は、種々の情報(たとえば、路車間マスタ鍵、共通鍵テーブル、テーブル更新鍵)を記憶する。また、本実施例では基地局装置20から取得される道路情報、自己または他の端末装置10から取得される車両情報、ならびに基地局装置20から取得される新しい暗号化路車間マスタ鍵、暗号化更新共通鍵テーブルおよび暗号化テーブル更新鍵を一時的に保持する。制御部19は、端末装置10全体の処理を制御する。
【0134】
セキュリティ処理部15は、送信処理として、セキュリティフレームを生成または解釈する。セキュリティ処理部15は、MACフレーム処理部14に出力すべきセキュリティフレームを、記憶部18に記憶されたデータをもとに生成する。たとえば、図23に示すペイロードのサービスアプリにアプリケーションデータをセットする。また、セキュリティヘッダの鍵情報の鍵IDに、MAC生成に使用する通信鍵の鍵IDをセットし、Nonceに自己の機器IDと時刻をセットする。また、鍵IDによって共通鍵テーブルより選択された通信鍵を用いて生成されるMACをセキュリティフッタにセットする。そして、その他のセキュリティヘッダを付加してセキュリティフレームを生成する。メッセージ形式が、認証付き暗号化データの場合、ペイロードおよびMACを当該通信鍵を用いて暗号化することで、メッセージを秘匿する。なお、メッセージタイプが平文である場合、これらの処理は省略される。
【0135】
セキュリティ処理部15は、受信処理として、MACフレーム処理部14からのセキュリティフレームを受けつける。セキュリティ処理部15は、セキュリティフレームのうちのセキュリティヘッダの内容を確認する。メッセージタイプが認証付きデータである場合、暗復号部156にてメッセージの検証処理を実行する。メッセージ形式が認証付き暗号化データである場合、暗復号部156にてメッセージの復号処理および検証処理を実行する。なお、メッセージ形式が平文である場合、これらの処理は省略される。
【0136】
セキュリティ処理部15は、暗復号部156、復号部157および鍵更新部158を含む。暗復号部156は、ペイロードに対するMACの生成と検証および、ペイロードとMACに対する暗号化および復号を行うことができる。すなわち、セキュリティヘッダのメッセージタイプのメッセージ形式に従った処理を行い、基地局装置20の暗復号部256と同等の機能を備える。したがって、送信処理は、基地局装置20の暗復号部256と同じであるため説明を割愛する。暗復号部156は、受信処理として、MACフレーム処理部14からセキュリティフレームを受け取る。メッセージ形式が認証付き暗号化データの場合、暗復号部156は、通信鍵を用いてペイロードとセキュリティフッタを復号する。そして、ペイロードに付加されたMACを検証する。メッセージ形式が暗号化データの場合、暗復号部156は、通信鍵を用いてペイロードを復号する。なお、復号および検証は送信側の暗号アルゴリズムに対応する復号アルゴリズムにより実行される。また、メッセージ形式が平文である場合、暗復号部156は復号および検証を実行しない。
【0137】
復号部157は、基地局装置20から報知されるパケット信号に含まれる通信鍵(乱数)を路車間マスタ鍵で復号する。また、路車間通信で使用する路車間マスタ鍵が更新される際、復号部157は基地局装置20から報知されるパケット信号に含まれる暗号化新マスタ鍵を現路車間マスタ鍵で復号する。また、車車間通信で使用される共通鍵テーブルが更新される際、復号部157は基地局装置20から報知されるパケット信号に含まれる暗号化テーブル更新鍵を現テーブル更新鍵で復号する。
【0138】
鍵更新部158は、自己(端末装置10)が保持すべき路車間マスタ鍵の更新処理および車車間通信用の共通鍵テーブルの更新処理を行う。鍵更新部158のこれらの更新処理の詳細は後述する。
【0139】
図26は、実施例2に係る通信システム500を用いた路車間通信における通常のメッセージ送受信手順を説明するための図である。基地局装置20の暗復号部256は、通信鍵とすべき乱数を発生させる。暗復号部256は、平文の送信データに対して当該通信鍵を用いて、MACを付加して、MAC付きの送信データを暗号化する。それとともに、暗号部257は当該通信鍵を路車間マスタ鍵を用いて暗号化する。これらの暗号化にはいずれも共通鍵暗号化方式が用いられる。セキュリティ処理部25は、暗号化送信データと暗号化通信鍵を格納したパケット信号を生成する。当該パケット信号は、MACフレーム処理部24および変復調部23を経て、RF部22からアンテナ21を介して外部に報知される。
【0140】
端末装置10のRF部12は、当該パケット信号をアンテナ11を介して受信する。当該パケット信号は、変復調部13およびMACフレーム処理部14を経て、セキュリティ処理部15に渡される。復号部157は、当該パケット信号に格納された暗号化通信鍵を、基地局装置20と共通している路車間マスタ鍵で復号する。暗復号部156は、当該パケット信号に格納された暗号化送信データを、復号された通信鍵で復号し、MAC検証する。復号化およびMAC検証が成功したら、暗号化送信データは平文の送信データに復元される。
【0141】
このメッセージ送受信方法には以下に示す様々なメリットがある。まず、動的に通信鍵を変えることができるので、後述する車車間通信におけるメッセージ送受信方法のように事前に複数の通信鍵を保持しておく必要がない。また、通信鍵として乱数を暗号化するため、通信路中から路車間マスタ鍵が漏洩するリスクが小さい。路車間マスタ鍵が漏洩しない限り、基本的に、システム運用管理機関や路車間サービス提供者は何もしなくてよい。また、路車間マスタ鍵が漏洩しても、マスタ鍵の更新の仕組みが知られない限り、通信鍵が漏洩するリスクは小さい。さらに、路車間通信により路車間マスタ鍵を更新することにより、漏洩リスクを低減できる。更新されるデータ量が少ないため、路車間マスタ鍵の更新は、路車間通信で十分に対応可能である。
【0142】
図27は、実施例2に係る通信システム500を用いた路車間通信における路車間マスタ鍵の更新手順を説明するための図である。システム運用管理機関のシステム運用管理装置300は、更新用の新しい路車間マスタ鍵を生成する。この更新用の新しい路車間マスタ鍵は、定期的に生成されてもよいし、路車間マスタ鍵の漏洩が発覚した場合に生成されてもよいし、その両方であってもよい。システム運用管理装置300は、路車間サービス提供者の路車間サービス提供者端末装置400に、新しい路車間マスタ鍵を伴うマスタ鍵更新通知を発行する。
【0143】
路車間サービス提供者端末装置400は、システム運用管理装置300から当該更新通知を受けると、基地局装置20に新しい路車間マスタ鍵を伴う更新指示を発行する。なお、システム運用管理機関と路車間サービス提供者間、路車間サービス提供者と基地局装置20との間の新しい路車間マスタ鍵の受け渡しは、通信システム500以外のバックインフラを用いて行われる。たとえば、専用回線などのセキュリティが保証されている通信網を用いてもよいし、記録メディアの配布により行われてもよい。
【0144】
基地局装置20の鍵更新部258は、新しい路車間マスタ鍵を受けつけると、自己の路車間マスタ鍵を更新する。具体的には、現路車間マスタ鍵を、前路車間マスタ鍵として、受けつけた新しい路車間マスタ鍵を現路車間マスタ鍵として、記憶部28に記録する。そして、更新後の一定期間、現路車間マスタ鍵(受け付けた新しい路車間マスタ鍵)をパケット信号に格納して報知するように制御する。暗号部257は、現路車間マスタ鍵(受け付けた新しい路車間マスタ鍵)を前路車間マスタ鍵を用いて暗号化する。この暗号化には共通鍵暗号化方式が用いられてもよいし、公開鍵暗号化方式が用いられてもよい。暗号化された新しい路車間マスタ鍵は、パケット信号に格納されて報知される。
【0145】
端末装置10の復号部157は、当該パケット信号に格納された暗号化路車間マスタ鍵を自身の保持する現路車間マスタ鍵を用いて復号する。鍵更新部158は、復号部157より復号された路車間マスタ鍵を受け取ると、自身の保持する現路車間マスタ鍵より、受け取った路車間マスタ鍵が新しい時に、現路車間マスタ鍵を、受け取った路車間マスタ鍵に置き換え(記憶部18に保持される路車間マスタ鍵も更新する。)、この新しい路車間マスタ鍵を更新後の正当な路車間マスタ鍵とする。
【0146】
なお、不正な基地局装置(いわゆる、なりすまし)は、基本的に、バックインフラを介して新しい路車間マスタ鍵を受け付けることができないため、少なくとも路車間マスタ鍵の更新後は、不正なメッセージを端末装置10に送り込むことができなくなる。すなわち、不正な基地局装置が現路車間マスタ鍵を知っている場合(すなわち、現路車間マスタ鍵が漏洩した場合)でも、新しい路車間マスタ鍵も知っていなければ、不正なメッセージを端末装置10に送り込むことができなくなる。新しい路車間マスタ鍵を知るには、路車間マスタ鍵更新の仕組みも知っていること(すなわち、仕様の漏洩)が条件となる。なお、新しい路車間マスタ鍵が公開鍵暗号方式で暗号化されている場合、不正な基地局装置はその秘密鍵を知っていることも条件となる。これらの条件をすべて満たす可能性は非常に低いと考えられる。なお、仮に現路車間マスタ鍵が漏洩しても、不正な基地局装置が出現するまで放置するという選択肢もあり得る。
【0147】
図28は、路車間通信において生成されるパケットに含まれるセキュリティフレームのデータ構造の一例を示す。図28において左側のセキュリティフレームが通常メッセージ送受信時のデータ構造を示し、右側のセキュリティフレームが路車間マスタ鍵更新時のデータ構造を示す。通常メッセージ送信時のセキュリティフレームのデータ構造では、ヘッダとして「バージョン」、「メッセージタイプ」、「通信鍵」および「NONCE」が配置され、その後に「ペイロード」が配置され、最後にフッタとして「MAC」が配置される。この例では、「ペイロード」がMAC対象である。「通信鍵」に格納される通信鍵(乱数)は路車間マスタ鍵により暗号化され、秘匿される。当該通信鍵(乱数)により「MAC」が生成され、当該通信鍵(乱数)により「ペイロード」および「MAC」が暗号化されて、秘匿される。
【0148】
路車間マスタ鍵更新時のセキュリティフレームのデータ構造では、通常メッセージ送信時のセキュリティフレームのデータ構造と比較し、「メッセージ形式」と「通信鍵」との間に「マスタ鍵」が挿入される。「マスタ鍵」には新しい路車間マスタ鍵が格納され、現路車間マスタ鍵により暗号化され、秘匿される。また、「ペイロード」内に「機器管理」として路車間マスタ鍵のバージョン情報が格納される。その他は、通常メッセージ送信時のセキュリティフレームと同様である。なお、端末装置10の鍵更新部158は、暗復号部156により「MAC」検証が成功した後に、路車間マスタ鍵を更新する。図23に戻る。通常メッセージ送信時は、鍵情報のフラグに6(2進:0110)がセットされる。すなわち、通信鍵および鍵IDが設定される。通信鍵には、現路車間マスタ鍵で暗号化された通信鍵(乱数)が、鍵IDに通信鍵を暗号化している路車間マスタ鍵のバージョン情報がセットされる。路車間マスタ鍵更新時は、鍵情報のフラグに14(2進:1110)がセットされる。すなわち、マスタ鍵、通信鍵および鍵IDが設定され、マスタ鍵に暗号化されたマスタ鍵が、通信鍵に現路車間マスタ鍵で暗号化された通信鍵(乱数)が、鍵IDに通信鍵を暗号化している路車間マスタ鍵のバージョン情報がセットされる。なお、鍵IDに通信鍵を暗号化している路車間マスタ鍵のバージョンをセットすることなく、路車間マスタ鍵の更新の判定ができれば、鍵IDを使用する必要がない。鍵情報のフラグには、通常メッセージ送信時は4(2進:0100)が、路車間マスタ鍵更新時は12(2進:1100)がセットされることになる。
【0149】
図29は、実施例2に係る通信システム500を用いた車車間通信における通常のメッセージ送受信手順を説明するための図である。端末装置10の暗復号部156は、少なくとも一つの共通鍵テーブルに格納された複数の通信鍵の中から一つの通信鍵をランダムに選択する。暗復号部156は、平文の送信データに対して当該通信鍵を用いてMACを生成し、MAC付きの送信データを暗号化する。セキュリティ処理部15は、暗号化送信データと、選択された通信鍵の鍵IDを格納したパケット信号を生成する。当該パケット信号は、MACフレーム処理部14および変復調部13を経て、RF部12からアンテナ11を介して外部に報知される。
【0150】
別の端末装置10のRF部12は、当該パケット信号をアンテナ11を介して受信する。当該パケット信号は、変復調部13およびMACフレーム処理部14を経て、セキュリティ処理部15に渡される。暗復号部156は、当該パケット信号に格納された鍵IDにより特定される通信鍵を共通鍵テーブルから読み出し、当該パケット信号に格納された暗号化送信データを、当該通信鍵で復号し、MAC検証する。MAC検証が成功したら、暗号化送信データは平文の送信データに復元される。
【0151】
このメッセージ送受信方法には以下に示す様々なメリットがある。まず、静的に通信鍵を使用するため、上述した路車間通信におけるメッセージ送受信方法より、データ通信量を抑えられる。また、複数の通信鍵を保持しておくことにより、通信路中から通信鍵が漏洩するリスクを小さくできる。また、共通鍵テーブルが漏洩した場合、新バージョンの通信鍵テーブルを追加することにより、セキュリティ低下を抑えられる。
【0152】
図30は、車車間通信において生成されるパケットに含まれるセキュリティフレームのデータ構造の一例を示す。当該セキュリティフレームのデータ構造では、ヘッダとして「バージョン」、「メッセージタイプ」、「鍵ID」および「NONCE」が配置され、その後に「ペイロード」が配置され、最後にフッタとして「MAC」が配置される。この例では、「ペイロード」がMAC対象である。「鍵ID」により特定される共通鍵テーブル内の通信鍵により「MAC」が生成され、当該通信鍵により「ペイロード」および「MAC」が暗号化されて、秘匿される。
【0153】
図31は、共通鍵テーブルのフォーマットを示す。共通鍵テーブルの「FIeld」には、「Version」、「Table ID」、「Number of key」、「Table Master」および「Key list」が設けられる。「Key list」には「Key 0」〜「Key 15」が設けられる。なお、一つの共通鍵テーブルに含まれる鍵の数は16に限るものではない。
【0154】
「Version」、「Table ID」および「Number of key」は、1バイトの領域が定義される。「Table Master」、「Key 0」〜「Key 15」は、16バイトの領域が定義される。
【0155】
「Table ID」にはテーブルIDがセットされる。「Number of key」にはテーブル内の鍵の数がセットされる。「Table Master」にはテーブル更新鍵がセットされる。「Key 0」には鍵番号0のAES鍵がセットされる。「Key 1」には鍵番号1のAES鍵がセットされる。以下、「Key 15」まで同様である。なお、AES以外の共通鍵を用いてもよい。また、共通鍵テーブルに含まれる鍵の数が、一定の場合「Number of key」は省略してもよい。さらには、テーブル更新鍵は、事前に共有している鍵として「Table Master」を省略してもよい。
【0156】
図32は、共通鍵テーブルの運用方法の一例を示す。図32では、端末装置10が四つの共通鍵テーブルを格納可能な記憶領域を保持する例を描いている。もちろん、端末装置10が保持する共通鍵テーブルの数は四つに限るものではない。初期状態(出荷時)には、端末装置10には一つの共通鍵テーブル(バージョン=1、テーブルID=1)が保持される。送信側の端末装置10はこの共通鍵テーブル(バージョン=1、テーブルID=1)から一つの通信鍵を選択して、MAC生成および暗号化に使用する。
【0157】
この共通鍵テーブル(バージョン=1、テーブルID=1)が漏洩した場合またはその可能性が発生した場合、新たな共通鍵テーブル(バージョン=1、テーブルID=2)が追加される。送信側の端末装置10はこの最新の共通鍵テーブル(バージョン=1、テーブルID=2)から一つの通信鍵を選択して、MAC生成および暗号化に使用する。同様の事象が発生した場合、共通鍵テーブル(バージョン=1、テーブルID=3)、共通鍵テーブル(バージョン=1、テーブルID=4)の順に新たな共通鍵テーブルが追加される。
【0158】
四つの共通鍵テーブルが端末装置10に保持された後、最後に追加された共通鍵テーブル(バージョン=1、テーブルID=4)が漏洩した場合またはその可能性が発生した場合、一番古い共通鍵テーブル(バージョン=1、テーブルID=1)に、新たな共通鍵テーブル(バージョン=2、テーブルID=1)が上書き(更新)される。以下、この処理が繰り返される。なお、図32において太線で囲われた共通鍵テーブルは、送信に使用されるテーブルであり、正規認証対象のテーブルであることを示し、細線で囲われた共通鍵テーブルは、受信専用のテーブルであり、準認証対象のテーブルであることを示す。このように、共通鍵テーブルを運用することにより、互換性を保ち、矛盾のない運用を実現できる。
【0159】
図33は、共通鍵テーブルの追加または更新を説明するための図である。本実施例では、追加または更新される共通鍵テーブルは、システム運用管理機関のシステム運用管理装置300により生成される。システム運用管理装置300は、当該共通鍵テーブルをテーブル更新鍵で暗号化する。なお、当該共通鍵テーブルには当該テーブル更新鍵も格納される。さらに、不正な端末装置10の情報もシステム運用管理装置300に集められ、システム運用管理装置300は上述した機器ネガリストも生成する。
【0160】
システム運用管理装置300は、路車間サービス提供者の路車間サービス提供者端末装置400およびサービス工場のサービス工場端末装置450に、上述した、機器ネガリスト、暗号化共通鍵テーブルおよびテーブル更新鍵をそれぞれ提供する。路車間サービス提供者端末装置400は、システム運用管理装置300から受けつけた機器ネガリスト、暗号化共通鍵テーブルおよびテーブル更新鍵を基地局装置20に提供する。サービス工場は、主に、自動車のメンテナンスを行う施設である。サービス工場のサービス工場端末装置450は、施設内に設置している小電力基地局装置451に、システム運用管理装置300から受けつけた機器ネガリスト、暗号化共通鍵テーブルおよびテーブル更新鍵を提供する。
【0161】
小電力基地局装置451は、リアルタイムの道路情報を端末装置10に報知する路側機ではなく、特定の端末装置10に共通鍵テーブルなどのシステム運用に関する情報を無線送信する専用機である。なお、サービス工場から端末装置10に記録メディアを介して、システム運用に関する情報を提供してもよい。
【0162】
路車間サービス提供者端末装置400から機器ネガリスト、暗号化共通鍵テーブルおよびテーブル更新鍵を受けつけた基地局装置20は、端末装置10から機器IDおよびテーブルIDを取得する。そして、その機器IDおよびテーブルIDに、路車間サービス提供者端末装置400から受け付けたテーブル更新鍵を付加し、それらを暗号化する。当該基地局装置20は、暗号化した機器ID、テーブルIDおよびテーブル更新鍵を格納したパケット信号を報知する。また、当該基地局装置20は、路車間サービス提供者端末装置400から受けつけた暗号化共通鍵テーブルを報知する。なお、機器ネガリストに登録されている端末装置10の機器IDを受け付けた場合、これらの処理は実行されない。
【0163】
小電力基地局装置451も、当該基地局装置20と同様に、サービス工場端末装置450から受けつけた暗号化共通鍵テーブルと、テーブル更新鍵を端末装置10に送信する。なお、小電力基地局装置451では、電波が届く範囲が制限されるため、当該テーブル更新鍵を暗号化して送信する必要性は小さく、当該テーブル更新鍵を暗号化せずに送信してもよい。
【0164】
端末装置10は、基地局装置20または小電力基地局装置451から受信した暗号化共通鍵テーブルを、同様に受信したテーブル更新鍵で復号する。なお、基地局装置20と端末装置10間の暗号化共通鍵テーブルの追加または更新手順の詳細は後述する。図33においても図27と同様に、システム運用管理機関と路車間サービス提供者間、システム運用管理機関とサービス工場間、路車間サービス提供者と基地局装置20間およびサービス工場と端末装置10間の共通鍵テーブルおよびテーブル更新鍵の受け渡しは、通信システム500以外のバックインフラを用いて行われる。
【0165】
図34は、実施例2に係る通信システム500を用いた路車間通信における共通鍵テーブルの追加または更新手順を説明するための図である。図34にて、基地局装置20(路側機)が、追加または更新用の暗号化共通鍵テーブルおよびそのテーブル更新鍵、ならびに機器ネガリストを保持していることを前提とする。当該基地局装置20は、端末装置10(車載器L)から、その機器ID(L)およびテーブルID(k)を格納したパケット信号を受信する。ここで、テーブルID(k)は現在使用されている最新の共通鍵テーブルのテーブルIDを示す。
【0166】
基地局装置20の鍵更新部258は、受信したパケットに格納された機器ID(L)が機器ネガリストに登録されているか否かをチェックする。登録されている場合、以降の処理は実行されない。登録されていない場合、暗号部257は、端末装置10から受信した機器ID(L)およびテーブルID(k)に、テーブル更新鍵(m)を連結して、現在使用中の最新の共通鍵テーブルのテーブル更新鍵(k)で暗号化する。その暗号化データはパケット信号に格納される。当該パケット信号は、路車間通信として外部に報知される。それとともに、暗号化されたテーブル更新鍵(m)に対応する暗号化された共通鍵テーブル(m)もパケット信号に格納され、路車間通信により外部に報知される。
【0167】
端末装置10では、受信されたパケット信号から暗号化された機器ID(L)、テーブルID(k)およびテーブル更新鍵(m)が取り出され、復号部157はそれらをテーブル更新鍵(k)で復号する。また、受信された別のパケット信号から暗号化共通鍵テーブル(m)が取り出され、復号部157は暗号化共通鍵テーブル(m)をテーブル更新鍵(m)で復号する。鍵更新部158は、復号された共通鍵テーブル(m)を、最新の共通鍵テーブルとしてテーブル格納領域に追加または更新する。なお、共通鍵テーブル(m)にMACが付加されている場合、テーブル更新鍵(m)でMACを検証し、成功したことを条件に追加または更新する。
【0168】
このように、共通鍵テーブルはデータ量が多いため、その追加または更新には路車間通信だけでなく、専用基地局装置なども用いると効果的である。また、端末装置10および基地局装置20が現に保持するテーブル更新鍵を用いることにより、リスク分散を図ることができる。また、機器ネガリストを用いることにより、不正な端末装置への新たな共通鍵テーブルの提供を回避することができ、メッセージの漏洩リスクを低減できる。
【0169】
以上説明したように実施例2によれば、共通鍵暗号化方式を用いた通信システムにおいて、路車間通信と車車間通信とで異なる運用方式を併用することにより、通信システム全体のセキュリティを効率的に向上させることができる。より具体的には、基地局装置から報知されるパケット信号を、端末装置から報知されるパケット信号よりセキュリティレベルの高い運用方式で暗号化する。前者のパケット信号は比較的データサイズに余裕があるが、後者のパケット信号は余裕が小さい。また、前者のパケット信号は後者のパケット信号より、高い信頼性が要求されるデータが含まれることが多い。
【0170】
このように、路車間通信と車車間通信の両方に共通鍵暗号化方式を用いることにより、処理負荷を軽減することができ、リアルタイム性を確保しつつ、低コストな通信システムを構築できる。この通信システムにおいて、情報の発信主体により暗号化の運用方法を変えることにより、効率的なセキュリティシステムを構築できる。
【0171】
また、路車間通信で使用する路車間マスタ鍵は1つとして説明したが、車車間通信で使用する通信鍵と同じように共通鍵テーブルを用いるようにしてもよい。この時、車車間の通信鍵と、路車間通信で使用する路車間マスタ鍵は異なった鍵を選択することが望ましい。また、共通鍵テーブルを指定するために、図23の鍵IDはオプションから必須となる。さらには、共通鍵テーブルを更新する毎にテーブル更新鍵を更新するとしたが、事前に共有したテーブル更新鍵の更新を行わないようにしてもよい。この場合、端末装置10毎にユニークなテーブル更新鍵を保持するようにすれば、安全性は担保される。以上、実施例2を説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【0172】
上記図32図34を参照しながら説明した共通鍵テーブルの運用方法は、基本的に共通鍵テーブルを端末装置10に一つずつ提供するものであった。以下に説明する変形例では、複数の共通鍵テーブルを一度に端末装置10に提供し、端末装置10は提供された複数の共通鍵テーブルを保持する。そして、端末装置10は保持している使用可能な共通鍵テーブルが無くなるまで、その複数の共通鍵テーブルを順次切り替えて使用する。そして、端末装置10は保持している使用可能な共通鍵テーブルが無くなると、一つ以上の新たな共通鍵テーブルの提供を受けて、それを保持する。また、管理システム(図示されない。)からの要求により、一つ以上の新たな共通鍵テーブルの提供を受けて、それを保持する。
【0173】
(実施例3)
図35(a)−(b)は、実施例3に係る、端末装置10に保持された共通鍵テーブルを示す図である(その1)。図36(a)−(b)は、実施例3に係る、端末装置10に保持された共通鍵テーブルを示す図である(その2)。実施例3では、路車間通信で使用する路車間マスタ鍵も、車車間通信で使用されている通信鍵と同様に共通鍵テーブルから選択されるものとする。以下、端末装置10は八つの共通鍵テーブルを格納可能な記憶領域(以下、格納領域という)を有し、五つの共通鍵テーブルを保持する例を説明する。当該実施例3では、一つの共通鍵テーブルに保持される通信鍵の数は八つである。なお、端末装置10に保持される共通鍵テーブルの数および一つの共通鍵テーブルに保持される通信鍵の数は複数であればよく、前述の数に限定されない。共通鍵テーブルの格納領域の数は、端末装置10に保持される共通鍵テーブルの数以上であればよい。すなわち、テーブルIDにより識別する数と共通鍵テーブルの格納領域の数は一致している必要はなく、多くても少なくてもよい。また、上述のごとく車車間の通信鍵のみでなく、路車間マスタ鍵にも適用可能できる。
【0174】
共通鍵テーブルの管理はバージョン及びテーブルIDにより行われる。バージョンの異なる同じテーブルIDで特定される共通鍵テーブルが同時に使用されることはない。必ず、バージョンが大きい方が使用される。テーブルIDはN(Nは自然数)の剰余系として設定される。本実施例3ではN=8である。たとえば、1番目の共通鍵テーブルと9番目の共通鍵テーブルのテーブルIDは0となる。バージョンは同じテーブルIDの新しい共通鍵テーブルが生成される度にカウントアップしていく。したがって、前者では0、後者では1となる。
【0175】
格納領域に保持される複数の共通鍵テーブルのうち、一つが送信用の共通鍵テーブル(以下、送信用鍵テーブルという)に指定され、複数が受信用の共通鍵テーブル(以下、受信用鍵テーブルという)に指定される。複数の受信用鍵テーブルは送信用鍵テーブルを含み、送信用鍵テーブルよりn(nは自然数、n<N)世代未来までの共通鍵テーブルを含む。なお、複数の受信用鍵テーブルはm(mは0または自然数、m+n<N)世代過去までの共通鍵テーブルを含んでもよい。i世代未来の共通鍵テーブルのテーブルIDは、{(送信用鍵テーブルのテーブルID+i) mod N}で、j世代前の共通鍵テーブルのテーブルIDは、{(送信用鍵テーブルのテーブルID−j) mod N}で算出される。なお、i世代未来の共通鍵テーブルのバージョンは、少なくとも、テーブルIDが送信用鍵テーブルのテーブルIDより大きい場合、送信用鍵テーブルのバージョン以上、テーブルIDが送信用鍵テーブルのテーブルIDより小さい場合、送信用鍵テーブルのバージョンを越える値である必要がある。また、j世代過去の共通鍵テーブルのバージョンは、少なくとも、テーブルIDが送信用鍵テーブルのテーブルIDより大きい場合、送信用鍵テーブルのバージョン未満、テーブルIDが送信用鍵テーブルのテーブルIDより小さい場合、送信用鍵テーブルのバージョン以下である必要がある。なお、格納領域に保持される同じテーブルIDの共通鍵テーブルが複数保持されている場合には、バージョンの値が小さいもの(古いもの)は、無効(保持していない)として扱う。
【0176】
システム運用管理装置300が送信用鍵テーブルの切替を指示しても、全ての端末装置10において送信用鍵テーブルが同時に切り替わるわけではない。端末装置10間において送信用鍵テーブルが切り替わるタイミングに時間差が生じる。たとえば、長期間使用されていない車両100に搭載された端末装置10では、二つ以上過去の共通鍵テーブルが送信用鍵テーブルに設定されている可能性もある。この車両100が使用されると別の車両100に搭載された端末装置10は、二世代過去の共通鍵テーブルで処理されたパケット信号を受信する。暗号化システムの運用上、受信用鍵テーブルの範囲が狭いほどセキュリティが高くなるが、正当な端末装置10からの送信データを復号できないケースが多くなる。両者の要請を考慮して受信用鍵テーブルの範囲は設定される。
【0177】
送信用鍵テーブルの切替周期が長い場合(たとえば、数年)、受信用鍵テーブルは、送信用鍵テーブルと次の共通鍵テーブル(n=1)で構成されるとよい。また、送信用鍵テーブルの切替周期が短い場合(たとえば、一年以内)、受信用鍵テーブルは、送信用鍵テーブルと、次の共通鍵テーブル(n=1)と、さらにそれ以降の共通鍵テーブル(n>1)とで構成されるとよい。切替期間が短いほどnを大きくし、多くの共通鍵テーブルを受信用鍵テーブルに組み入れるとよい。切替期間が短い場合、複数の端末装置10間で送信用鍵テーブルのばらつきが大きくなる。これに対し、受信用鍵テーブルに組み入れる共通鍵テーブルの数を増やすことにより、送信用鍵テーブルのミスマッチを減らすことができる。また、mは1または0が適当である。
【0178】
図35(a)は、車車間通信における共通鍵テーブルを用いた暗号化サービスの運用開始〜1年目に出荷される端末装置10が保持する共通鍵テーブルを示す。図35(b)は、2〜3年目に出荷される端末装置10が保持する共通鍵テーブルを示す。図36(a)は、10〜11年目に出荷される端末装置10が保持する共通鍵テーブルを示す。図36(b)は、12〜13年目に出荷される端末装置10が保持する共通鍵テーブルを示す。
【0179】
運用開始〜1年目は共通鍵テーブル(バージョン=0、テーブルID=0)が送信用鍵テーブルとして使用される。各端末装置10は、共通鍵テーブル(バージョン=0、テーブルID=0)から一つの通信鍵を選択して車車間通信に使用する。2〜3年目は共通鍵テーブル(バージョン=0、テーブルID=1)が送信用鍵テーブルとして使用される。4〜5年目は共通鍵テーブル(バージョン=0、テーブルID=2)が送信用鍵テーブルとして使用される。このように本実施例3では2年ごとに送信用鍵テーブルを順次切り替える運用を行う。この共通鍵テーブルの切替はシステム運用管理装置300により統一的に管理される。
【0180】
各端末装置10は出荷時に五つの共通鍵テーブルを保持するため、基本的に出荷から8〜10年間、各端末装置10は共通鍵テーブルを追加更新せずに暗号化システムを使用できる。ただし、出荷から8〜10年目以降もこの暗号化システムを使用するためには、8〜10年経過前に新たな共通鍵テーブルを追加更新する必要がある。すなわち、使用可能な共通鍵テーブルが無くなる前に、新たな共通鍵テーブルを追加更新する必要がある。
【0181】
図37(a)−(b)は、実施例3に係る共通鍵テーブルの切替の様子を示す図である(その1)。図35(a)に従って、出荷される端末装置10における共通鍵テーブルの切替の様子である。図38(a)−(b)は、実施例3に係る共通鍵テーブルの切替の様子を示す図である(その2)。図36(c)に従って、出荷される端末装置10における共通鍵テーブルの切替の様子である。図37(a)では共通鍵テーブル(バージョン=0、テーブルID=0)が送信用鍵テーブルに指定されている。この状態で送信用鍵テーブルの切替が指示されると、鍵更新部158は、図37(b)に示すように送信用鍵テーブルを共通鍵テーブル(バージョン=0、テーブルID=1)に切り替える。図38(a)では共通鍵テーブル(バージョン=0、テーブルID=7)が送信用鍵テーブルに指定されている。この状態で送信用鍵テーブルの切替が指示されると、鍵更新部158は、図38(b)に示すように送信用鍵テーブルを共通鍵テーブル(バージョン=1、テーブルID=0)に切り替える。
【0182】
このように、送信用鍵テーブルの切替が指示されると、鍵更新部158は、テーブルIDがN(本実施例3では8)の剰余系において次の値に切り替える。ただし、切替後の共通鍵テーブルのバージョンが同じ、または+1である必要がある。図37(a)−(b)に示す例では切替前後でバージョンが同じである。図38(a)−(b)に示す例では切替前後でバージョンが+1されている。複数のバージョンの共通鍵テーブルが格納領域に併存する場合、実装上、送信用鍵テーブルのバージョンより古いバージョンの共通鍵テーブルは存在しないものとして扱えばよい。なお、図37(a)−(b)の切替後、さらに3回の切替が行われると、送信用鍵テーブルが共通鍵テーブル(バージョン=0、テーブルID=4)に切り替わることになる。このとき、格納領域には次世代未来の共通鍵テーブルが保持されていなくなるので、新たに数世代未来の共通鍵テーブルを追記することで、図35(a)に従って、出荷される端末装置10の共通鍵テーブルの更新を行うことができる。なお余裕をみて、送信用鍵テーブルが共通鍵テーブル(バージョン=0、テーブルID=3)または(バージョン=0、テーブルID=4)のいずれかのときに更新するものとしてもよい。実施例3では、実施例2における共通鍵テーブルの更新による更新周期が長いこと(実施例3では実施例2の5倍)、端末装置10によって更新のタイミングが異なり、更新に時間的余裕があることから、路車間通信を使用しない、メンテナンスによる共通鍵テーブルの更新が行えるので、路車間通信のトラフィックを削かない運用ができるといった利点がある。
【0183】
図39(a)−(b)は、実施例3に係る共通鍵テーブルの緊急更新の様子を示す図である。図40(a)−(b)は、実施例3に係る共通鍵テーブルの緊急更新後の切替の様子を示す図である。図35(a)に従って、出荷される端末装置10における共通鍵テーブルの緊急更新および緊急更新後の切替の様子である。緊急時(たとえば、共通鍵テーブルの漏洩発生時)には、通常の切替期間に関係なく、鍵更新部158は、その時点における送信用鍵テーブルより世代的に未来の共通鍵テーブルを保持する場合、それらを更新する。また、鍵更新部158は、更新した共通鍵テーブルより世代的に未来の新たな共通鍵テーブルを追加する。更新または追加される共通鍵テーブルは、システム運用管理装置300から提供される。更新または追加される共通鍵テーブルのバージョンは、送信用鍵テーブルのバージョンに+1されている。なお、テーブルIDがNの剰余系であることから明らかなように、世代的に未来の共通鍵テーブルのバージョンは、世代的に未来の共通鍵テーブルのテーブルIDが送信用鍵テーブルのテーブルIDより一つ小さいとき、送信用鍵テーブルのバージョンに+2されることになる。
【0184】
図39(a)は共通鍵テーブル(バージョン=0、テーブルID=2)が送信用鍵テーブルであるときに漏洩が発生した場合の例を示している。この漏洩に対して緊急更新が実行される。図39(b)は緊急更新後の格納領域の状態を示す。図39(b)に示す例では鍵更新部158は、送信用鍵テーブルの次の共通鍵テーブル(バージョン=0、テーブルID=3)を共通鍵テーブル(バージョン=1、テーブルID=3)に書き換え、その次の共通鍵テーブル(バージョン=0、テーブルID=4)を共通鍵テーブル(バージョン=1、テーブルID=4)に書き換える。さらに、共通鍵テーブル(バージョン=1、テーブルID=5)及び共通鍵テーブル(バージョン=1、テーブルID=6)を追加する。すなわち、送信用鍵テーブルより世代的に未来に、四つの新たな共通鍵テーブルが格納されることになる。図39(b)ではこの四つの共通鍵テーブルを太線で描いている。
【0185】
図40(a)は図39(b)と同じ図である。図40(b)は四つの新たな共通鍵テーブルが更新追加された後、送信用鍵テーブルの切替指示に応じて、送信用鍵テーブルが共通鍵テーブル(バージョン=0、テーブルID=2)から共通鍵テーブル(バージョン=1、テーブルID=3)に切り替わる様子を描いている。
【0186】
図41は、実施例3に係る送信用鍵テーブルの第1切替例を示す図である。第1切替例は、受信用鍵テーブルに送信用鍵テーブルとそれより過去および未来の共通鍵テーブルが組み入れられる場合に適用される。以下の説明では、過去および未来の共通鍵テーブルがそれぞれ一つ組み入れられる場合を想定する。すなわち、受信鍵テーブルが三つ存在する場合を想定する。なお、未来の共通鍵テーブルについては複数、組み入れられてもよい。
【0187】
通常時、鍵更新部158は通常切替期間(本実施例3では2年)ごとに送信用鍵テーブルを切り替える。緊急事態発生時、鍵更新部158は現在の送信用鍵テーブルを維持しつつ、それより世代的に未来の共通鍵テーブルをシステム運用管理装置300から提供される新たな共通鍵テーブルに更新する。この更新を本明細書では緊急更新という。この更新期間は、通常切替期間の切替残期間に関係なく、送信用鍵テーブルの更新に必要な期間を確保できるように設定される。たとえば、全ての端末装置10の8割の端末装置10が更新完了する期間に設定されてもよい。残りの端末装置10はリコール品として個別に更新する。
【0188】
第1切替例では、緊急更新時、鍵更新部158は過去の共通鍵テーブルを無効化する。システム運用管理装置300は、過去の共通鍵テーブルの削除指令を発行するか、端末装置10に格納される全ての共通鍵テーブルを書き換えるための新たな共通鍵テーブルを提供する。後者の場合、鍵更新部158は格納される全ての共通鍵テーブルを新たな共通鍵テーブルに上書きする。
【0189】
緊急更新期間終了後の、送信用鍵テーブルの最初の切替期間(以下、緊急切替期間という)は、通常切替期間より短く設定される。すなわち、緊急更新期間終了後に使用する最初の送信用鍵テーブルの利用期間は、通常の利用期間より短く設定される。第1切替例では、送信用鍵テーブルより一単位過去の共通鍵テーブルも受信用鍵テーブルに含まれる。したがって、緊急切替期間では緊急事態発生時に送信用鍵テーブルであった共通鍵テーブルを用いて暗号されたデータの受信を許容することになる。この共通鍵テーブルは漏洩または漏洩の可能性があるため、できるだけその受信を許容する期間を短くすることが好ましい。そこで、第1切替例では緊急切替期間が通常切替期間より短く設定される。緊急切替期間後の切替期間では漏洩または漏洩の可能性がある共通鍵テーブルを用いて暗号されたデータの受信を許容しないため、緊急切替期間後の切替期間は通常切替期間となる。
【0190】
図42は、実施例3に係る送信用鍵テーブルの第2切替例を示す図である。第2切替例は、受信用鍵テーブルに送信用鍵テーブルとそれより未来の共通鍵テーブルが組み入れられる場合に適用される。
【0191】
通常時、鍵更新部158は通常切替期間ごとに送信用鍵テーブルを切り替える。緊急事態発生時、鍵更新部158は現在の送信用鍵テーブルを維持しつつ、それより世代的に未来の共通鍵テーブルを緊急更新する。第2切替例では、第1切替例のように緊急切替期間は設定されない。第2切替例では、送信用鍵テーブルより過去の共通鍵テーブルが受信用鍵テーブルに含まれないため、漏洩または漏洩の可能性がある共通鍵テーブルを用いて暗号化されたデータの受信を許容しない。したがって、緊急更新期間後の最初の切替期間を通常切替期間より短くする必要がない。
【0192】
図43は、実施例3に係る共通鍵テーブルの追加または更新を説明するための図である。システム運用管理機関のシステム運用管理装置300は、複数の共通鍵テーブルを生成し、車両メーカの共通鍵テーブル設定装置460に提供する。共通鍵テーブル設定装置460は、提供された複数の共通鍵テーブルを、車両100に新規に搭載された端末装置10に書き込む。この書き込む複数の共通鍵テーブルの種類は出荷時期により異なる。
【0193】
システム運用管理装置300は、送信用鍵テーブルの切替タイミングが到来すると、路車間サービス提供者端末装置400にテーブル切替指示を発行する。路車間サービス提供者端末装置400は、システム運用管理装置300から受け付けたテーブル切替指示を基地局装置20に伝達する。基地局装置20は、路車間サービス提供者端末装置400から受け付けたテーブル切替指示を路車間通信でブロードキャスト送信する。車両100に既に搭載された端末装置10は、そのテーブル切替指示を受け付けると、送信用鍵テーブルを切り替える。また、端末装置10は、受け付けたテーブル切替指示を車車間通信でブロードキャスト送信する。別の端末装置10は、テーブル切替指示を受け付けると、送信用鍵テーブルを切り替える。システム運用管理装置300からのテーブル切替指示は、共通鍵テーブル設定装置460および新規の端末装置10を介して既存の端末装置10に伝達されてもよい。
【0194】
なお、送信用鍵テーブルの切替タイミングは端末装置10が判断して切り替えていくようにしてもよい。ここでは、路車間通信で使用するマスタ鍵も、車車間通信で使用されている通信鍵と同様に共通鍵テーブルから選択されるものとする。また、図23における鍵IDは、路車間通信でも使用する。なお、予め車車間通信で使用されている通信鍵とマスタ鍵の範囲を分けておいてもよい。この場合、双方の共通鍵テーブルに帰属する鍵の数が同じである必要はなく、鍵寿命の観点から、通信鍵より路車間マスタ鍵は少なくてもよい。
【0195】
システム運用管理装置300は、送信用鍵テーブルの切替タイミングが到来すると、路車間サービス提供者端末装置400にテーブル切替指示を発行する。路車間サービス提供者端末装置400は、システム運用管理装置300からテーブル切替指示を受け取ると、基地局装置20に送信用鍵テーブルのテーブル切替指示を発行する。基地局装置20は、テーブル切替指示を受け取ると、自身の使用する送信用鍵テーブルを切り替える。そして、切り替えた共通鍵テーブルよりマスタ鍵を選択して、メッセージ形式が認証付き暗号化データまたは認証付きデータのセキュリティフレームを含むパケット信号を報知する。
【0196】
車両100に既に搭載された端末装置10は、そのパケット信号を受信すると受信処理を行う。セキュリティ処理部15は、受信したパケット信号に含まれるセキュリティフレームのMACを検証する。検証に成功すると、受信したセキュリティフレームの鍵IDからテーブルIDを取り出して、自身の送信用鍵テーブルのテーブルIDと比較する。自身の送信用鍵テーブルより未来の世代の共通鍵テーブルを用いている場合、送信用鍵テーブルをそれに切り替える。また、他の端末装置10から車車間通信で受信したパケット信号に基づいて切り替えるようにしても良い。
【0197】
車両100に既に搭載された端末装置10は、前述のパケット信号を受信すると受信処理を行う。セキュリティ処理部15は、受信したパケット信号に含まれるセキュリティフレームのMACを検証する。検証に成功すると、受信したセキュリティフレームの鍵IDからテーブルIDを取り出して、自身の送信用鍵テーブルより未来の世代の共通鍵テーブルを用いている場合、そのテーブルIDと送信元の機器IDを保持する。そして、例えば、10台の他の端末装置10から、未来の世代の同じ共通鍵テーブルを用いていると判断された場合、送信用鍵デーブルをそれに切り替える。両者の切り替え判断は併用できる。新規の端末装置10の送信用鍵テーブルは、事前に切り替えて提供されるので、基地局装置20が無い場所であっても、切替を伝搬させることができる。すなわち、基地局装置20が無い場所を移動する車両であっても、切替後の他の端末装置10からのパケット信号を受信することによって切り替わる。なお、MAC検証は、発信元の真正性が確認できない点に鑑み、異なる複数(例えば10台)の基地局装置20または他の端末装置10から受信したパケット信号の検証の成功に基づいて、送信用鍵デーブルを切り替えるようにする。また、実施例1およびその変形例1〜変形例6のごとく、路車間通信のパケット信号に電子署名がついている場合、電子署名は発信元の真正性が確認できることに鑑みて、受信したパケット信号に対する電子署名の検証成功時と、MACの検証成功時の切替の判断基準を変えてもよい。例えば、基地局装置20から受信したパケット信号に含まれるセキュリティフレームの電子署名の検証に成功したとき、あるいは、複数台(例えば10台)の他の端末装置10から受信したパケット信号に含まれるセキュリティフレームのMACの検証に成功したときとなる。
【0198】
また、緊急事態発生時、システム運用管理装置300は新しい共通鍵テーブルを、路車間サービス提供者端末装置400および基地局装置20を介して既存の端末装置10に伝達するとともに、共通鍵テーブル設定装置460および新規の端末装置10を介して既存の端末装置10に伝達する。共通鍵テーブルを更新する際、図32図33に示した手法を用いることができる。
【0199】
なお、共通鍵テーブルの更新は次のように行われてもよい。まず、端末装置10は自己の機器IDを含む更新要求信号をシステム運用管理装置300に送信する。システム運用管理装置300は、各機器IDに対応する公開鍵で新たな共通鍵テーブルを暗号化し、端末装置10に送信する。両者の通信は、路車間サービス提供者端末装置400および基地局装置20を介して実行されてもよいし、その他のネットワークを介して実行されてもよい。端末装置10は、暗号化された共通鍵テーブルを受信すると、ユニークな秘密鍵で復号する。
【0200】
また、各機器IDに対応する公開鍵にかえて各機器IDに対応する共通鍵を使用しても良い。システム運用管理装置300は、各機器IDを受け取って、その機器IDに対応する共通鍵を使用して新たな共通鍵テーブルを暗号化し、端末装置10に送信する。このとき、端末装置10とシステム運用管理装置300間の通信路については特に限定を加えない。
【0201】
以上説明したように本実施例3によれば、複数の共通鍵テーブルを一度に端末装置10に提供し、テーブル切替指示に応じて切り替えて使用することにより、共通鍵テーブルの更新追加回数を削減できる。したがって、漏洩のリスクを低減できる。なお、漏洩が発生した場合、共通鍵テーブルを緊急更新することにより、セキュリティを確保できる。
【符号の説明】
【0202】
10 端末装置、 11 アンテナ、 12 RF部、 13 変復調部、 14 MACフレーム処理部、 15 セキュリティ処理部、 151 検証部、 151a 証明書検証部、 151b メッセージ検証部、 151c ダイジェスト保持部、 151d 認証鍵保持部、 151e ステータス管理部、 152 復号部、 161 受信処理部、 162 通知部、 17 データ生成部、 18 記憶部、 19 制御部、 20 基地局装置、 21 アンテナ、 22 RF部、 23 変復調部、 24 MACフレーム処理部、 25 セキュリティ処理部、 26 データ生成部、 251 署名部、 252 暗号部、 27 ネットワーク通信部、 28 記憶部、 29 制御部、 100 車両、 202 エリア、 204 エリア外、 500 通信システム、 156 暗復号部、 157 復号部、 158 鍵更新部、 256 暗復号部、 257 暗号部、 258 鍵更新部、 27 ネットワーク通信部、 28 記憶部、 29 制御部、 300 システム運用管理装置、 400 路車間サービス提供者端末装置、 450 サービス工場端末装置、 451 小電力基地局装置。
【産業上の利用可能性】
【0203】
本発明に係る端末装置はITSに利用可能である。
図1
図2
図3
図4
図5
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図24
図25
図26
図27
図29
図33
図34
図35
図36
図37
図38
図39
図40
図41
図42
図43
図6
図23
図28
図30
図31
図32