JP6195260B2 - 処理装置 - Google Patents

Description

本発明は、通信技術に関し、特に所定の情報が含まれた信号を送受信する処理装置に関する。

自動車向け無線通信の形態は、路車間通信、車車間通信（車路車間通信を含む）に大別される。いずれの通信も、交差点での出会い頭の衝突やコーナー先の渋滞による追突防止などに活用できる。たとえば、車車間通信においてＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）などによって現在の位置情報をリアルタイムに検出し、その位置情報を車載器同士で交換しあうことによって、交差点での衝突防止を図ることができる。路車間通信では、交差点や路側に路側機が設置され、この路側機から車載器に上記のような運転支援情報が送信される。

無線通信は有線通信に比較して通信の傍受や第三者のなりすましによる不正な介入が容易であるため、無線通信ではそれらへの対策が有線通信より重要となる。通信内容の秘匿性を確保するには、通信データに対して暗号方式を利用したメッセージ認証を行う手法が有効である。暗号方式には、大別すると公開鍵暗号方式と共通鍵暗号方式がある。前者は後者と比較し、セキュリティは高いがデータ量が多く、かつ、処理負荷が大きいため実装コストが高くなる。すなわち、両者はトレードオフの関係にある。

特開２００５−２０２９１３号公報 特開２００７−１０４３１０号公報 特開平８−３３１０７５号公報

本発明はこうした状況に鑑みてなされたものであり、その目的は、通信システムのセキュリティを効率的に確保するための技術を提供することにある。

本発明のある態様の端末装置は、無線装置から報知される複数のパケット信号を受信する受信部と、パケット信号に含まれる公開鍵を含む証明書を検証するための第１検証部と、第１検証部で検証されたパケット信号に含まれる証明書を特定する情報と、公開鍵を保持するダイジェスト保持部と、を備える。第１検証部は、ダイジェスト保持部に保持される証明書を特定する情報によって特定される証明書を含むパケット信号が受信されると、当該パケット信号に含まれる暗号鍵を含む証明書の検証をスキップする。

本発明の別の態様の端末装置は、暗号化されたパケット信号を受信する受信部と、パケット信号を復号する復号部と、を備える。パケット信号は、共通鍵暗号方式により暗号化されており、基地局装置から報知されるパケット信号と、他の端末装置から報知されるパケット信号とで異なる運用方式により暗号化される。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、通信システムのセキュリティを効率的に確保することができる。

本発明の実施例１に係る通信システムの構成を示す図である。 図２（ａ）−（ｄ）は、通信システムにおいて規定されるスーパーフレームのフォーマットを示す図である。 図３（ａ）−（ｂ）は、サブフレームの構成を示す図である。 図４（ａ）−（ｆ）は、通信システムにおいて規定される各レイヤのフレームのフォーマットを示す図である。 ＲＳＵパケットの具体例を示す図である。 端末装置に４つのＲＳＵ用コアが搭載される場合において、各ＲＳＵ用コアの処理例を示す図である。 ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の一例を示す図である。 ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の別の例を示す図である。 実施例１に係る基地局装置の構成を示す図である。 実施例１に係る、車両に搭載された端末装置の構成を示す図である。 検証部の構成例１を示す図である。 構成例１に係る検証部が用いられる端末装置のＲＳＵパケットの受信処理を示すフローチャートである。 検証部の構成例２を示す図である。 構成例２に係る検証部が用いられる端末装置のＲＳＵパケットの受信処理を示すフローチャートである。 構成例２に係る検証部が用いられる端末装置の公開鍵証明書の検証処理を示すフローチャートである。 構成例２に係る検証部が用いられる端末装置の電子署名付きメッセージの検証処理を示すフローチャートである。 ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の変形例１を示す図である。 ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の変形例２を示す図である。 ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の変形例３を示す図である。 図２０（ａ）−（ｃ）は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の変形例４を示す図である。 図２１（ａ）−（ｂ）は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の変形例５を示す図である。 図２２（ａ）−（ｃ）は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の変形例６を示す図である。 セキュリティフレームのデータ構造の一例を示す図である。 実施例２に係る基地局装置の構成を示す図である。 実施例２に係る、車両に搭載された端末装置の構成を示す図である。 実施例２に係る通信システムを用いた路車間通信における通常のメッセージ送受信手順を説明するための図である。 実施例２に係る通信システムを用いた路車間通信における路車間マスタ鍵の更新手順を説明するための図である。 路車間通信において生成されるパケットに含まれるセキュリティフレームのデータ構造の一例を示す図である。 実施例２に係る通信システムを用いた車車間通信における通常のメッセージ送受信手順を説明するための図である。 車車間通信において生成されるパケットに含まれるセキュリティフレームのデータ構造の一例を示す図である。 共通鍵テーブルのフォーマットを示す図である。 共通鍵テーブルの運用方法の一例を示す図である。 共通鍵テーブルの追加または更新を説明するための図である。 実施例２に係る通信システムを用いた路車間通信における共通鍵テーブルの追加または更新手順を説明するための図である。 図３５（ａ）−（ｂ）は、実施例３に係る、端末装置に保持された共通鍵テーブルを示す図である（その１）。 図３６（ａ）−（ｂ）は、実施例３に係る、端末装置に保持された共通鍵テーブルを示す図である（その２）。 図３７（ａ）−（ｂ）は、実施例３に係る共通鍵テーブルの切替の様子を示す図である（その１）。 図３８（ａ）−（ｂ）は、実施例３に係る共通鍵テーブルの切替の様子を示す図である（その２）。 図３９（ａ）−（ｂ）は、実施例３に係る共通鍵テーブルの緊急更新の様子を示す図である。 図４０（ａ）−（ｂ）は、実施例３に係る共通鍵テーブルの緊急更新後の切替の様子を示す図である。 実施例３に係る送信用鍵テーブルの第１切替例を示す図である。 実施例３に係る送信用鍵テーブルの第２切替例を示す図である。 実施例３に係る共通鍵テーブルの追加または更新を説明するための図である。

（実施例１）
本発明の実施例１の基礎となった知見は、次の通りである。路車間通信では、車車間通信より公共性が強いため、なりすましやデータ改ざんを防ぐ要請がより大きくなると共に、発信元の正当性の確認ができることが望ましいとされる。そこで、路側機（基地局装置）から車載器（端末装置）に、公開鍵証明書および電子署名付きのデータを格納したパケット信号を報知するシステムが検討されている。

しかしながら、すべてのパケット信号に含まれる公開鍵証明書および電子署名の検証を実行するには高速な処理が必要となり、端末装置に高速のハードウエアを搭載する必要性が発生する。これらの検証処理には公開鍵暗号方式が用いられるため、演算量が多くなり回路規模が増大する要因となる。

実施例１はこうした状況に鑑みてなされたものであり、その目的は、セキュリティを向上させつつ、パケット信号を受信する際の処理負荷を軽減させる技術を提供することにある。

実施例１の一態様の概要は、次の通りである。実施例１のある態様の端末装置は、「無線装置」から報知される複数のパケット信号を受信する受信部と、前記パケット信号に含まれる「公開鍵を含む証明書」を検証するための第１検証部と、前記第１検証部で検証された前記パケット信号に含まれる証明書を特定する情報と、公開鍵を保持するダイジェスト保持部と、を備える。前記第１検証部は、前記ダイジェスト保持部に保持される証明書を特定する情報によって特定される証明書を含むパケット信号が受信されると、当該パケット信号に含まれる公開鍵を含む証明書の検証をスキップする。「無線装置」は、基地局装置であってもよいし、端末装置であってもよい。「公開鍵を含む証明書」は、認証局などの第三者により発行される、公開鍵の正当性とその公開鍵の所有主体を結びつけるものである。

「公開鍵を含む証明書」をパケット信号に含めることにより、セキュリティを向上させることができる。また、「公開鍵を含む証明書」の検証処理を適宜スキップすることにより処理負荷を軽減できる。

前記パケット信号に含まれる署名付きメッセージを検証するための第２検証部と、前記ダイジェスト保持部に保持される証明書を特定する情報によって特定される証明書を含むパケット信号に対する前記第２検証部での検証結果を保持するステータス管理部と、をさらに備えてもよい。前記第２検証部は、前記ダイジェスト保持部に保持される証明書を特定する情報によって特定される証明書を含むパケット信号を検証すると、検証結果を前記ステータス管理部に保持させ、さらに、前記ステータス管理部に検証の成功が保持されている間、当該パケット信号のうちの少なくともひとつのパケット信号の署名付きメッセージの検証をスキップしてもよい。

署名付きメッセージをパケット信号に含めることにより、セキュリティを向上させることができる。また、署名付きメッセージの検証処理を適宜スキップすることにより処理負荷を軽減できる。

前記第２検証部は、当該パケット信号のうちの少なくともひとつのパケット信号の署名付きメッセージの検証をスキップするとき、当該署名付きメッセージを承認と判定してもよい。これによると、処理負荷をさらに軽減できる。

ひとつの無線装置から無線装置信号受信期間に受信される複数のパケット信号のうち、前記証明書が少なくとも無線装置信号受信期間の先頭のパケット信号に含まれていてもよい。前記証明書を特定する特定情報が前記証明書を含まないパケット信号に含まれていてもよい。前記第２検証部は、ひとつの無線装置信号受信期間に受信される複数のパケット信号のうち、先頭のパケット信号に含まれる署名付きメッセージの検証が成功した場合、前記特定情報によって特定される証明書、または、前記特定情報を含む受信したパケット信号の署名付きメッセージの検証をスキップしてもよい。これによると、セキュリティ向上と処理負荷軽減のバランスを図ることができる。

ひとつの無線装置から無線信号受信期間に受信される複数のパケット信号のうち、電子署名が少なくとも無線装置信号受信期間の先頭のパケット信号に含まれていてもよい。メッセージ認証コードが少なくとも無線装置信号受信期間の先頭のパケット信号以外のパケット信号に含まれていてもよい。本端末装置は、パケット信号に含まれる電子署名付きメッセージを検証するための第２検証部と、前記パケット信号以外のパケット信号に含まれるメッセージ認証コード付きメッセージを検証するための第３検証部と、をさらに備えてもよい。これによると、セキュリティ向上と処理負荷軽減のバランスを図ることができる。

本発明の実施例１を具体的に説明する前に、概要を述べる。本発明の実施例１は、交差点や路側などに設置された基地局装置から車両に搭載された端末装置に、情報を提供するために実行される路車間通信、および車両に搭載された端末装置から他の車両に情報を提供するために実行される車車間通信を用いたＩＴＳ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｔｒａｎｓｐｏｒｔ Ｓｙｓｔｅｍｓ）などの通信システムに関する。

ＩＴＳでは、ＩＥＥＥ８０２．１１などの無線ＬＡＮ規格に類した無線通信を用いることが検討されている。そのような無線通信では、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ ｗｉｔｈ Ｃｏｌｌｉｓｉｏｎ Ａｖｏｉｄａｎｃｅ）と呼ばれるアクセス制御機能が使用されている。そのため、当該無線通信では、基地局装置および複数の端末装置によって同一の無線チャネルが共有される。このようなＣＳＭＡ／ＣＡでは、キャリアセンスによって他のパケット信号が送信されていないことを確認した後に、パケット信号がブロードキャストにより送信される（以下、パケット信号のブロードキャストによる送信を「報知」という）。

車車間通信として、端末装置は、それが搭載されている車両の速度や位置などを示す車両情報を格納したパケット信号を報知する。そのパケット信号を受信した端末装置は、そのパケット信号に格納された情報をもとに車両の接近などを認識する。また、路車間通信として、基地局装置は、交差点情報および渋滞情報などが格納されたパケット信号を報知する。

交差点情報には、交差点の位置情報、基地局装置が設置された交差点の路線情報、撮影画像、交差点内の車両や歩行者の位置情報など、交差点の状況に関する情報が含まれる。端末装置は、この交差点情報をモニタに表示する。また、この交差点情報をもとに交差点の状況を認識し、出会い頭・右折・左折による、車両、自転車、歩行者との衝突防止を目的とした視覚情報あるいは音声メッセージをユーザに通知してもよい。渋滞情報には、基地局装置が設置された走路の混雑状況、道路工事、事故に関する情報が含まれる。端末装置は、この渋滞情報をもとに進行方向の渋滞をユーザに伝達する。また、その渋滞を迂回するための迂回路を提示してもよい。

図１は、本発明の実施例１に係る通信システム５００の構成を示す。これは、一つの交差点を上方から見た場合に相当する。通信システム５００は、基地局装置２０、第１車両１００ａに搭載された端末装置１０ａ、第２車両１００ｂに搭載された端末装置１０ｂを含む。エリア２０２は基地局装置２０の電波圏内を示し、エリア外２０４は基地局装置２０の電波圏外を示す。図面の上側が「北」に対応し、第１車両１００ａは「南」から「北」に進んでおり、第２車両１００ｂは「東」から「西」に進んでいる。基地局装置２０は外部ネットワーク２００を介して外部の装置と通信が可能である。

図２（ａ）−（ｄ）は、通信システム５００において規定されるスーパーフレームのフォーマットを示す。図２（ａ）は、スーパーフレームの構成を示す。スーパーフレームは、第１サブフレームから第Ｎサブフレームと示されるＮ個のサブフレームによって形成されている。たとえば、スーパーフレームの長さが１００ｍｓｅｃであり、Ｎが８である場合、１２．５ｍｓｅｃの長さのサブフレームが規定される。Ｎは、８以外であってもよい。

図２（ｂ）は、第１基地局装置２０ａによって生成されるスーパーフレームの構成を示す。第１基地局装置２０ａは、基地局装置２０のうちの任意の一つに相当する。第１基地局装置２０ａは、第１サブフレームの先頭部分に路車送信期間を設定する。また、第１基地局装置２０ａは、第１サブフレームにおいて路車送信期間に続いて車車送信期間を設定する。車車送信期間とは、端末装置１０がパケット信号を報知する期間である。つまり、第１サブフレームの先頭期間である路車送信期間において第１基地局装置２０ａは必ずこの期間にパケット信号を報知する。逆に、第１基地局装置２０ａの電波到達距離内に配置される他の基地局装置２０、および、この電波到達距離内にいる端末装置１０は、この期間にパケット信号を報知することはない。第１サブフレームの路車送信期間に後続する車車送信期間において端末装置１０がパケット信号を報知可能であるように規定される。さらに、第１基地局装置２０ａは、第２サブフレームから第Ｎサブフレームに車車送信期間のみを設定する。

図２（ｃ）は、第２基地局装置２０ｂによって生成されるスーパーフレームの構成を示す。第２基地局装置２０ｂは、第１基地局装置２０ａとは異なった基地局装置２０に相当する。第２基地局装置２０ｂは、第２サブフレームの先頭部分に路車送信期間を設定する。また、第２基地局装置２０ｂは、第２サブフレームにおける路車送信期間の後段、第１サブフレーム、第３サブフレームから第Ｎサブフレームに車車送信期間を設定する。

図２（ｄ）は、第３基地局装置２０ｃによって生成されるスーパーフレームの構成を示す。第３基地局装置２０ｃは、第１基地局装置２０ａや第２基地局装置２０ｂとは異なった基地局装置２０に相当する。第３基地局装置２０ｃは、第３サブフレームの先頭部分に路車送信期間を設定する。また、第３基地局装置２０ｃは、第３サブフレームにおける路車送信期間の後段、第１サブフレーム、第２サブフレーム、第４サブフレームから第Ｎサブフレームに車車送信期間を設定する。このように、複数の基地局装置２０は、互いに異なったサブフレームを選択し、選択したサブフレームの先頭部分に路車送信期間を設定する。このように、基地局装置２０は、自身がパケット信号（情報）を報知するために１つのサブフレームの路車送信期間を独占することで、固有の報知期間をスーパーフレーム内に設けている。スーパーフレーム内に設定可能なサブフレームは有限（本実施例では８個）ではあるが、複数の基地局装置２０の電波到達距離を考慮して、スーパーフレームを選択すれば、基地局装置２０の設置台数を制限することはない。逆に、スーパーフレーム内のすべてのサブフレームに対して基地局装置２０が設置されるものとは限らない。

図３（ａ）−（ｂ）は、サブフレームの構成を示す。図３（ａ）に示すように、サブフレームは、路車送信期間、車車送信期間の順に構成される。路車送信期間では基地局装置２０がパケット信号を報知し、車車送信期間では端末装置１０がパケット信号を報知可能である。図３（ｂ）は、路車送信期間におけるパケット信号の配置を示す。図示のごとく、路車送信期間（以下、ＲＳＵ（Ｒｏａｄ Ｓｉｄｅ Ｕｎｉｔ）期間という）において、複数の路車間通信のパケット信号（以下、ＲＳＵパケットという）が並べられている。ここで、前後のＲＳＵパケットは、ＳＩＦＳ（Ｓｈｏｒｔ Ｉｎｔｅｒｆｒａｍｅ Ｓｐａｃｅ）だけ離れている。

図４（ａ）−（ｆ）は、通信システム５００において規定される各レイヤのフレームのフォーマットを示す。図４（ａ）は、物理レイヤのフレームフォーマットを示す。図示のごとく、フレームには、ＰＬＣＰプリアンブル、ＰＬＣＰヘッダ、ＰＳＤＵ（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）、テールが順に配置される。図４（ｂ）は、ＭＡＣレイヤのフレームフォーマットを示す。このフレームは、図４（ａ）のＰＳＤＵに格納される。図示のごとく、フレームには、ＭＡＣヘッダ、ＭＳＤＵ（ＭＡＣ Ｌａｙｅｒ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）、ＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）が順に配置される。図４（ｃ）は、ＬＬＣレイヤのフレームフォーマットを示す。このフレームは、図４（ｂ）のＭＳＤＵに格納される。図示のごとく、フレームには、ＬＬＣヘッダ、ＬＳＤＵ（ＬＬＣ Ｌａｙｅｒ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）が順に配置される。

図４（ｄ）は、車車間・路車間共用通信制御情報レイヤのフレームフォーマットを示す。このフレームは、図４（ｃ）のＬＳＤＵに格納される。図示のごとく、フレームには、ＩＲヘッダ、ＡＰＤＵ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）が順に配置される。図４（ｅ）は、セキュリティレイヤのフレームフォーマットを示す。このフレームは、図４（ｄ）のＡＰＤＵに格納される。図示のごとく、フレームには、セキュリティヘッダ（Ｓｅｃｕｒｉｔｙ Ｈｅａｄｅｒ）、ペイロード（Ｐａｙｌｏａｄ）、セキュリティフッタ（Ｓｅｃｕｒｉｔｙ Ｆｏｏｔｅｒ）が順に配置される。図４（ｆ）は、アプリケーションレイヤのフレームフォーマットを示す。このフレームは、図４（ｅ）のペイロードに格納されており、アプリケーションデータによって構成される。以下では、ＭＡＣレイヤのフレームをＭＡＣフレームといい、セキュリティレイヤのフレームをセキュリティフレームという。また、フレームフォーマットをデータ構造という。

図５は、Ｎ＝４とし、１つのＲＳＵ期間を１台の基地局装置２０が占有して使用する場合のＲＳＵパケットの具体例を示す。本具体例は、相互に電波到達範囲が重なる基地局装置２０が最大４台設置可能とする場合で、スーパーフレーム期間（本具体例では１００ｍｓｅｃ）に４つのＲＳＵ期間が存在する。本具体例では、１つのＲＳＵ期間に７つのＲＳＵパケットが送信される。各ＲＳＵパケットのセキュリティフレームは、セキュリティヘッダ、アプリケーションデータを格納するペイロード、セキュリティフッダで構成される。ヘッダには公開鍵証明書が格納され、フッダには電子署名が格納される。なお、セキュリティフレームより下位レイヤのヘッダは省略して描いている。本具体例では、スーパーフレーム期間に、端末装置１０は最大４台の基地局装置２０から、すなわち４つのサブフレームに配置された４つのＲＳＵ期間に対して、ＲＳＵパケットを処理する機能が必要となる。ここで、端末装置１０は保持する各ＲＳＵ期間に対するＲＳＵパケットの処理系をＲＳＵパケット用コアと呼ぶ。よって、本具体例に対応した端末装置１０は４つのＲＳＵ用コアを備えている。なお、公開鍵暗号方式による署名検証に用いる検証処理機能はＲＳＵパケット用コア毎に配置してもよいし、複数のＲＳＵパケット用コアで共有してもよい。

図６は、端末装置１０に４つのＲＳＵ用コア（ＲＳＵ１用コア〜ＲＳＵ４用コア）が搭載される場合において、各ＲＳＵ用コアの処理例を示す。図６では車両１００が「西」から「東」に進行する。車両１００が通過するエリアの近傍には、５つの基地局装置（以下、路側機ともいう）（図６では第１基地局装置２０ａ、第２基地局装置２０ｂ、第３基地局装置２０ｃ、第４基地局装置２０ｄ、第５基地局装置２０ｅ）が設置されている。

図６において、期間ＴｖはＲＳＵ用コアが処理を停止している期間を示し、期間Ｔｃは公開鍵証明書の検証を実行している期間を示し、期間Ｔｍは電子署名付きメッセージの検証を実行している期間を示す。また、円は、各基地局装置２０の電波圏内を示し、各円内のＲＳＵ１〜ＲＳＵ４は、それぞれが図５のＲＳＵ期間１〜ＲＳＵ期間４を利用していることを示している。車両１００が第１基地局装置２０ａの電波圏内に入ると、ＲＳＵ１用コアは、第１基地局装置２０ａから報知されるＲＳＵパケットの公開鍵証明書の検証を実行する。その公開鍵証明書の検証が成功すると、ＲＳＵパケットの電子署名付きメッセージの検証を実行する。車両１００が第１基地局装置２０ａの電波圏外に出ると、第１基地局装置２０ａから報知されるＲＳＵパケットの検証処理を終了する。その後、車両１００が第５基地局装置２０ｅの電波圏内に入ると、ＲＳＵ１用コアは、第５基地局装置２０ｅから報知されるＲＳＵパケットの公開鍵証明書の検証を実行する。その公開鍵証明書の検証が成功すると、ＲＳＵパケットの電子署名付きメッセージの検証を実行する。車両１００が第５基地局装置２０ｅの電波圏外に出ると、第５基地局装置２０ｅから報知されるＲＳＵパケットの検証処理を終了する。ＲＳＵ２用コア〜ＲＳＵ４用コアも、ＲＳＵ１用コアと同様の処理を実行する。

図７は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の一例を示す。このデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ＩＤ」、「ｎｏｎｃｅ」、「データ長」および「公開鍵証明書」が配置され、その後に「ペイロード」が配置され、最後にセキュリティフッダとして「電子署名」が配置される。この例では、暗号対象は「公開鍵証明書」、「ペイロード」および「電子署名」であり、署名対象は「ペイロード」である。

「バージョン」はフレームフォーマットのバージョンを示す。「メッセージ形式」はメッセージ形式を指定する。メッセージ形式には、平文データ形式、認証付きデータ形式および認証付き暗号化データ形式がある。

「鍵ＩＤ」は基地局装置２０と端末装置１０間で共有されている通信鍵を識別するための情報である。データ形式が認証付き暗号化データ形式である場合、当該通信鍵で「公開鍵証明書」、「ペイロード」および「電子署名」が暗号化される。当該通信鍵には、事前に共有された共通鍵暗号方式の共通鍵で、たとえば、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）鍵を用いることができる。図７の例では、ＣＴＲ（ＣｏｕｎＴｅＲ）モードにより暗号化される。

「ｎｏｎｃｅ」は、通信鍵を用いた暗号化において暗号結果を攪乱するために用いる通信毎にユニークな値または、その一部がセットされる。この値は乱数であってもよいし、送信時刻であってもよい。さらに、乱数または送信時刻に発信元の機器ＩＤが追加されてもよい。「ｎｏｎｃｅ」に、送信時刻のみをセットした場合には、通信毎に使用するユニークな値として、「ｎｏｎｃｅ」にセットした送信時刻と基地局装置２０の固有値、たとえば、公開鍵証明書に含まれるシリアル番号、あるいは機器ＩＤを用いて通信毎にユニークな値として利用する。なお、「ｎｏｎｃｅ」に乱数をセットした場合であっても、「ｎｏｎｃｅ」にセットした乱数と、基地局装置２０の固有値を通信毎にユニークな値として利用してもよい。「データ長」は暗号対象のデータのデータ長（より具体的にはバイト数）を設置する。なお、「公開鍵証明書」のデータ長が固定長であるならば、「ペイロード」のデータ長をセットしてもよい。

「公開鍵証明書」は基地局装置２０に固有の公開鍵に対する公開鍵証明書をセットする。公開鍵証明書は公開鍵とその公開鍵の所有主体を結びつける証明書である。公開鍵証明書には、署名者の識別情報、機器ＩＤ（公開鍵証明書の識別情報）、有効期限、公開鍵（鍵生成アルゴリズム、サイズなどを含む）、署名者の署名などが含まれる。本実施例では、署名者は認証局（ＣＡ：Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）とする。当該署名は、たとえば、ＲＳＡ、ＤＳＡ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）、ＥＣＤＳＡ（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ−ＤＳＡ）などの公開鍵暗号方式により生成される。本実施例ではＥＣＤＳＡを採用する。

「電子署名」には、「ペイロード」に対する署名がセットされる。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。なお、「電子署名」に署名がセットされるのは、データ形式が、認証付きデータ形式、または、認証付き暗号化データ形式の時である。認証付き暗号化データ形式の時は、「電子署名」に署名をセットした後、「公開鍵証明書」、「ペイロード」、「電子署名」は暗号化される。

図８は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の別の例を示す。図８に示すデータ構造は、図７に示すデータ構造と比較し、「公開鍵証明書」を暗号対象としない。これに伴い、「公開鍵証明書」が「データ長」より前に配置される。図８に示すデータ構造では、「公開鍵証明書」が「ｎｏｎｃｅ」の直前に配置される。以下では、図７のセキュリティフレームのメッセージ形式を認証付き暗号化データ形式とした場合の処理について記載する。また、メッセージ形式を認証付きデータ形式とした場合、暗号化および復号に関する処理を省くだけである。メッセージ形式を平文データ形式とした場合には、さらに署名の生成および検証を省くのみである。この時、セキュリティフッダの「電子署名」にどんな値をセットしてもよい。さらには、セキュリティフッダを省略するようにしてもよい。また、図８のセキュリティフレームでは、メッセージ形式を認証付きデータ形式とした場合に、「公開鍵証明書」を暗号対象から外すだけである。図７では、「公開鍵証明書」、「ペイロード」および「電子署名」が暗号化される。図８では「ペイロード」および「電子署名」が暗号化されるとしたが、情報を秘匿し、情報の流失を防ぐには、少なくとも「ペイロード」が暗号化されていればよい。

図９は、実施例１に係る基地局装置２０の構成を示す。基地局装置２０は、アンテナ２１、ＲＦ部２２、変復調部２３、ＭＡＣフレーム処理部２４、セキュリティ処理部２５、データ生成部２６、ネットワーク通信部２７、記憶部２８および制御部２９を備える。セキュリティ処理部２５は署名部２５１と、暗号部２５２を含む。

ＭＡＣフレーム処理部２４、セキュリティ処理部２５、データ生成部２６、ネットワーク通信部２７、記憶部２８および制御部２９の構成は、ハードウエア的には、任意のプロセッサ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

ＲＦ部２２は、受信処理として、端末装置１０および他の基地局装置２０からのパケット信号をアンテナ２１にて受信する。ＲＦ部２２は、受信した無線周波数のパケット信号に対して周波数変換を実行し、ベースバンドのパケット信号を生成する。ＲＦ部２２は、ベースバンドのパケット信号を変復調部２３に出力する。一般的に、ベースバンドのパケット信号は、同相成分と直交成分によって形成されるため、二つの信号線が示されるべきであるが、図を簡略化するため、図９では一つの信号線だけを示している。ＲＦ部２２は、受信系の構成要素として、図示しないＬＮＡ（Ｌｏｗ Ｎｏｉｓｅ Ａｍｐｌｉｆｉｅｒ）、ミキサ、ＡＧＣ、Ａ／Ｄ変換部などを含む。

ＲＦ部２２は、送信処理として、生成したパケット信号を基地局装置２０から送信する。ＲＦ部２２は、変復調部２３から入力されるベースバンドのパケット信号に対して周波数変換を実行し、無線周波数のパケット信号を生成する。ＲＦ部２２は、自身に割り当てられたＲＳＵ期間において、無線周波数のパケット信号をアンテナ２１から送信する。ＲＦ部２２は、送信系の構成要素として、図示しないＰＡ（Ｐｏｗｅｒ Ａｍｐｌｉｆｉｅｒ）、ミキサ、Ｄ／Ａ変換部などを含む。

変復調部２３は、受信処理として、ＲＦ部２２からのベースバンドのパケット信号に対して、復調を実行する。変復調部２３は、復調して得たデジタルデータを、ＭＡＣフレーム処理部２４に出力する。また、変復調部２３は、送信処理として、ＭＡＣフレーム処理部２４からのＭＡＣフレームに対して、変調を実行する。変復調部２３は、変調した結果をベースバンドのパケット信号としてＲＦ部２２に出力する。

本実施例に係る通信システム５００では、ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）変調方式を採用する。この場合、変復調部２３は受信処理としてＦＦＴ（Ｆａｓｔ Ｆｏｕｒｉｅｒ Ｔｒａｎｓｆｏｒｍ）を実行し、送信処理としてＩＦＦＴ（Ｉｎｖｅｒｓｅ Ｆａｓｔ Ｆｏｕｒｉｅｒ Ｔｒａｎｓｆｏｒｍ）を実行する。

ＭＡＣフレーム処理部２４は、受信処理として、変復調部２３からのデジタルデータから、ＭＡＣフレームを取り出し、取り出したＭＡＣフレームから、セキュリティフレームを取り出し、セキュリティ処理部２５に出力する。また、ＭＡＣフレーム処理部２４は、送信処理として、セキュリティ処理部２５からのセキュリティフレームに対して、ＭＡＣヘッダ、ＬＬＣヘッダおよびＩＲ情報ヘッダを付加し、ＭＡＣフレームを生成し、変復調部２３に出力する。また、他の基地局装置２０または端末装置１０からのパケット信号が衝突しないようパケット信号の送受信タイミングを制御する。

ネットワーク通信部２７は、外部ネットワーク２００に接続される。ネットワーク通信部２７は、外部ネットワーク２００から工事や渋滞などに関する道路情報を受けつける。

また、ネットワーク通信部２７は、セキュリティ処理部２５による処理結果を外部ネットワーク２００へ出力したり、記憶部２８に蓄積して、定期的に外部ネットワーク２００へ出力したりする。データ生成部２６は、アプリケーションデータを生成する。たとえば、アプリケーションデータに道路情報をセットする。そして、アプリケーションデータの内容によって、データ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部２５に出力する。記憶部２８は、種々の情報を記憶する。制御部２９は、基地局装置２０全体の処理を制御する。

セキュリティ処理部２５は、セキュリティフレームを生成または解釈する。本実施例では、基地局装置２０からのパケット送信に注目するため、セキュリティフレームを生成する処理に注目する。セキュリティ処理部２５は、ＭＡＣフレーム処理部２４に出力すべきセキュリティフレームを、データ生成部２６から受け取ったアプリケーションデータ、認証局から受け取った秘密鍵、公開鍵証明書などを利用して生成する。

セキュリティ処理部２５は、署名部２５１および暗号部２５２を含む。署名部２５１は、本実施例では図示しない認証局が発行する秘密鍵と、この秘密鍵と対をなす公開鍵を含む公開鍵証明書を内部に記憶している。この秘密鍵と公開鍵証明書は、基地局装置２０に固有とすることで、共通鍵暗号方式に比べてセキュリティを高くすることができる。署名部２５１は、自身が保持する秘密鍵を用いて、署名対象に対する署名を生成する。暗号部２５２は、暗号対象を端末装置１０と共有している通信鍵を用いて暗号化する。図７に示すデータ構造では、「公開鍵証明書」、「ペイロード」および「電子署名」を暗号化する。

図１０は、実施例１に係る、車両１００に搭載された端末装置１０の構成を示す。端末装置１０は、アンテナ１１、ＲＦ部１２、変復調部１３、ＭＡＣフレーム処理部１４、セキュリティ処理部１５、受信処理部１６１、通知部１６２、データ生成部１７、記憶部１８および制御部１９を備える。セキュリティ処理部１５は、検証部１５１および復号部１５２を含む。

ＭＡＣフレーム処理部１４、セキュリティ処理部１５、受信処理部１６１、通知部１６２、データ生成部１７、記憶部１８および制御部１９の構成は、ハードウエア的には、任意のプロセッサ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

アンテナ１１、ＲＦ部１２、変復調部１３およびＭＡＣフレーム処理部１４は、図９のアンテナ２１、ＲＦ部２２、変復調部２３およびＭＡＣフレーム処理部２４の構成および動作は基本的に共通する。以下、これらの構成要素については、相違点を中心に説明する。

受信処理部１６１は、セキュリティ処理部１５から受け取ったデータと、データ生成部１７から受け取った自車の車両情報にもとづき、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また、データが画像情報であれば通知部１６２に表示するよう処理する。

通知部１６２は、図示しないモニタ、ランプ、スピーカなどのユーザへの通知手段を含む。受信処理部１６１からの指示にしたがって、図示しない他の車両の接近などを当該通知手段を介して運転者に通知する。また、渋滞情報、交差点などの画像情報などをモニタに表示する。

データ生成部１７は、図示しないＧＰＳ受信機、ジャイロスコープ、車速センサなどから供給される情報にもとづき、端末装置１０が搭載された車両１００の現在位置、進行方向、移動速度などを特定する。なお、現在位置は、緯度・経度によって示される。これらの情報の特定方法は一般的な公知の技術により実現可能であるため、ここでは説明を省略する。データ生成部１７は、特定した情報をもとに他の端末装置１０や基地局装置２０に報知すべきデータを生成し、セキュリティ処理部１５に出力する。また、特定した情報を受信処理部１６１に自車の車両情報として出力する。記憶部１８は、種々の情報を記憶する。制御部１９は、端末装置１０全体の処理を制御する。

セキュリティ処理部１５は、セキュリティフレームを生成または解釈する。本実施例では、基地局装置２０からのパケット受信に注目するため、そのパケット信号に格納されたセキュリティフレームを解釈する処理に注目する。セキュリティ処理部１５は、検証部１５１および復号部１５２を含む。復号部１５２は、セキュリティフレームの「鍵ＩＤ」により特定される通信鍵を用いて、暗号対象を復号する。図７に示すデータ構造では、「公開鍵証明書」、「ペイロード」および「電子署名」を復号する。検証部１５１は「公開鍵証明書」および「電子署名」を検証する。なお、検証部１５１は公開鍵証明書を検証するために、本実施例では図示しない認証局が発行する公開鍵証明書を検証する認証鍵を内部に記憶している。この認証鍵は、認証局において公開鍵証明書の署名を生成するのに用いた秘密鍵と対をなす公開鍵である。

図１１は、検証部１５１の構成例１を示す。構成例１に係る検証部１５１は、証明書検証部１５１ａ、メッセージ検証部１５１ｂ、ダイジェスト保持部１５１ｃ、認証鍵保持部１５１ｄを含む。構成例１では、各ＲＳＵ用コアにおける単位ＲＳＵ期間に受信されたＲＳＵパケットの公開鍵証明書または電子署名付きメッセージの検証を、スーパーフレーム期間内に終了させる公開鍵の署名検証処理能力を検証部１５１が持っていることを前提とする。

ダイジェスト保持部１５１ｃは、証明書検証部１５１ａによる検証が成功した公開鍵証明書のダイジェスト、公開鍵、機器ＩＤを保持する。説明の便宜上、これらの情報をまとめてＲＳＵ検証情報と呼ぶ。ダイジェスト保持部１５１ｃは、各ＲＳＵ期間（サブスロット）毎にＲＳＵ検証情報を保持する。すなわち、ＲＳＵ用コアの数だけＲＳＵ検証情報を保持する。公開鍵証明書のダイジェストとして、ここでは公開鍵証明書に含まれる署名を当てるとするが、以下の処理では、証明書の全体あるいは一部のハッシュ値、公開鍵または／かつ公開鍵証明書に含まれる署名、機器ＩＤ（公開鍵証明書の識別番号）をダイジェストの代用としてもよい。すなわち証明書を特定できる情報であれば、いずれであってもよい。このようにするとダイジェスト保持部１５１ｃに保持するデータ量が削減される。なお、ＲＳＵ検証情報は、少なくとも検証に成功した公開鍵証明書を特定できればよいので、公開鍵証明書のダイジェスト、公開鍵、機器ＩＤ、公開鍵証明書の識別番号の全てを必ずしも必要とはしないし、これらに限定する必要はない。公開鍵証明書から取得できる情報であればいずれであっても構わない。ステータスは、当該ＲＳＵ期間における検証の状態を表す状態情報である。認証鍵保持部１５１ｄは、証明書検証部１５１ａによって公開鍵証明書を検証するための認証鍵を保持する。

証明書検証部１５１ａは、基地局装置２０から報知されるパケット信号に含まれる公開鍵証明書に含まれる署名を、認証鍵保持部１５１ｄに保持される認証鍵を用いて検証する。この認証鍵は予め組み込まれていてもよいし、安全な手段で事後的に取得し、認証鍵保持部１５１ｄに保持したものであってもよい。

公開鍵証明書に含まれる署名に対する検証が成功すれば、当該公開鍵証明書に含まれる基地局装置２０が生成した公開鍵は、当該認証局により証明された真性なものであると推定できる。しかしながら、この署名には公開鍵暗号方式（本実施例ではＥＣＤＳＡ）が用いられるため、すべてのＲＳＵパケットにおいて公開鍵証明書の検証を実行すると処理負荷が増大する。そこで、公開鍵証明書の検証を適宜、スキップする。

以下では特に断りがない限り、ダイジェスト保持部１５１ｃにＲＳＵ検証情報に関する処理はパケット信号を受信したＲＳＵ期間に対応するＲＳＵ検証情報に対する処理である。証明書検証部１５１ａは、基地局装置２０から報知されるパケット信号を受信すると、そのＲＳＵパケットに含まれる公開鍵証明書から取り出したダイジェストと、ダイジェスト保持部１５１ｃに保持されるダイジェストとの比較をする。両者が異なる場合、証明書検証部１５１ａは当該パケット信号に含まれる公開鍵証明書の検証を実行する。公開鍵証明書の検証が成功した場合、ダイジェスト保持部１５１ｃに保持されるＲＳＵ検証情報を検証した公開鍵証明書のものに更新する。公開鍵証明書の検証が失敗した場合、処理を終了する。両者が対応（より厳密には、一致）する場合、当該パケット信号に含まれる公開鍵証明書の検証をスキップする。すなわち、正式な検証を実行せずに公開鍵証明書のダイジェストの一致をもって検証成功とみなす。これは、公開鍵証明書のダイジェストあるいは、公開鍵や機器ＩＤが一致している間は、同一の基地局装置２０から報知されたパケット信号と推定できるためである。すなわち、ある基地局装置２０から報知されたパケット信号に含まれる公開鍵証明書の検証が一度成功すれば、その基地局装置２０から報知される後続のパケット信号の信頼性は高いと判断できる。なお、メッセージ検証では、ダイジェスト保持部１５１ｃに保持されている公開鍵と機器ＩＤを利用して、メッセージの検証処理を実行する。受け取ったＲＳＵパケットに含まれる公開鍵証明書から、公開鍵や機器ＩＤを取得しないのは、公開鍵証明書の改ざん攻撃に対抗するためである。

メッセージ検証部１５１ｂは、証明書検証部１５１ａにおいて公開鍵証明書の検証が成功した場合、または、認証をスキップした場合、基地局装置２０から報知されるパケット信号に含まれる認証付きメッセージを検証する。検証には、ダイジェスト保持部１５１ｃに保持されている公開鍵と機器ＩＤを用いる。本実施例では電子署名付きメッセージ形式における「ペイロード」の完全性と真正性の検証をする。電子署名付き暗号化メッセージ形式では、暗号を解いた（復号した）後、同様な処理を行う。この電子署名は、当該パケット信号に含まれる公開鍵証明書に格納される公開鍵と対をなす秘密鍵により生成されているため、当該公開鍵を用いた当該電子署名付きメッセージに対する検証が成功すれば、当該メッセージは基地局装置２０により生成された完全かつ真正なものであるとすることができる。

しかしながら、この電子署名にも公開鍵暗号方式（本実施例ではＥＣＤＳＡ）が用いられるため、すべてのＲＳＵパケットにおいて電子署名付きメッセージの検証を実行すると処理負荷が増大する。そこで、検証部１５１の処理能力に応じて、電子署名付きメッセージの検証を適宜、スキップする。なお、ＲＳＵパケットの数が少ない場合や、処理能力に余裕がある場合、すべての電子署名付きメッセージの検証を実行してもよい。検証部１５１の処理能力はハードウエアの規模やスペックを増大させるほど向上するため、データの信頼性と回路規模はトレードオフの関係となる。

メッセージ検証部１５１ｂは、ダイジェスト保持に１５１ｃに保持されるステータスが「メッセージ検証済」であり、公開鍵証明書のダイジェストが対応（より厳密には、一致）しているパケット信号が受信されている間、当該パケット信号のうちの少なくともひとつのパケット信号の電子署名付きメッセージの検証をスキップする。たとえば、公開鍵証明書のダイジェストが一致している複数のパケット信号について、当該複数のパケット信号に含まれる少なくともひとつ（たとえば、先頭のパケット信号）の電子署名付きメッセージの検証が成功すると、その他のパケット信号に含まれる電子署名付きメッセージを検証することなく、当該電子署名付きメッセージを承認と判定してもよい。

より具体的には、メッセージ検証部１５１ｂは、同じサブフレームのＲＳＵ期間に受信される複数のパケット信号のうち、先頭のパケット信号に含まれる電子署名付きメッセージの検証が成功し、かつパケット信号以外の任意のひとつのパケット信号に含まれる電子署名付きメッセージの検証が成功した場合、当該ＲＳＵ期間に受信されるすべてのパケット信号に含まれる電子署名付きメッセージを承認と判定してもよい。

図１２は、構成例１に係る検証部１５１が用いられる端末装置１０のＲＳＵパケットの受信処理を示すフローチャートである。ＲＦ部１２はＲＳＵパケットを受信する（Ｓ１０）。このＲＳＵパケットは変復調部１３、ＭＡＣフレーム処理部１４を経て、セキュリティ処理部１５に出力される。証明書検証部１５１ａは、ダイジェスト保持部１５１ｃに保持される公開鍵証明書のダイジェストと、受信されたＲＳＵパケットに含まれる公開鍵証明書のダイジェストを比較し、一致するか否か判定する（Ｓ１１）。

ダイジェストが一致しない場合（Ｓ１１のＮ）、証明書検証部１５１ａは受信されたＲＳＵパケットに含まれる公開鍵証明書に格納される署名を検証する（Ｓ１２）。なお、ダイジェストが一致しない場合は初期状態や基地局装置２０が切り替わったときに発生する。

当該検証が成功した場合（Ｓ１２のＹ）、当該公開鍵証明書のダイジェスト、および公開鍵をダイジェスト保持部１５１ｃに上書きする（Ｓ１３）。証明書検証部１５１ａは、該当ＲＳＵ期間内のパケット認証を不定と判定し、受信処理部１６１に報告する（Ｓ１４）。なお、不定とは認証処理の結果が確定していない状態を指す。受信処理部１６１は、認証が不定のパケットに含まれるデータを、予め設定された規則にしたがい処理する。たとえば、認証されるまでそのデータに対する処理を停止していてもよいし、未認証である旨のフラグを立てて通知部１６２に渡してもよいし、メッセージに含まれる情報の重要度に応じて両者を使い分けしてもよい。通知部１６２は未認証である旨のフラグが立っている情報を受領した場合、未認証の情報であることをユーザに認識させる態様で、その情報をユーザに通知することができる。

ステップＳ１２にて上記検証が失敗した場合（Ｓ１２のＮ）、該当ＲＳＵ期間内のパケット認証を否認と判定し、受信処理部１６１に報告する（Ｓ１５）。ステップＳ１２〜ステップＳ１５の処理が、図６における期間Ｔｃの処理である。ステップＳ１１にてダイジェストが一致する場合（Ｓ１１のＹ）、電子署名付きメッセージの検証をすべきパケット信号を選択する（Ｓ１６）。上述したように、この検証対象は該当ＲＳＵ期間内の先頭パケットであってもよいし、先頭以外のパケットであってもよい。また、検証対象とすべきパケットの数は一つであってもよいし、複数であってもよい。

メッセージ検証部１５１ｂは選択されたパケットに含まれる電子署名付きメッセージを検証する（Ｓ１７）。当該検証が成功した場合（Ｓ１７のＹ）、メッセージ検証部１５１ｂは、該当ＲＳＵ期間内のパケット認証を承認と判定し、受信処理部１６１に報告する（Ｓ１８）。当該検証が失敗した場合（Ｓ１７のＮ）、メッセージ検証部１５１ｂは、該当ＲＳＵ期間内のパケット認証を否認と判定し、受信処理部１６１に報告する（Ｓ１９）。ステップＳ１６〜ステップＳ１９の処理が、図６における期間Ｔｍの処理である。

端末装置１０の受信処理の継続中（Ｓ２０のＮ）、ステップＳ１０〜ステップＳ１９までの処理が繰り返し実行される。当該受信処理が終了すると（Ｓ２０のＹ）、ステップＳ１０〜ステップＳ１９までの処理も終了する。

図１３は、検証部１５１の構成例２を示す。構成例２に係る検証部１５１は、構成例１に係る検証部１５１にステータス管理部１５１ｅが追加された構成である。ステータス管理部１５１ｅは、ダイジェスト保持部１５１ｃに保持されるＲＳＵ検証情報のそれぞれに対応した処理の進行状態を示すステータスの管理を行う。構成例２では、単位ＲＳＵ期間に受信されるＲＳＵパケットの公開鍵証明書および電子署名付きメッセージの検証を、その単位ＲＳＵ期間に終了させることが保証されないことを前提とする。すなわち、構成例２に係る検証部１５１の処理能力が構成例１に係る検証部１５１の処理能力より低く、換言すれば、回路規模が小さく設計される。

図１４は、構成例２に係る検証部１５１が用いられる端末装置１０のＲＳＵパケットの受信処理を示すフローチャートである。ＲＦ部１２はＲＳＵパケットを受信する（Ｓ３０）。このＲＳＵパケットは変復調部１３、ＭＡＣフレーム処理部１４を経て、セキュリティ処理部１５に出力される。証明書検証部１５１ａは、ダイジェスト保持部１５１ｃに保持される公開鍵証明書のダイジェストと、受信されたＲＳＵパケットに含まれる公開鍵証明書のダイジェストを比較し、一致するか否か判定する（Ｓ３１）。

ダイジェストが一致しない場合（Ｓ３１のＮ）、証明書検証部１５１ａは、該当ＲＳＵ期間内のパケットの公開鍵証明書の検証が必要であると判断し、パケット認証は不定として、受信処理部１６１に報告する（Ｓ３２）。その後、証明書検証部１５１ａに公開鍵証明書の検証開始をステータス管理部１５１ｅに指示する（Ｓ３３）。ダイジェストが一致する場合（Ｓ３１のＹ）、メッセージの検証開始をステータス管理部１５１ｅに指示し、ステータス管理部１５１ｅはステータスを判定する（Ｓ３４、Ｓ３８）。当該ステータスは後述する図１５、図１６に示すフローチャートにより管理される。

ステータスが「証明書検証失敗」または「メッセージ検証失敗」の場合、ステータス管理部１５１ｅは該当ＲＳＵ期間内のパケット認証を否認と判定し、受信処理部１６１に報告する（Ｓ３５）。ステータスが「証明書検証中」、「証明書検証成功」または「メッセージ検証中」の場合、ステータス管理部１５１ｅは該当ＲＳＵ期間内のパケット認証を不定と判定し、受信処理部１６１に報告する（Ｓ３６）。ステータスが「メッセージ検証成功」の場合、ステータス管理部１５１ｅは該当ＲＳＵ期間内のパケット認証を承認と判定し、受信処理部１６１に報告する（Ｓ３７）。当該報告の後、「証明書検証成功」の場合（Ｓ３８の証明書検証成功）、ステータス管理部１５１ｅは、メッセージ検証部１５１ｂに電子署名付きメッセージの検証開始を指示する（Ｓ３９）。

端末装置１０の受信処理の継続中（Ｓ４０のＮ）、ステップＳ３０〜ステップＳ３９までの処理が繰り返し実行される。当該受信処理が終了すると（Ｓ４０のＹ）、ステップＳ３０〜ステップＳ３９までの処理も終了する。

図１５は、構成例２に係る検証部１５１が用いられる端末装置１０の公開鍵証明書の検証処理を示すフローチャートである。当該検証処理は、ステータス管理部１５１ｅによる公開鍵証明書の検証開始指示を受けて開始する（図１４のＳ３３）。まず、ステータス管理部１５１ｅはステータスを「証明書検証中」に設定する（Ｓ３３１）。ステータス管理部１５１ｅは公開鍵証明書の検証が終了したか否か判定する（Ｓ３３２）。終了しない間（Ｓ３３２のＮ）、ステータスを「証明書検証中」に維持する。当該検証が終了すると（Ｓ３３２のＹ）、ステータス管理部１５１ｅは当該検証が成功したか否か判定する（Ｓ３３３）。当該検証が成功した場合（Ｓ３３３のＹ）、証明書検証部１５１ａは、当該公開鍵証明書のダイジェスト、および公開鍵をダイジェスト保持部１５１ｃに上書きする（Ｓ３３４）。ステータス管理部１５１ｅはステータスを「証明書検証成功」に変更する（Ｓ３３５）。上記検証が失敗した場合（Ｓ３３３のＮ）、ステータス管理部１５１ｅはステータスを「証明書検証失敗」に変更する（Ｓ３３６）。

図１６は、構成例２に係る検証部１５１が用いられる端末装置１０の電子署名付きメッセージの検証処理を示すフローチャートである。当該検証処理は、ステータス管理部１５１ｅによる電子署名付きメッセージの検証開始指示を受けて開始する（図１４のＳ３９）。まず、ステータス管理部１５１ｅはステータスを「メッセージ検証中」に変更する（Ｓ３９１）。ステータス管理部１５１ｅは電子署名付きメッセージの検証が終了したか否か判定する（Ｓ３９２）。終了しない間（Ｓ３９２のＮ）、ステータスを「メッセージ検証中」に維持する。当該検証が終了すると（Ｓ３９２のＹ）、ステータス管理部１５１ｅは当該検証が成功したか否か判定する（Ｓ３９３）。当該検証が成功した場合（Ｓ３９３のＹ）、ステータス管理部１５１ｅはステータスを「メッセージ検証成功」に変更する（Ｓ３９４）。上記検証が失敗した場合（Ｓ３９３のＮ）、ステータス管理部１５１ｅはステータスを「メッセージ検証失敗」に変更する（Ｓ３９５）。

なお、図１４のステップＳ３２およびステップＳ３３と図１５の処理が、図６における期間Ｔｃの処理にあたり、図１４のステップＳ３４〜ステップＳ３９および図１６の処理が、図６における期間Ｔｍの処理にあたる。図１４〜図１６のフローチャートに示す検証処理によれば、単位ＲＳＵ期間内に、その期間に含まれる公開鍵証明書および電子署名付きメッセージの検証が終了しない場合でも、矛盾なく検証処理を実行できる。

以上説明したように実施例１によれば、セキュリティを向上させつつ、パケット信号を受信する際の処理負荷を軽減できる。すなわち、公開鍵暗号方式を用いた、公開鍵証明書および電子署名をパケット信号に含めることにより、セキュリティを向上させることができる。また、公開鍵証明書の検証処理を適宜スキップすることにより処理負荷を軽減できる。電子署名付きメッセージの検証処理も適宜スキップすることにより処理負荷をさらに軽減できる。この処理負荷を軽減するほど、回路規模を小さくでき、コストも削減できる。したがって、路車間通信の高信頼性が要求されるＩＴＳにおいて、本実施例に係る端末装置１０を採用すれば、高信頼性と低コストを両立でき、ＩＴＳの普及にもつながる。

以上、実施例１を説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

図１７は、ＲＳＵパケットに含まれる図７のセキュリティフレームのフォーマットの変形例１を示す。変形例１に係るデータ構造は、図７に示すデータ構造に「ＭＡＣ」を追加した構成である。図１７に示すデータ構造では「電子署名」の後に「ＭＡＣ」が追加され、セキュリティフッダは、「電子署名」と「ＭＡＣ」によって構成される。「ＭＡＣ」は、共通鍵とＭＡＣ対象に所定のＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ：メッセージ認証コード）アルゴリズムを適用して生成される。図１７に示すデータ構造では、ＭＡＣ対象は「ｎｏｎｃｅ」、「データ長」、「公開鍵証明書」、「ペイロード」および「電子署名」であり、共通鍵は基地局装置２０と端末装置１０間で共有されている通信鍵である。図１７の例では、「ＭＡＣ」は、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）アルゴリズムと「鍵ＩＤ」により特定される通信鍵を用いたＣＢＣ（Ｃｉｐｈｅｒ Ｂｌｏｃｋ Ｃｈａｉｎｉｎｇ）−ＭＡＣの値を代入する。認証付き暗号化データの場合は、ＣＣＭ（Ｃｏｕｎｔｅｒ ｗｉｔｈ ＣＢＣ−ＭＡＣ）モードにより生成されることとなる。

「ＭＡＣ」は「電子署名」より簡易な認証方法であり、データ量も少なく、かつ、高速処理が可能である。基地局装置２０のセキュリティ処理部１５は、「電子署名」と「ＭＡＣ」の両方を生成する。端末装置１０の検証部１５１は、ＲＳＵ期間の先頭パケットに含まれる公開鍵証明書および電子署付きメッセージの検証を実行し、それらの検証が成功した場合、当該ＲＳＵ期間の先頭パケットに後続するパケットについては公開鍵証明書のダイジェストの比較と、ＭＡＣ付きメッセージの検証を実行する。ＭＡＣ付きメッセージの検証は、電子署名付きメッセージの検証より負荷が軽くハードウエア化に適した処理であること、認証付き暗号化データの場合に使用する暗号化と同一の暗号アルゴリズムを最小とするため暗号処理の追加がないことにより、セキュリティ低下を抑制しつつ、回路規模を小さくできる。図１１および図１３のメッセージ検証部１５１ｂは、メッセージ検証のスキップに代えてＭＡＣの検証を行う。ＭＡＣ検証に成功した場合、パケット認証を承認とする。ＭＡＣ検証に失敗した場合、パケット認証を否認と報告する。このように、全ての検証をスキップに代えてＭＡＣ検証を行うことで、各メッセージの完全性と真正性の確認ができるようになるので、セキュリティ低下を招くことなく、署名検証の負荷を軽減することができる。

変形例１に係るデータ構造では、「公開鍵証明書」を暗号化の対象外としている。この場合、図８のデータ構造のように「データ長」と「公開証明書」を転置して、「データ長」に対して「ペイロード」あるいは、暗号対象データのバイト数を代入するようにしてもよい。また、図７同様に「公開鍵証明書」も暗号化の対象に含めるようにしてもよい。

図１８は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の変形例２を示す。変形例１に係るデータ構造は、認証用のデータとして、「電子署名」と「ＭＡＣ」の両方が格納されるため、セキュリティフレームのデータ量が増大する。そこで、ＲＳＵ期間の先頭パケット以外のパケットのセキュリティフレームのデータ量を低減する手法を考える。

変形例２に係るデータ構造は、１つのＲＳＵ期間の先頭のＲＳＵパケットのみ「電子署名」と「ＭＡＣ」の両方をセキュリティフッダに格納し、後続のＲＳＵパケットは「ＭＡＣ」のみとする。変形例１に係るデータ構造と比較すると、先頭のパケットは同じ構造である。後続のパケットは、「電子署名」が削除され、「公開鍵証明書」の代わりに「公開鍵証明書のダイジェスト」が用いられる構成である。なお、通信路におけるパケット位置が通信システム５００内で管理されている場合、「公開鍵証明書のダイジェスト」も省略可能である。また、前述のごとく、「公開鍵証明書のダイジェスト」は、公開鍵証明書を特定可能な情報であれば代用が可能である。例えば、公開鍵証明書に含まれる機器ＩＤや、公開鍵証明書の識別情報、公開鍵証明書の署名およびその一部などがそれに当たる。変形例２に係るデータ構造のセキュリティフレームは、ＲＳＵ期間の先頭パケット以外のパケットに用いられる。

変形例２に係る先頭のＲＳＵパケットのデータ構造も、変形例１に係るデータ構造と同様に、「公開鍵証明書」を暗号化の対象外としている。この場合、図８のデータ構造のように「データ長」と「公開証明書」を転置して、「データ長」に対して「ペイロード」あるいは、暗号対象データのバイト数を代入するようにしてもよい。また、図７同様に「公開鍵証明書」あるいは「公開鍵証明書のダイジェスト」も暗号化の対象に含めるようにしてもよい。

また、変形例２に係るデータ構造における後続のＲＳＵパケットについては、「公開鍵証明書のダイジェスト」を暗号化の対象外としているが、「公開鍵証明書のダイジェスト」も暗号化の対象に含めるようにしてもよいし、「データ長」と「公開鍵証明書のダイジェスト」を転置して、「データ長」に対して「ペイロード」あるいは、暗号対象データのバイト数を代入するようにしてもよい。また、１つのＲＳＵ期間の先頭のＲＳＵパケットか、後続のＲＳＵパケットかによってセキュリティフレームのデータ構造を分けるように説明したが、１つの基地局装置２０が複数のＲＳＵ期間を使用する場合、１つの基地局装置２０が、スーパーフレームに送信する全てのＲＳＵパケットの１つに「公開鍵証明書」と「電子署名」が含まれているようにしてもよい。この場合、スーパーフレームに送信する先頭のＲＳＵパケットと、それ以外の後続のＲＳＵパケットでセキュリティフレームのデータ構造が分けられる。

図１９は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の変形例３を示す。変形例３に係るデータ構造は、１つのＲＳＵ期間の先頭のＲＳＵパケットは、図７のセキュリティフレームと同じ構造とし、後続のＲＳＵパケットは変形例２の後続のＲＳＵパケットと同じ構造とする。スーパーフレーム期間内に各ＲＳＵ用コアに対する公開鍵の署名検証（ＥＣＤＡＳ検証）処理能力を持つ場合に最も有効である。セキュリティフレームのデータ構造の変形例２および変形例３においても、変形例１と同様で、図１１および図１３のメッセージ検証部１５１ｂは、メッセージ検証のスキップに代えてＭＡＣの検証を行う。ＭＡＣ検証に成功した場合、パケット認証を承認とする。ＭＡＣ検証に失敗した場合、パケット認証を否認と報告するようにすればよい。

変形例３に係るデータ構造における先頭のＲＳＵパケットを、図８のセキュリティフレームと同じ構造としてもよい。また、変形例３に係るデータ構造における後続のＲＳＵパケットについては、「公開鍵証明書のダイジェスト」を暗号化の対象外としているが、「公開鍵証明書のダイジェスト」も暗号化の対象に含めるようにしてもよいし、「データ長」と「公開鍵証明書のダイジェスト」を転置して、「データ長」に対して「ペイロード」あるいは、暗号対象データのバイト数を代入するようにしてもよい。また、変形例２と同様、１つの基地局装置２０が複数のＲＳＵ期間を使用する場合、スーパーフレームに送信する先頭のＲＳＵパケットと、それ以外の後続のＲＳＵパケットでセキュリティフレームのデータ構造を分けるようにしてもよい。

変形例１および変形例２は、端末装置１０が、基地局装置２０の電波到達距離内に入ると、最初にＲＳＵ期間の先頭のＲＳＵパケットを選択して検証を行う。この時、公開鍵証明書およびメッセージの検証によって、基地局装置２０の正当性とパケット信号に含まれるアプリケーションデータの完全性と真正性が確認される。承認された場合、当該ＲＳＵパケットが正規の基地局装置２０から発信された正規のパケット信号であることが確認されたことになる。また、通信の性格上、当該ＲＳＵパケットが送信されたＲＳＵ期間は、正規の基地局装置２０は送信期間であることが確定する。以降のＲＳＵパケットでは、公開鍵証明書のダイジェストの一致確認とＭＡＣ検証によってパケット信号に含まれるアプリケーションデータの完全性と真正性を確認する。一方、端末装置１０が、基地局装置２０の電波到達距離外に出て、同じサブフレームを使用する別の基地局装置２０の電波到達距離内に入ると、公開鍵証明書のダイジェストが一致しないので、再び、署名の検証を行うこととなる。変形例３は、ＲＳＵ期間単位で処理を閉じる。ＲＳＵ期間の先頭ＲＳＵパケットに対して、公開鍵証明書およびメッセージの検証を行い、基地局装置２０の正当性とパケット信号に含まれるアプリケーションデータの完全性と真正性を確認する。後続のＲＳＵパケットに対しては公開鍵証明書のダイジェストの一致確認とＭＡＣ検証によってパケット信号に含まれるアプリケーションデータの完全性と真正性を確認する。

次に、変形例４を説明する。図１８に示した変形例２では、各ＲＳＵパケットにＭＡＣが含まれている。変形例４では、先頭以外のＲＳＵパケットに対して、ＭＡＣを配置させず、それらのＭＡＣも先頭パケットにまとめて配置させる。つまり、先頭パケットには、ＲＳＵ期間に含まれた各ＲＳＵパケットに対するＭＡＣが含まれている。図２０（ａ）−（ｃ）は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の変形例４を示す。図２０（ａ）は、図３（ｂ）に示された路車送信期間、つまり図５に示されたＲＳＵ期間に含まれた複数のＲＳＵパケットのうち、先頭パケットのフォーマットを示す。

これは、図５のＲＳＵパケット１に相当する。図示のごとく、「Ｖｅｒ」、「メッセージ形式」、「パケットＩＤ」、「公開鍵証明書」、「鍵ＩＤ」、「ＭＡＣリスト」、「電子署名」、「Ｎｏｎｃｅ」、「データ長」、「ペイロード」が順に配置される。「Ｖｅｒ」、「メッセージ形式」、「公開鍵証明書」、「鍵ＩＤ」、「電子署名」、「Ｎｏｎｃｅ」、「データ長」、「ペイロード」は、これまでと同一であるので、ここでは説明を省略する。パケットＩＤでは、ＲＳＵ期間に含まれる複数のＲＳＵパケットを識別するための番号が示される。具体的には、ＲＳＵ期間に含まれる複数のＲＳＵパケットの先頭から順に、パケットＩＤが「０」、「１」、・・・のように規定される。そのため、先頭パケットでは、パケットＩＤとして「０」が示される。

「ＭＡＣリスト」の構成は、図２０（ｂ）に示される。図示のごとく、「パケット数」、「ＭＡＣ（Ｐ０）」、「ＭＡＣ（Ｐ１）」、・・・、「ＭＡＣ（Ｐｎ−１）」が含まれる。「パケット数」は、ＲＳＵ期間に含まれるＲＳＵパケット数を示す。したがって、ＭＡＣリストに列挙されている「ＭＡＣ（Ｐｉ）」（０≦ｉ＜ｎ、ｉは自然数）の数ｎが代入される。「ＭＡＣ（Ｐ０）」は、パケットＩＤ「０」に対するＭＡＣを示し、「ＭＡＣ（Ｐ１）」は、パケットＩＤ「１」に対するＭＡＣを示す。「パケット数」がｎである場合、「ＭＡＣ（Ｐｎ−１）」までが含まれる。図２０（ａ）に戻る。ここでは、「ＭＡＣリスト」、「電子署名」が署名対象であり、「Ｎｏｎｃｅ」、「データ長」、「ペイロード」がＭＡＣ対象であり、ペイロードが暗号対象である。なお、暗号化はなされなくてもよい。

図２０（ｃ）は、後続のＲＳＵパケットのフォーマットを示す。これは、図５のＲＳＵパケット２からＲＳＵパケット７のそれぞれに相当する。図示のごとく、「Ｖｅｒ」、「メッセージ形式」、「パケットＩＤ」、「公開鍵証明書ダイジェスト」、「鍵ＩＤ」、「Ｎｏｎｃｅ」、「データ長」、「ペイロード」が順に配置される。パケット数がｎである場合、パケットＩＤでは、「１」、「２」、・・・「ｎ−１」が示される。図２０（ｃ）では、図１８の後続の先頭ＲＳＵパケットとは異なり、鍵ＩＤが含まれない。これは、変形例４においてすべてのＲＳＵパケットに対するＭＡＣは、先頭パケットに含まれており、かつ共通の鍵ＩＤの通信鍵がＭＡＣの生成に使用されているからである。

基地局装置２０のセキュリティ処理部１５は、すべてのＲＳＵパケットに対する「ＭＡＣ」を生成し、次いで、生成したＭＡＣを含む「ＭＡＣリスト」に対する「電子署名」を生成する。セキュリティ処理部１５は、それらを先頭パケットに含める。端末装置１０の検証部１５１は、ＲＳＵ期間の先頭パケットに含まれる公開鍵証明書および公開鍵証明書に含まれる公開鍵を使用して電子署付き「ＭＡＣリスト」の検証を実行することによって、基地局装置２０の正当性とパケット信号に含まれるアプリケーションデータの真正性を確認する。それらの検証が成功した場合、つまり承認された場合、当該ＲＳＵパケットが正規の基地局装置２０から発信された正規のパケット信号であることが確認されたことになる。また、前述のごとく、当該ＲＳＵパケットが送信されたＲＳＵ期間は、正規の基地局装置２０は送信期間であることが確定する。当該ＲＳＵ期間の先頭パケットにおける公開鍵暗号方式による２つの検証に成功した後は、先頭のパケットについては公開鍵証明書のダイジェストの比較と、ＭＡＣ（Ｐ０）を用いたメッセージの検証を、後続するパケットでは、公開鍵暗号方式による２つの検証が成功した、あるいは、公開鍵証明書のダイジェストの比較に成功した先頭パケットに含まれるＭＡＣ（Ｐｉ）、（０＜ｉ＜ｎ、ｉは自然数）を用いたメッセージ認証を実行する。

変形例４によれば、ＭＡＣを先頭パケットに集約するので、先頭パケット以外のＲＳＵパケットの伝送効率を向上できる。また、すべてのＲＳＵパケットの鍵ＩＤを共通にするので、すべてのＲＳＵパケット全体の伝送効率を向上できる。また、公開鍵暗号方式による認証処理の高速化を受けて、変形例３と同じように、ＲＳＵ期間単位で処理を閉じることもできる。

次に、変形例５を説明する。変形例５では、変形例４と比較して、「ペイロード」が電子署名の対象であり、「ＭＡＣリスト」および「電子署名」が暗号対象である点が異なる。図２１（ａ）−（ｂ）は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の変形例５を示す。図２１（ａ）は、先頭パケットのフォーマットを示し、図２１（ｂ）は、先頭パケット以外のＲＳＵパケットのフォーマットを示す。図２１（ａ）では、図２０（ａ）と比較して、ＭＡＣ対象および暗号対象が異なるので、「ＭＡＣリスト」と「電子署名」の位置が異なっている。一方、図２１（ｂ）は、図２０（ｂ）と同様である。変形例４に対して、基地局装置２０および端末装置１０では、署名処理、暗号処理を除いて変形例３と同様の処理がなされればよいので、ここでは説明を省略する。変形例４によれば、ＭＡＣリストが暗号対象にされるので、セキュリティ特性を向上できる。

なお、変形例４および変形例５のＲＳＵ期間の後続するパケットに、当該パケットを発信する基地局装置２０を簡易に確認するために「公開鍵証明書ダイジェスト」を含めているが、省略しても構わない。該ＲＳＵ期間の先頭パケットにおける公開鍵暗号方式による２つの検証に成功した時に使用した公開鍵証明書のダイジェストと、先頭のパケットに含まれる公開鍵証明書のダイジェストとを比較して、一致した場合に、ＭＡＣ（Ｐｉ）（０≦ｉ＜ｎ、ｉは自然数）を取り出す。したがって、取り出したＭＡＣは、正規の基地局装置２０から発信された正当な値であると判断する。この場合、ＲＳＵ期間の後続するパケットに対する公開鍵証明書のダイジェスト比較は省略される。

次に、変形例６を説明する。変形例６は、ＲＳＵ期間に含まれた複数のＲＳＵパケットすべてに対してひとつの電子署名とひとつのＭＡＣを生成する。図２２（ａ）−（ｃ）は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の変形例６を示す。図２２（ａ）は、先頭パケットのフォーマットを示し、図２２（ｂ）は、ＲＳＵ期間に含まれた複数のＲＳＵパケットのうち、先頭パケットと最後のＲＳＵパケット以外のＲＳＵパケットのフォーマットを示す。さらに、図２２（ｃ）は、最後のＲＳＵパケットのフォーマットを示す。図２２（ａ）における「パケット総数」は、ＲＳＵ期間に含まれたＲＳＵパケットの総数を示し、「ペイロード長」は、図２２（ａ）−（ｃ）に含まれたペイロードの合計バイト数を示す。一方、図２２（ａ）−（ｃ）の「データ長」は、当該パケットにおける暗号対象のバイト数を示す。また、図２２（ａ）および図２２（ｂ）において、電子署名およびＭＡＣは含まれない。一方、図２２（ｃ）のみに電子署名およびＭＡＣが含まれる。

変形例６のセキュリティフレームのデータ構造では、先頭パケットのみに「パケット総数」を含めているが、すべてのパケットに対して、「パケット総数」を含めてもよい。例えば、先頭パケットと同様に、「パケットＩＤ」と「パケット総数」を並べて配置すればよい。

基地局装置２０のセキュリティ処理部１５は、分割前のペイロードに対して、電子署名およびＭＡＣを生成した後、ペイロードを複数に分割する。分割数は、ＲＳＵ期間に含まれるＲＳＵ数に相当する。セキュリティ処理部１５は、分割したペイロードをもとに、図２２（ａ）−（ｃ）に示されたフォーマットのＲＳＵパケットを生成する。その際、前述のごとく、最後のＲＳＵパケットのみに電子署名およびＭＡＣが配置される。端末装置１０の検証部１５１は、パケットＩＤをもとに、ＲＳＵ期間に含まれた複数のＲＳＵパケットを合成する。以下、合成したＲＳＵパケットは連結パケットと呼ばれる。検証部１５１は、連結パケットに含まれる公開鍵証明書および電子署付きメッセージの検証を実行することによって、基地局装置２０の正当性とパケット信号に含まれるアプリケーションデータの真正性を確認する。それらの検証が成功した場合、つまり承認された場合、当該連結パケットが正規の基地局装置２０から発信された正規のパケット信号であることが確認されたことになる。さらに、検証部１５１は、公開鍵証明書のダイジェストの比較と、ＭＡＣ付きメッセージの検証を実行する。変形例５によれば、複数のＲＳＵパケットのすべてに対して、ひとつの電子署名とひとつのＭＡＣが配置されるので、伝送効率を向上できる。

さらに、すべてのパケットに対してＭＡＣを配置した変形例１、２、４、５および、１つのＲＳＵ期間におけるすべてのパケット結合した変形例６のセキュリティフレームのデータ構造を採用することで、公開鍵暗号による検証処理を実装しないで共通鍵暗号のみ、すなわち、暗号化データの復号とＭＡＣ検証のみに対応した低コストの端末装置１０を提供することも可能となる。この端末装置１０は、なりすまし検知、改ざんの検知の効果を得ることができる。

また、変形例１、２、５および６では、「電子署名」をＭＡＣ対象としたが、必ずしもＭＡＣ対象に含める必要はない。含めない場合でも同様な効果が得られる。なお、本発明におけるセキュリティフレームの一例、別の例、変形例１〜６において、主に「ペイロード」を暗号対象として暗号化するように説明したが、必ずしも暗号化する必要はなく、「ペイロード」を秘匿する必要がない場合には暗号化を行わないで平文としてよい。

実施例１および変形例において、「鍵ＩＤ」が配置されているが、それの代わりに暗号化された通信鍵が配置されていてもよい。

（実施例２）
本発明の実施例２の基礎となった知見は、次の通りである。リアルタイム性を重視する必要がある路車間通信および車車間通信では、共通鍵暗号化方式を採用することが有力である。しかしながら、路車間通信および車車間通信を同じ共通鍵で運用すると、その鍵が漏洩した場合、路車間通信および車車間通信の両方のセキュリティが破れてしまう。

実施例２はこうした状況に鑑みてなされたものであり、その目的は、共通鍵暗号化方式を用いた通信システムのセキュリティを効率的に向上させる技術を提供することにある。

実施例２の一態様の概要は、次の通りである。実施例２のある態様の端末装置は、暗号化されたパケット信号を受信する受信部と、前記パケット信号を復号する復号部と、を備える。前記パケット信号は共通鍵暗号方式により暗号化されており、基地局装置から報知されるパケット信号と、他の端末装置から報知されるパケット信号とで異なる運用方式により暗号化される。

この態様によれば、共通鍵暗号化方式を用いた通信システムにおいて、路車間通信と車車間通信とで異なる運用方式を併用することにより、通信システム全体のセキュリティを効率的に向上させることができる。

前記基地局装置から報知されるパケット信号は、前記他の端末装置から報知されるパケット信号よりセキュリティレベルの高い運用方式により暗号化されてもよい。これによると、高い信頼性が要求されるデータが含まれることが多い前者のパケット信号を、後者のパケット信号よりセキュリティレベルの高い運用方式により暗号化することにより、通信システム全体の処理負荷の増大を抑制しつつ、セキュリティ確保を図ることができる。

前記基地局装置から報知されるパケット信号は、パケット送信のたびに生成される通信鍵により暗号化されてもよい。前記他の端末装置から報知されるパケット信号は、端末装置間で共有されている、複数の通信鍵を含む鍵テーブル内のいずれかの通信鍵により暗号化されてもよい。これによると、高い信頼性が要求されるデータが含まれることが多い前者のパケット信号を、後者のパケット信号よりセキュリティレベルの高い運用方式により暗号化することにより、通信システム全体の処理負荷の増大を抑制しつつ、セキュリティ確保を図ることができる。

前記基地局装置と本端末装置間でマスタ鍵が共有されてもよい。前記基地局装置から報知されるパケット信号には、前記マスタ鍵により暗号化された通信鍵が含まれてもよい。前記他の端末装置から報知されるパケット信号は、前記鍵テーブル内から選択された通信鍵の識別情報が含まれてもよい。これによると、高い信頼性が要求されるデータが含まれることが多い前者のパケット信号を、後者のパケット信号よりセキュリティレベルの高い運用方式により暗号化することにより、通信システム全体の処理負荷の増大を抑制しつつ、セキュリティ確保を図ることができる。

前記基地局装置から報知されるパケット信号に含まれるメッセージに、公開鍵暗号方式により暗号化された電子署名が付加されてもよい。これによると、前記基地局装置から報知されるパケット信号のセキュリティを向上させることができる。

図２３は、セキュリティフレームのデータ構造の一例を示す。これは、図４（ｅ）の内容を詳細にした図である。セキュリティヘッダには、バージョン（ＶＥＲ）、メッセージタイプ（ＭＴ）、鍵情報、Ｎｏｎｃｅおよびデータ長を含む。バージョン（ＶＥＲ）はフレームフォーマットのバージョンを示し、固定値（＝０）である。バージョン（ＶＥＲ）のデータ長は１バイトである。メッセージタイプ（ＭＴ）はメッセージのタイプ、データ認証方式などを指定する。メッセージタイプ（ＭＴ）のデータ長は０．５バイトである。当該データ長の最上位ビット（ＭＳＢ）は管理アプリフラグであり、管理フィールドの有無を示す。「０」が無し、「１」が有りを示す。ビット２はデータ認証方式を示す。「０」がメッセージ認証コード（ＭＡＣ：Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）方式、「１」が電子署名方式を示す。ビット１および最下位ビット（ＬＳＢ）はメッセージ形式を示す。「０」が認証無しデータ、「１」が認証付きデータ、「２」が認証付き暗号化データ、「３」が予約を示す。

鍵情報は、フラグ、マスタ鍵、通信鍵および鍵ＩＤを含む。マスタ鍵、通信鍵および鍵ＩＤはオプションである。フラグは鍵情報内の後続フィールドの有無を示す。フラグのデータ長は０．５バイトである。最上位ビット（ＭＳＢ）がマスタ鍵（暗号化されていてもよい）、ビット２が通信鍵（暗号化されていてもよい）、ビット１が鍵ＩＤ、最下位ビット（ＬＳＢ）が予約（＝０）を示す。各ビットにおいて「０」が無しを示し、「１」が有りを示す。したがって、すべてのビットが「０」の場合、当該フィールドは省略されることを示す。マスタ鍵は直前のマスタ鍵で暗号化された新マスタ鍵を示す。マスタ鍵のデータ長は１６バイトである。通信鍵は最新のマスタ鍵で暗号化された通信鍵を示す。通信鍵のデータ長は１６バイトである。鍵ＩＤは鍵テーブルを参照するための識別番号を示す。鍵ＩＤのデータ長は１バイトである。Ｎｏｎｃｅは発信元情報および発信日時を含む。発信元情報は発信元の機器ＩＤを示す。発信元情報のデータ長は４バイトである。発信日時はメッセージの送信日時またはカウンタ値を示す。発信日時のデータ長は６バイトである。データ長はペイロードのバイト長を示す。データ長は１〜２バイトの範囲である。なお、実施例１同様、Ｎｏｎｃｅは乱数であってもよい。

ペイロードは通信鍵による秘匿およびメッセージ認証対象となる。ペイロードは管理アプリおよびサービスアプリを含む。管理アプリは、セキュリティ管理アプリケーションデータを示し、オプションである。サービスアプリはアプリケーションデータを示す。管理アプリおよびサービスアプリのデータ長は可変である。

セキュリティフッタはデータ認証を含む。データ認証はＭＡＣまたは電子署名を示す。データ認証のデータ長は前者のとき１２バイトで、後者のとき５６バイトである。

図２４は、実施例２に係る基地局装置２０の構成を示す。基地局装置２０は、アンテナ２１、ＲＦ部２２、変復調部２３、ＭＡＣフレーム処理部２４、セキュリティ処理部２５、データ生成部２６、ネットワーク通信部２７、記憶部２８および制御部２９を備える。セキュリティ処理部２５は暗復号部２５６、暗号部２５７および鍵更新部２５８を含む。以下、図９の実施例１に係る基地局装置２０と重複する説明を省略し、それとの相違点を説明する。

ネットワーク通信部２７は、外部ネットワーク２００に接続される。ネットワーク通信部２７は、外部ネットワーク２００から工事や渋滞などに関する道路情報を受けつける。また、本実施例では後述するシステム運用管理装置から提供される、路車間通信用のマスタ鍵（以下、路車間マスタ鍵という）、機器ネガリスト、暗号化更新鍵テーブルおよびテーブル更新鍵を受けつける。なお、機器ネガリストとはシステム運用管理装置から提供される共通鍵テーブルを追加または更新すべきでない端末装置１０のリストをいう。機器ネガリストに登録される機器は、機器に不具合が発見され、メーカによる回収が進められている機器や、盗難届が出されている機器などが該当する。

また、ネットワーク通信部２７は、セキュリティ処理部２５による処理結果を外部ネットワーク２００へ出力したり、記憶部２８に蓄積して、定期的に外部ネットワーク２００へ出力したりする。

記憶部２８は、種々の情報（たとえば、路車間マスタ鍵、共通鍵テーブル、テーブル更新鍵）を記憶する。本実施例では、外部ネットワーク２００から取得される道路情報、後述するシステム運用管理装置から提供される、新しい路車間マスタ鍵、機器ネガリスト、暗号化更新鍵テーブルおよびテーブル更新鍵、ならびに端末装置１０から提供される機器ＩＤおよび共通鍵テーブルＩＤ（以下適宜、テーブルＩＤという）を一時的に記憶する。制御部２９は、基地局装置２０全体の処理を制御する。データ生成部２６は、センサやカメラ（図示されない）などからの情報や、記憶部２８に記憶されている情報を利用してサービスアプリケーションデータを生成する。そして、サービスアプリケーションデータの内容によって、メッセージ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部２５に出力する。

セキュリティ処理部２５は、セキュリティフレームを生成または解釈する。セキュリティ処理部２５は、送信処理として、データ生成部２６からサービスアプリケーションデータを受け取ると、ＭＡＣフレーム処理部２４に出力すべきセキュリティフレームを、受け取ったサービスアプリケーションデータと記憶部２８に記憶されているデータをもとに生成する。たとえば、図２３に示すペイロードのサービスアプリに、データ生成部２６から受け取ったサービスアプリケーションデータをセットし、そのデータ長をセキュリティヘッダのデータ長にセットする。また、セキュリティヘッダの鍵情報の通信鍵に、路車間マスタ鍵で暗号化された通信鍵（乱数）をセットする。また、当該通信鍵（乱数）を用いて求めたＭＡＣをセキュリティフッタにセットする。そして、その他のセキュリティヘッダを付加してセキュリティフレームを生成する。その後、指定されたメッセージ形式が認証付き暗号化データの場合、ペイロードおよびＭＡＣを当該通信鍵（乱数）を用いて暗号化することで、メッセージを秘匿することも可能である。

セキュリティ処理部２５は、受信処理として、ＭＡＣフレーム処理部２４からのセキュリティフレームを受けつける。セキュリティ処理部２５は、セキュリティフレームのうちのセキュリティヘッダの内容を確認する。メッセージタイプが認証付きデータである場合、暗復号部２５６にてメッセージの検証処理を実行する。メッセージタイプが認証付き暗号化データである場合、暗復号部２５６にてメッセージの復号処理を実行し、検証処理を実行する。なお、メッセージタイプが平文である場合、これらの処理は省略される。

セキュリティ処理部２５は、暗復号部２５６、暗号部２５７および鍵更新部２５８を含む。本実施例では、基地局装置２０からのパケット送信に注目するため、送信処理として実行されるセキュリティフレームを生成する処理に注目する。受信処理として行われるセキュリティフレームを解釈する処理については、後述する端末装置１０の受信処理と同じである。暗復号部２５６は、通信鍵を用いてペイロードを対象としたＭＡＣを生成する。ＭＡＣは、ＡＥＳ−ＣＢＣモードを利用したＣＢＣ−ＭＡＣアルゴリズムを適用して生成される。なお、ＭＡＣの生成には、Ｎｏｎｃｅやデータ長も利用される。次いで、メッセージ形式が認証付き暗号化データの場合、通信鍵を用いてペイロードとセキュリティフッダの暗号化が行われる。暗号化は、ＡＥＳ＿ＣＴＲ（ＣｏｕｎＴｅＲ）モードを適用する。本実施例では、暗復号部２５６は、メッセージ形式が認証付き暗号化データの場合には、通信鍵（乱数）を用いたＡＥＳ−ＣＣＭモードを適用したため、ペイロードに対するＭＡＣの付加およびペイロードとＭＡＣの暗号化を行う。なお、ＡＥＳ―ＣＣＭモードを適用せずに、ペイロードより暗号化を行った後、ＭＡＣの付加を行ってもよいし、ＭＡＣの付加および暗号化のいずれか一方のみを行ってもよい。なお、ペイロードを対象としたＭＡＣの生成、および、ペイロードとセキュリティフッダの暗号化には、通信鍵の他に、Ｎｏｎｃｅやデータ長が利用される。ＣＢＣ−ＭＡＣおよびＣＣＭモードのアルゴリズムによるものであり、Ｎｏｎｃｅの使用により、ペイロードと通信鍵が同じであっても、異なったＭＡＣ、暗号化の結果が得られる。

暗号部２５７は、基地局装置２０より端末装置１０に対して送信する鍵を暗号化する。具体的には、暗復号部２５６で使用した通信鍵（乱数）を路車間マスタ鍵で暗号化する。また、暗号部２５７は、路車間通信で使用する路車間マスタ鍵を更新する際、現路車間マスタ鍵で新路車間マスタ鍵を暗号化する。また、暗号部２５７は、車車間通信で使用する共通鍵テーブルを更新する際、現テーブル更新鍵で新テーブル更新鍵を暗号化する。

鍵更新部２５８は、路車間マスタ鍵の更新処理を行う。また、端末装置１０が保持すべき共通鍵テーブルの更新処理を行う。これらの更新処理の詳細は後述する。

図２５は、実施例２に係る、車両１００に搭載された端末装置１０の構成を示す。端末装置１０は、アンテナ１１、ＲＦ部１２、変復調部１３、ＭＡＣフレーム処理部１４、セキュリティ処理部１５、受信処理部１６１、通知部１６２、データ生成部１７、記憶部１８および制御部１９を備える。セキュリティ処理部１５は、暗復号部１５６、復号部１５７および鍵更新部１５８を含む。以下、図１０の実施例１に係る端末装置１０と重複する説明を省略し、それとの相違点を説明する。

データ生成部１７は、図示しないＧＰＳ受信機、ジャイロスコープ、車速センサなどから供給される情報にもとづき、端末装置１０が搭載された車両１００の現在位置、進行方向、移動速度などを特定する。なお、現在位置は、緯度・経度によって示される。これらの情報の特定方法は一般的な公知の技術により実現可能であるため、ここでは説明を省略する。データ生成部１７は、特定した情報をもとに他の端末装置１０や基地局装置２０に報知すべきデータを生成し、生成したデータ（以下、アプリケーションデータという）をセキュリティ処理部１５に出力する。そして、アプリケーションデータの内容によって、メッセージ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部１５に出力する。また、特定した情報を受信処理部１６１に自車の車両情報として出力する。

記憶部１８は、種々の情報（たとえば、路車間マスタ鍵、共通鍵テーブル、テーブル更新鍵）を記憶する。また、本実施例では基地局装置２０から取得される道路情報、自己または他の端末装置１０から取得される車両情報、ならびに基地局装置２０から取得される新しい暗号化路車間マスタ鍵、暗号化更新共通鍵テーブルおよび暗号化テーブル更新鍵を一時的に保持する。制御部１９は、端末装置１０全体の処理を制御する。

セキュリティ処理部１５は、送信処理として、セキュリティフレームを生成または解釈する。セキュリティ処理部１５は、ＭＡＣフレーム処理部１４に出力すべきセキュリティフレームを、記憶部１８に記憶されたデータをもとに生成する。たとえば、図２３に示すペイロードのサービスアプリにアプリケーションデータをセットする。また、セキュリティヘッダの鍵情報の鍵ＩＤに、ＭＡＣ生成に使用する通信鍵の鍵ＩＤをセットし、Ｎｏｎｃｅに自己の機器ＩＤと時刻をセットする。また、鍵ＩＤによって共通鍵テーブルより選択された通信鍵を用いて生成されるＭＡＣをセキュリティフッタにセットする。そして、その他のセキュリティヘッダを付加してセキュリティフレームを生成する。メッセージ形式が、認証付き暗号化データの場合、ペイロードおよびＭＡＣを当該通信鍵を用いて暗号化することで、メッセージを秘匿する。なお、メッセージタイプが平文である場合、これらの処理は省略される。

セキュリティ処理部１５は、受信処理として、ＭＡＣフレーム処理部１４からのセキュリティフレームを受けつける。セキュリティ処理部１５は、セキュリティフレームのうちのセキュリティヘッダの内容を確認する。メッセージタイプが認証付きデータである場合、暗復号部１５６にてメッセージの検証処理を実行する。メッセージ形式が認証付き暗号化データである場合、暗復号部１５６にてメッセージの復号処理および検証処理を実行する。なお、メッセージ形式が平文である場合、これらの処理は省略される。

セキュリティ処理部１５は、暗復号部１５６、復号部１５７および鍵更新部１５８を含む。暗復号部１５６は、ペイロードに対するＭＡＣの生成と検証および、ペイロードとＭＡＣに対する暗号化および復号を行うことができる。すなわち、セキュリティヘッダのメッセージタイプのメッセージ形式に従った処理を行い、基地局装置２０の暗復号部２５６と同等の機能を備える。したがって、送信処理は、基地局装置２０の暗復号部２５６と同じであるため説明を割愛する。暗復号部１５６は、受信処理として、ＭＡＣフレーム処理部１４からセキュリティフレームを受け取る。メッセージ形式が認証付き暗号化データの場合、暗復号部１５６は、通信鍵を用いてペイロードとセキュリティフッタを復号する。そして、ペイロードに付加されたＭＡＣを検証する。メッセージ形式が暗号化データの場合、暗復号部１５６は、通信鍵を用いてペイロードを復号する。なお、復号および検証は送信側の暗号アルゴリズムに対応する復号アルゴリズムにより実行される。また、メッセージ形式が平文である場合、暗復号部１５６は復号および検証を実行しない。

復号部１５７は、基地局装置２０から報知されるパケット信号に含まれる通信鍵（乱数）を路車間マスタ鍵で復号する。また、路車間通信で使用する路車間マスタ鍵が更新される際、復号部１５７は基地局装置２０から報知されるパケット信号に含まれる暗号化新マスタ鍵を現路車間マスタ鍵で復号する。また、車車間通信で使用される共通鍵テーブルが更新される際、復号部１５７は基地局装置２０から報知されるパケット信号に含まれる暗号化テーブル更新鍵を現テーブル更新鍵で復号する。

鍵更新部１５８は、自己（端末装置１０）が保持すべき路車間マスタ鍵の更新処理および車車間通信用の共通鍵テーブルの更新処理を行う。鍵更新部１５８のこれらの更新処理の詳細は後述する。

図２６は、実施例２に係る通信システム５００を用いた路車間通信における通常のメッセージ送受信手順を説明するための図である。基地局装置２０の暗復号部２５６は、通信鍵とすべき乱数を発生させる。暗復号部２５６は、平文の送信データに対して当該通信鍵を用いて、ＭＡＣを付加して、ＭＡＣ付きの送信データを暗号化する。それとともに、暗号部２５７は当該通信鍵を路車間マスタ鍵を用いて暗号化する。これらの暗号化にはいずれも共通鍵暗号化方式が用いられる。セキュリティ処理部２５は、暗号化送信データと暗号化通信鍵を格納したパケット信号を生成する。当該パケット信号は、ＭＡＣフレーム処理部２４および変復調部２３を経て、ＲＦ部２２からアンテナ２１を介して外部に報知される。

端末装置１０のＲＦ部１２は、当該パケット信号をアンテナ１１を介して受信する。当該パケット信号は、変復調部１３およびＭＡＣフレーム処理部１４を経て、セキュリティ処理部１５に渡される。復号部１５７は、当該パケット信号に格納された暗号化通信鍵を、基地局装置２０と共通している路車間マスタ鍵で復号する。暗復号部１５６は、当該パケット信号に格納された暗号化送信データを、復号された通信鍵で復号し、ＭＡＣ検証する。復号化およびＭＡＣ検証が成功したら、暗号化送信データは平文の送信データに復元される。

このメッセージ送受信方法には以下に示す様々なメリットがある。まず、動的に通信鍵を変えることができるので、後述する車車間通信におけるメッセージ送受信方法のように事前に複数の通信鍵を保持しておく必要がない。また、通信鍵として乱数を暗号化するため、通信路中から路車間マスタ鍵が漏洩するリスクが小さい。路車間マスタ鍵が漏洩しない限り、基本的に、システム運用管理機関や路車間サービス提供者は何もしなくてよい。また、路車間マスタ鍵が漏洩しても、マスタ鍵の更新の仕組みが知られない限り、通信鍵が漏洩するリスクは小さい。さらに、路車間通信により路車間マスタ鍵を更新することにより、漏洩リスクを低減できる。更新されるデータ量が少ないため、路車間マスタ鍵の更新は、路車間通信で十分に対応可能である。

図２７は、実施例２に係る通信システム５００を用いた路車間通信における路車間マスタ鍵の更新手順を説明するための図である。システム運用管理機関のシステム運用管理装置３００は、更新用の新しい路車間マスタ鍵を生成する。この更新用の新しい路車間マスタ鍵は、定期的に生成されてもよいし、路車間マスタ鍵の漏洩が発覚した場合に生成されてもよいし、その両方であってもよい。システム運用管理装置３００は、路車間サービス提供者の路車間サービス提供者端末装置４００に、新しい路車間マスタ鍵を伴うマスタ鍵更新通知を発行する。

路車間サービス提供者端末装置４００は、システム運用管理装置３００から当該更新通知を受けると、基地局装置２０に新しい路車間マスタ鍵を伴う更新指示を発行する。なお、システム運用管理機関と路車間サービス提供者間、路車間サービス提供者と基地局装置２０との間の新しい路車間マスタ鍵の受け渡しは、通信システム５００以外のバックインフラを用いて行われる。たとえば、専用回線などのセキュリティが保証されている通信網を用いてもよいし、記録メディアの配布により行われてもよい。

基地局装置２０の鍵更新部２５８は、新しい路車間マスタ鍵を受けつけると、自己の路車間マスタ鍵を更新する。具体的には、現路車間マスタ鍵を、前路車間マスタ鍵として、受けつけた新しい路車間マスタ鍵を現路車間マスタ鍵として、記憶部２８に記録する。そして、更新後の一定期間、現路車間マスタ鍵（受け付けた新しい路車間マスタ鍵）をパケット信号に格納して報知するように制御する。暗号部２５７は、現路車間マスタ鍵（受け付けた新しい路車間マスタ鍵）を前路車間マスタ鍵を用いて暗号化する。この暗号化には共通鍵暗号化方式が用いられてもよいし、公開鍵暗号化方式が用いられてもよい。暗号化された新しい路車間マスタ鍵は、パケット信号に格納されて報知される。

端末装置１０の復号部１５７は、当該パケット信号に格納された暗号化路車間マスタ鍵を自身の保持する現路車間マスタ鍵を用いて復号する。鍵更新部１５８は、復号部１５７より復号された路車間マスタ鍵を受け取ると、自身の保持する現路車間マスタ鍵より、受け取った路車間マスタ鍵が新しい時に、現路車間マスタ鍵を、受け取った路車間マスタ鍵に置き換え（記憶部１８に保持される路車間マスタ鍵も更新する。）、この新しい路車間マスタ鍵を更新後の正当な路車間マスタ鍵とする。

なお、不正な基地局装置（いわゆる、なりすまし）は、基本的に、バックインフラを介して新しい路車間マスタ鍵を受け付けることができないため、少なくとも路車間マスタ鍵の更新後は、不正なメッセージを端末装置１０に送り込むことができなくなる。すなわち、不正な基地局装置が現路車間マスタ鍵を知っている場合（すなわち、現路車間マスタ鍵が漏洩した場合）でも、新しい路車間マスタ鍵も知っていなければ、不正なメッセージを端末装置１０に送り込むことができなくなる。新しい路車間マスタ鍵を知るには、路車間マスタ鍵更新の仕組みも知っていること（すなわち、仕様の漏洩）が条件となる。なお、新しい路車間マスタ鍵が公開鍵暗号方式で暗号化されている場合、不正な基地局装置はその秘密鍵を知っていることも条件となる。これらの条件をすべて満たす可能性は非常に低いと考えられる。なお、仮に現路車間マスタ鍵が漏洩しても、不正な基地局装置が出現するまで放置するという選択肢もあり得る。

図２８は、路車間通信において生成されるパケットに含まれるセキュリティフレームのデータ構造の一例を示す。図２８において左側のセキュリティフレームが通常メッセージ送受信時のデータ構造を示し、右側のセキュリティフレームが路車間マスタ鍵更新時のデータ構造を示す。通常メッセージ送信時のセキュリティフレームのデータ構造では、ヘッダとして「バージョン」、「メッセージタイプ」、「通信鍵」および「ＮＯＮＣＥ」が配置され、その後に「ペイロード」が配置され、最後にフッタとして「ＭＡＣ」が配置される。この例では、「ペイロード」がＭＡＣ対象である。「通信鍵」に格納される通信鍵（乱数）は路車間マスタ鍵により暗号化され、秘匿される。当該通信鍵（乱数）により「ＭＡＣ」が生成され、当該通信鍵（乱数）により「ペイロード」および「ＭＡＣ」が暗号化されて、秘匿される。

路車間マスタ鍵更新時のセキュリティフレームのデータ構造では、通常メッセージ送信時のセキュリティフレームのデータ構造と比較し、「メッセージ形式」と「通信鍵」との間に「マスタ鍵」が挿入される。「マスタ鍵」には新しい路車間マスタ鍵が格納され、現路車間マスタ鍵により暗号化され、秘匿される。また、「ペイロード」内に「機器管理」として路車間マスタ鍵のバージョン情報が格納される。その他は、通常メッセージ送信時のセキュリティフレームと同様である。なお、端末装置１０の鍵更新部１５８は、暗復号部１５６により「ＭＡＣ」検証が成功した後に、路車間マスタ鍵を更新する。図２３に戻る。通常メッセージ送信時は、鍵情報のフラグに６（２進：０１１０）がセットされる。すなわち、通信鍵および鍵ＩＤが設定される。通信鍵には、現路車間マスタ鍵で暗号化された通信鍵（乱数）が、鍵ＩＤに通信鍵を暗号化している路車間マスタ鍵のバージョン情報がセットされる。路車間マスタ鍵更新時は、鍵情報のフラグに１４（２進：１１１０）がセットされる。すなわち、マスタ鍵、通信鍵および鍵ＩＤが設定され、マスタ鍵に暗号化されたマスタ鍵が、通信鍵に現路車間マスタ鍵で暗号化された通信鍵（乱数）が、鍵ＩＤに通信鍵を暗号化している路車間マスタ鍵のバージョン情報がセットされる。なお、鍵ＩＤに通信鍵を暗号化している路車間マスタ鍵のバージョンをセットすることなく、路車間マスタ鍵の更新の判定ができれば、鍵ＩＤを使用する必要がない。鍵情報のフラグには、通常メッセージ送信時は４（２進：０１００）が、路車間マスタ鍵更新時は１２（２進：１１００）がセットされることになる。

図２９は、実施例２に係る通信システム５００を用いた車車間通信における通常のメッセージ送受信手順を説明するための図である。端末装置１０の暗復号部１５６は、少なくとも一つの共通鍵テーブルに格納された複数の通信鍵の中から一つの通信鍵をランダムに選択する。暗復号部１５６は、平文の送信データに対して当該通信鍵を用いてＭＡＣを生成し、ＭＡＣ付きの送信データを暗号化する。セキュリティ処理部１５は、暗号化送信データと、選択された通信鍵の鍵ＩＤを格納したパケット信号を生成する。当該パケット信号は、ＭＡＣフレーム処理部１４および変復調部１３を経て、ＲＦ部１２からアンテナ１１を介して外部に報知される。

別の端末装置１０のＲＦ部１２は、当該パケット信号をアンテナ１１を介して受信する。当該パケット信号は、変復調部１３およびＭＡＣフレーム処理部１４を経て、セキュリティ処理部１５に渡される。暗復号部１５６は、当該パケット信号に格納された鍵ＩＤにより特定される通信鍵を共通鍵テーブルから読み出し、当該パケット信号に格納された暗号化送信データを、当該通信鍵で復号し、ＭＡＣ検証する。ＭＡＣ検証が成功したら、暗号化送信データは平文の送信データに復元される。

このメッセージ送受信方法には以下に示す様々なメリットがある。まず、静的に通信鍵を使用するため、上述した路車間通信におけるメッセージ送受信方法より、データ通信量を抑えられる。また、複数の通信鍵を保持しておくことにより、通信路中から通信鍵が漏洩するリスクを小さくできる。また、共通鍵テーブルが漏洩した場合、新バージョンの通信鍵テーブルを追加することにより、セキュリティ低下を抑えられる。

図３０は、車車間通信において生成されるパケットに含まれるセキュリティフレームのデータ構造の一例を示す。当該セキュリティフレームのデータ構造では、ヘッダとして「バージョン」、「メッセージタイプ」、「鍵ＩＤ」および「ＮＯＮＣＥ」が配置され、その後に「ペイロード」が配置され、最後にフッタとして「ＭＡＣ」が配置される。この例では、「ペイロード」がＭＡＣ対象である。「鍵ＩＤ」により特定される共通鍵テーブル内の通信鍵により「ＭＡＣ」が生成され、当該通信鍵により「ペイロード」および「ＭＡＣ」が暗号化されて、秘匿される。

図３１は、共通鍵テーブルのフォーマットを示す。共通鍵テーブルの「ＦＩｅｌｄ」には、「Ｖｅｒｓｉｏｎ」、「Ｔａｂｌｅ ＩＤ」、「Ｎｕｍｂｅｒ ｏｆ ｋｅｙ」、「Ｔａｂｌｅ Ｍａｓｔｅｒ」および「Ｋｅｙ ｌｉｓｔ」が設けられる。「Ｋｅｙ ｌｉｓｔ」には「Ｋｅｙ ０」〜「Ｋｅｙ １５」が設けられる。なお、一つの共通鍵テーブルに含まれる鍵の数は１６に限るものではない。

「Ｖｅｒｓｉｏｎ」、「Ｔａｂｌｅ ＩＤ」および「Ｎｕｍｂｅｒ ｏｆ ｋｅｙ」は、１バイトの領域が定義される。「Ｔａｂｌｅ Ｍａｓｔｅｒ」、「Ｋｅｙ ０」〜「Ｋｅｙ １５」は、１６バイトの領域が定義される。

「Ｔａｂｌｅ ＩＤ」にはテーブルＩＤがセットされる。「Ｎｕｍｂｅｒ ｏｆ ｋｅｙ」にはテーブル内の鍵の数がセットされる。「Ｔａｂｌｅ Ｍａｓｔｅｒ」にはテーブル更新鍵がセットされる。「Ｋｅｙ ０」には鍵番号０のＡＥＳ鍵がセットされる。「Ｋｅｙ １」には鍵番号１のＡＥＳ鍵がセットされる。以下、「Ｋｅｙ １５」まで同様である。なお、ＡＥＳ以外の共通鍵を用いてもよい。また、共通鍵テーブルに含まれる鍵の数が、一定の場合「Ｎｕｍｂｅｒ ｏｆ ｋｅｙ」は省略してもよい。さらには、テーブル更新鍵は、事前に共有している鍵として「Ｔａｂｌｅ Ｍａｓｔｅｒ」を省略してもよい。

図３２は、共通鍵テーブルの運用方法の一例を示す。図３２では、端末装置１０が四つの共通鍵テーブルを格納可能な記憶領域を保持する例を描いている。もちろん、端末装置１０が保持する共通鍵テーブルの数は四つに限るものではない。初期状態（出荷時）には、端末装置１０には一つの共通鍵テーブル（バージョン＝１、テーブルＩＤ＝１）が保持される。送信側の端末装置１０はこの共通鍵テーブル（バージョン＝１、テーブルＩＤ＝１）から一つの通信鍵を選択して、ＭＡＣ生成および暗号化に使用する。

この共通鍵テーブル（バージョン＝１、テーブルＩＤ＝１）が漏洩した場合またはその可能性が発生した場合、新たな共通鍵テーブル（バージョン＝１、テーブルＩＤ＝２）が追加される。送信側の端末装置１０はこの最新の共通鍵テーブル（バージョン＝１、テーブルＩＤ＝２）から一つの通信鍵を選択して、ＭＡＣ生成および暗号化に使用する。同様の事象が発生した場合、共通鍵テーブル（バージョン＝１、テーブルＩＤ＝３）、共通鍵テーブル（バージョン＝１、テーブルＩＤ＝４）の順に新たな共通鍵テーブルが追加される。

四つの共通鍵テーブルが端末装置１０に保持された後、最後に追加された共通鍵テーブル（バージョン＝１、テーブルＩＤ＝４）が漏洩した場合またはその可能性が発生した場合、一番古い共通鍵テーブル（バージョン＝１、テーブルＩＤ＝１）に、新たな共通鍵テーブル（バージョン＝２、テーブルＩＤ＝１）が上書き（更新）される。以下、この処理が繰り返される。なお、図３２において太線で囲われた共通鍵テーブルは、送信に使用されるテーブルであり、正規認証対象のテーブルであることを示し、細線で囲われた共通鍵テーブルは、受信専用のテーブルであり、準認証対象のテーブルであることを示す。このように、共通鍵テーブルを運用することにより、互換性を保ち、矛盾のない運用を実現できる。

図３３は、共通鍵テーブルの追加または更新を説明するための図である。本実施例では、追加または更新される共通鍵テーブルは、システム運用管理機関のシステム運用管理装置３００により生成される。システム運用管理装置３００は、当該共通鍵テーブルをテーブル更新鍵で暗号化する。なお、当該共通鍵テーブルには当該テーブル更新鍵も格納される。さらに、不正な端末装置１０の情報もシステム運用管理装置３００に集められ、システム運用管理装置３００は上述した機器ネガリストも生成する。

システム運用管理装置３００は、路車間サービス提供者の路車間サービス提供者端末装置４００およびサービス工場のサービス工場端末装置４５０に、上述した、機器ネガリスト、暗号化共通鍵テーブルおよびテーブル更新鍵をそれぞれ提供する。路車間サービス提供者端末装置４００は、システム運用管理装置３００から受けつけた機器ネガリスト、暗号化共通鍵テーブルおよびテーブル更新鍵を基地局装置２０に提供する。サービス工場は、主に、自動車のメンテナンスを行う施設である。サービス工場のサービス工場端末装置４５０は、施設内に設置している小電力基地局装置４５１に、システム運用管理装置３００から受けつけた機器ネガリスト、暗号化共通鍵テーブルおよびテーブル更新鍵を提供する。

小電力基地局装置４５１は、リアルタイムの道路情報を端末装置１０に報知する路側機ではなく、特定の端末装置１０に共通鍵テーブルなどのシステム運用に関する情報を無線送信する専用機である。なお、サービス工場から端末装置１０に記録メディアを介して、システム運用に関する情報を提供してもよい。

路車間サービス提供者端末装置４００から機器ネガリスト、暗号化共通鍵テーブルおよびテーブル更新鍵を受けつけた基地局装置２０は、端末装置１０から機器ＩＤおよびテーブルＩＤを取得する。そして、その機器ＩＤおよびテーブルＩＤに、路車間サービス提供者端末装置４００から受け付けたテーブル更新鍵を付加し、それらを暗号化する。当該基地局装置２０は、暗号化した機器ＩＤ、テーブルＩＤおよびテーブル更新鍵を格納したパケット信号を報知する。また、当該基地局装置２０は、路車間サービス提供者端末装置４００から受けつけた暗号化共通鍵テーブルを報知する。なお、機器ネガリストに登録されている端末装置１０の機器ＩＤを受け付けた場合、これらの処理は実行されない。

小電力基地局装置４５１も、当該基地局装置２０と同様に、サービス工場端末装置４５０から受けつけた暗号化共通鍵テーブルと、テーブル更新鍵を端末装置１０に送信する。なお、小電力基地局装置４５１では、電波が届く範囲が制限されるため、当該テーブル更新鍵を暗号化して送信する必要性は小さく、当該テーブル更新鍵を暗号化せずに送信してもよい。

端末装置１０は、基地局装置２０または小電力基地局装置４５１から受信した暗号化共通鍵テーブルを、同様に受信したテーブル更新鍵で復号する。なお、基地局装置２０と端末装置１０間の暗号化共通鍵テーブルの追加または更新手順の詳細は後述する。図３３においても図２７と同様に、システム運用管理機関と路車間サービス提供者間、システム運用管理機関とサービス工場間、路車間サービス提供者と基地局装置２０間およびサービス工場と端末装置１０間の共通鍵テーブルおよびテーブル更新鍵の受け渡しは、通信システム５００以外のバックインフラを用いて行われる。

図３４は、実施例２に係る通信システム５００を用いた路車間通信における共通鍵テーブルの追加または更新手順を説明するための図である。図３４にて、基地局装置２０（路側機）が、追加または更新用の暗号化共通鍵テーブルおよびそのテーブル更新鍵、ならびに機器ネガリストを保持していることを前提とする。当該基地局装置２０は、端末装置１０（車載器Ｌ）から、その機器ＩＤ（Ｌ）およびテーブルＩＤ（ｋ）を格納したパケット信号を受信する。ここで、テーブルＩＤ（ｋ）は現在使用されている最新の共通鍵テーブルのテーブルＩＤを示す。

基地局装置２０の鍵更新部２５８は、受信したパケットに格納された機器ＩＤ（Ｌ）が機器ネガリストに登録されているか否かをチェックする。登録されている場合、以降の処理は実行されない。登録されていない場合、暗号部２５７は、端末装置１０から受信した機器ＩＤ（Ｌ）およびテーブルＩＤ（ｋ）に、テーブル更新鍵（ｍ）を連結して、現在使用中の最新の共通鍵テーブルのテーブル更新鍵（ｋ）で暗号化する。その暗号化データはパケット信号に格納される。当該パケット信号は、路車間通信として外部に報知される。それとともに、暗号化されたテーブル更新鍵（ｍ）に対応する暗号化された共通鍵テーブル（ｍ）もパケット信号に格納され、路車間通信により外部に報知される。

端末装置１０では、受信されたパケット信号から暗号化された機器ＩＤ（Ｌ）、テーブルＩＤ（ｋ）およびテーブル更新鍵（ｍ）が取り出され、復号部１５７はそれらをテーブル更新鍵（ｋ）で復号する。また、受信された別のパケット信号から暗号化共通鍵テーブル（ｍ）が取り出され、復号部１５７は暗号化共通鍵テーブル（ｍ）をテーブル更新鍵（ｍ）で復号する。鍵更新部１５８は、復号された共通鍵テーブル（ｍ）を、最新の共通鍵テーブルとしてテーブル格納領域に追加または更新する。なお、共通鍵テーブル（ｍ）にＭＡＣが付加されている場合、テーブル更新鍵（ｍ）でＭＡＣを検証し、成功したことを条件に追加または更新する。

このように、共通鍵テーブルはデータ量が多いため、その追加または更新には路車間通信だけでなく、専用基地局装置なども用いると効果的である。また、端末装置１０および基地局装置２０が現に保持するテーブル更新鍵を用いることにより、リスク分散を図ることができる。また、機器ネガリストを用いることにより、不正な端末装置への新たな共通鍵テーブルの提供を回避することができ、メッセージの漏洩リスクを低減できる。

以上説明したように実施例２によれば、共通鍵暗号化方式を用いた通信システムにおいて、路車間通信と車車間通信とで異なる運用方式を併用することにより、通信システム全体のセキュリティを効率的に向上させることができる。より具体的には、基地局装置から報知されるパケット信号を、端末装置から報知されるパケット信号よりセキュリティレベルの高い運用方式で暗号化する。前者のパケット信号は比較的データサイズに余裕があるが、後者のパケット信号は余裕が小さい。また、前者のパケット信号は後者のパケット信号より、高い信頼性が要求されるデータが含まれることが多い。

このように、路車間通信と車車間通信の両方に共通鍵暗号化方式を用いることにより、処理負荷を軽減することができ、リアルタイム性を確保しつつ、低コストな通信システムを構築できる。この通信システムにおいて、情報の発信主体により暗号化の運用方法を変えることにより、効率的なセキュリティシステムを構築できる。

また、路車間通信で使用する路車間マスタ鍵は１つとして説明したが、車車間通信で使用する通信鍵と同じように共通鍵テーブルを用いるようにしてもよい。この時、車車間の通信鍵と、路車間通信で使用する路車間マスタ鍵は異なった鍵を選択することが望ましい。また、共通鍵テーブルを指定するために、図２３の鍵ＩＤはオプションから必須となる。さらには、共通鍵テーブルを更新する毎にテーブル更新鍵を更新するとしたが、事前に共有したテーブル更新鍵の更新を行わないようにしてもよい。この場合、端末装置１０毎にユニークなテーブル更新鍵を保持するようにすれば、安全性は担保される。以上、実施例２を説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

上記図３２−図３４を参照しながら説明した共通鍵テーブルの運用方法は、基本的に共通鍵テーブルを端末装置１０に一つずつ提供するものであった。以下に説明する変形例では、複数の共通鍵テーブルを一度に端末装置１０に提供し、端末装置１０は提供された複数の共通鍵テーブルを保持する。そして、端末装置１０は保持している使用可能な共通鍵テーブルが無くなるまで、その複数の共通鍵テーブルを順次切り替えて使用する。そして、端末装置１０は保持している使用可能な共通鍵テーブルが無くなると、一つ以上の新たな共通鍵テーブルの提供を受けて、それを保持する。また、管理システム（図示されない。）からの要求により、一つ以上の新たな共通鍵テーブルの提供を受けて、それを保持する。

（実施例３）
図３５（ａ）−（ｂ）は、実施例３に係る、端末装置１０に保持された共通鍵テーブルを示す図である（その１）。図３６（ａ）−（ｂ）は、実施例３に係る、端末装置１０に保持された共通鍵テーブルを示す図である（その２）。実施例３では、路車間通信で使用する路車間マスタ鍵も、車車間通信で使用されている通信鍵と同様に共通鍵テーブルから選択されるものとする。以下、端末装置１０は八つの共通鍵テーブルを格納可能な記憶領域（以下、格納領域という）を有し、五つの共通鍵テーブルを保持する例を説明する。当該実施例３では、一つの共通鍵テーブルに保持される通信鍵の数は八つである。なお、端末装置１０に保持される共通鍵テーブルの数および一つの共通鍵テーブルに保持される通信鍵の数は複数であればよく、前述の数に限定されない。共通鍵テーブルの格納領域の数は、端末装置１０に保持される共通鍵テーブルの数以上であればよい。すなわち、テーブルＩＤにより識別する数と共通鍵テーブルの格納領域の数は一致している必要はなく、多くても少なくてもよい。また、上述のごとく車車間の通信鍵のみでなく、路車間マスタ鍵にも適用可能できる。

共通鍵テーブルの管理はバージョン及びテーブルＩＤにより行われる。バージョンの異なる同じテーブルＩＤで特定される共通鍵テーブルが同時に使用されることはない。必ず、バージョンが大きい方が使用される。テーブルＩＤはＮ（Ｎは自然数）の剰余系として設定される。本実施例３ではＮ＝８である。たとえば、１番目の共通鍵テーブルと９番目の共通鍵テーブルのテーブルＩＤは０となる。バージョンは同じテーブルＩＤの新しい共通鍵テーブルが生成される度にカウントアップしていく。したがって、前者では０、後者では１となる。

格納領域に保持される複数の共通鍵テーブルのうち、一つが送信用の共通鍵テーブル（以下、送信用鍵テーブルという）に指定され、複数が受信用の共通鍵テーブル（以下、受信用鍵テーブルという）に指定される。複数の受信用鍵テーブルは送信用鍵テーブルを含み、送信用鍵テーブルよりｎ（ｎは自然数、ｎ＜Ｎ）世代未来までの共通鍵テーブルを含む。なお、複数の受信用鍵テーブルはｍ（ｍは０または自然数、ｍ＋ｎ＜Ｎ）世代過去までの共通鍵テーブルを含んでもよい。i世代未来の共通鍵テーブルのテーブルＩＤは、｛（送信用鍵テーブルのテーブルＩＤ＋i） ｍｏｄ Ｎ｝で、ｊ世代前の共通鍵テーブルのテーブルＩＤは、｛（送信用鍵テーブルのテーブルＩＤ−ｊ） ｍｏｄ Ｎ｝で算出される。なお、i世代未来の共通鍵テーブルのバージョンは、少なくとも、テーブルＩＤが送信用鍵テーブルのテーブルＩＤより大きい場合、送信用鍵テーブルのバージョン以上、テーブルＩＤが送信用鍵テーブルのテーブルＩＤより小さい場合、送信用鍵テーブルのバージョンを越える値である必要がある。また、ｊ世代過去の共通鍵テーブルのバージョンは、少なくとも、テーブルＩＤが送信用鍵テーブルのテーブルＩＤより大きい場合、送信用鍵テーブルのバージョン未満、テーブルＩＤが送信用鍵テーブルのテーブルＩＤより小さい場合、送信用鍵テーブルのバージョン以下である必要がある。なお、格納領域に保持される同じテーブルＩＤの共通鍵テーブルが複数保持されている場合には、バージョンの値が小さいもの（古いもの）は、無効（保持していない）として扱う。

システム運用管理装置３００が送信用鍵テーブルの切替を指示しても、全ての端末装置１０において送信用鍵テーブルが同時に切り替わるわけではない。端末装置１０間において送信用鍵テーブルが切り替わるタイミングに時間差が生じる。たとえば、長期間使用されていない車両１００に搭載された端末装置１０では、二つ以上過去の共通鍵テーブルが送信用鍵テーブルに設定されている可能性もある。この車両１００が使用されると別の車両１００に搭載された端末装置１０は、二世代過去の共通鍵テーブルで処理されたパケット信号を受信する。暗号化システムの運用上、受信用鍵テーブルの範囲が狭いほどセキュリティが高くなるが、正当な端末装置１０からの送信データを復号できないケースが多くなる。両者の要請を考慮して受信用鍵テーブルの範囲は設定される。

送信用鍵テーブルの切替周期が長い場合（たとえば、数年）、受信用鍵テーブルは、送信用鍵テーブルと次の共通鍵テーブル（ｎ＝１）で構成されるとよい。また、送信用鍵テーブルの切替周期が短い場合（たとえば、一年以内）、受信用鍵テーブルは、送信用鍵テーブルと、次の共通鍵テーブル（ｎ＝１）と、さらにそれ以降の共通鍵テーブル（ｎ＞１）とで構成されるとよい。切替期間が短いほどｎを大きくし、多くの共通鍵テーブルを受信用鍵テーブルに組み入れるとよい。切替期間が短い場合、複数の端末装置１０間で送信用鍵テーブルのばらつきが大きくなる。これに対し、受信用鍵テーブルに組み入れる共通鍵テーブルの数を増やすことにより、送信用鍵テーブルのミスマッチを減らすことができる。また、ｍは１または０が適当である。

図３５（ａ）は、車車間通信における共通鍵テーブルを用いた暗号化サービスの運用開始〜１年目に出荷される端末装置１０が保持する共通鍵テーブルを示す。図３５（ｂ）は、２〜３年目に出荷される端末装置１０が保持する共通鍵テーブルを示す。図３６（ａ）は、１０〜１１年目に出荷される端末装置１０が保持する共通鍵テーブルを示す。図３６（ｂ）は、１２〜１３年目に出荷される端末装置１０が保持する共通鍵テーブルを示す。

運用開始〜１年目は共通鍵テーブル（バージョン＝０、テーブルＩＤ＝０）が送信用鍵テーブルとして使用される。各端末装置１０は、共通鍵テーブル（バージョン＝０、テーブルＩＤ＝０）から一つの通信鍵を選択して車車間通信に使用する。２〜３年目は共通鍵テーブル（バージョン＝０、テーブルＩＤ＝１）が送信用鍵テーブルとして使用される。４〜５年目は共通鍵テーブル（バージョン＝０、テーブルＩＤ＝２）が送信用鍵テーブルとして使用される。このように本実施例３では２年ごとに送信用鍵テーブルを順次切り替える運用を行う。この共通鍵テーブルの切替はシステム運用管理装置３００により統一的に管理される。

各端末装置１０は出荷時に五つの共通鍵テーブルを保持するため、基本的に出荷から８〜１０年間、各端末装置１０は共通鍵テーブルを追加更新せずに暗号化システムを使用できる。ただし、出荷から８〜１０年目以降もこの暗号化システムを使用するためには、８〜１０年経過前に新たな共通鍵テーブルを追加更新する必要がある。すなわち、使用可能な共通鍵テーブルが無くなる前に、新たな共通鍵テーブルを追加更新する必要がある。

図３７（ａ）−（ｂ）は、実施例３に係る共通鍵テーブルの切替の様子を示す図である（その１）。図３５（ａ）に従って、出荷される端末装置１０における共通鍵テーブルの切替の様子である。図３８（ａ）−（ｂ）は、実施例３に係る共通鍵テーブルの切替の様子を示す図である（その２）。図３６（ｃ）に従って、出荷される端末装置１０における共通鍵テーブルの切替の様子である。図３７（ａ）では共通鍵テーブル（バージョン＝０、テーブルＩＤ＝０）が送信用鍵テーブルに指定されている。この状態で送信用鍵テーブルの切替が指示されると、鍵更新部１５８は、図３７（ｂ）に示すように送信用鍵テーブルを共通鍵テーブル（バージョン＝０、テーブルＩＤ＝１）に切り替える。図３８（ａ）では共通鍵テーブル（バージョン＝０、テーブルＩＤ＝７）が送信用鍵テーブルに指定されている。この状態で送信用鍵テーブルの切替が指示されると、鍵更新部１５８は、図３８（ｂ）に示すように送信用鍵テーブルを共通鍵テーブル（バージョン＝１、テーブルＩＤ＝０）に切り替える。

このように、送信用鍵テーブルの切替が指示されると、鍵更新部１５８は、テーブルＩＤがＮ（本実施例３では８）の剰余系において次の値に切り替える。ただし、切替後の共通鍵テーブルのバージョンが同じ、または＋１である必要がある。図３７（ａ）−（ｂ）に示す例では切替前後でバージョンが同じである。図３８（ａ）−（ｂ）に示す例では切替前後でバージョンが＋１されている。複数のバージョンの共通鍵テーブルが格納領域に併存する場合、実装上、送信用鍵テーブルのバージョンより古いバージョンの共通鍵テーブルは存在しないものとして扱えばよい。なお、図３７（ａ）−（ｂ）の切替後、さらに３回の切替が行われると、送信用鍵テーブルが共通鍵テーブル（バージョン＝０、テーブルＩＤ＝４）に切り替わることになる。このとき、格納領域には次世代未来の共通鍵テーブルが保持されていなくなるので、新たに数世代未来の共通鍵テーブルを追記することで、図３５（ａ）に従って、出荷される端末装置１０の共通鍵テーブルの更新を行うことができる。なお余裕をみて、送信用鍵テーブルが共通鍵テーブル（バージョン＝０、テーブルＩＤ＝３）または（バージョン＝０、テーブルＩＤ＝４）のいずれかのときに更新するものとしてもよい。実施例３では、実施例２における共通鍵テーブルの更新による更新周期が長いこと（実施例３では実施例２の５倍）、端末装置１０によって更新のタイミングが異なり、更新に時間的余裕があることから、路車間通信を使用しない、メンテナンスによる共通鍵テーブルの更新が行えるので、路車間通信のトラフィックを削かない運用ができるといった利点がある。

図３９（ａ）−（ｂ）は、実施例３に係る共通鍵テーブルの緊急更新の様子を示す図である。図４０（ａ）−（ｂ）は、実施例３に係る共通鍵テーブルの緊急更新後の切替の様子を示す図である。図３５（ａ）に従って、出荷される端末装置１０における共通鍵テーブルの緊急更新および緊急更新後の切替の様子である。緊急時（たとえば、共通鍵テーブルの漏洩発生時）には、通常の切替期間に関係なく、鍵更新部１５８は、その時点における送信用鍵テーブルより世代的に未来の共通鍵テーブルを保持する場合、それらを更新する。また、鍵更新部１５８は、更新した共通鍵テーブルより世代的に未来の新たな共通鍵テーブルを追加する。更新または追加される共通鍵テーブルは、システム運用管理装置３００から提供される。更新または追加される共通鍵テーブルのバージョンは、送信用鍵テーブルのバージョンに＋１されている。なお、テーブルＩＤがＮの剰余系であることから明らかなように、世代的に未来の共通鍵テーブルのバージョンは、世代的に未来の共通鍵テーブルのテーブルＩＤが送信用鍵テーブルのテーブルＩＤより一つ小さいとき、送信用鍵テーブルのバージョンに＋２されることになる。

図３９（ａ）は共通鍵テーブル（バージョン＝０、テーブルＩＤ＝２）が送信用鍵テーブルであるときに漏洩が発生した場合の例を示している。この漏洩に対して緊急更新が実行される。図３９（ｂ）は緊急更新後の格納領域の状態を示す。図３９（ｂ）に示す例では鍵更新部１５８は、送信用鍵テーブルの次の共通鍵テーブル（バージョン＝０、テーブルＩＤ＝３）を共通鍵テーブル（バージョン＝１、テーブルＩＤ＝３）に書き換え、その次の共通鍵テーブル（バージョン＝０、テーブルＩＤ＝４）を共通鍵テーブル（バージョン＝１、テーブルＩＤ＝４）に書き換える。さらに、共通鍵テーブル（バージョン＝１、テーブルＩＤ＝５）及び共通鍵テーブル（バージョン＝１、テーブルＩＤ＝６）を追加する。すなわち、送信用鍵テーブルより世代的に未来に、四つの新たな共通鍵テーブルが格納されることになる。図３９（ｂ）ではこの四つの共通鍵テーブルを太線で描いている。

図４０（ａ）は図３９（ｂ）と同じ図である。図４０（ｂ）は四つの新たな共通鍵テーブルが更新追加された後、送信用鍵テーブルの切替指示に応じて、送信用鍵テーブルが共通鍵テーブル（バージョン＝０、テーブルＩＤ＝２）から共通鍵テーブル（バージョン＝１、テーブルＩＤ＝３）に切り替わる様子を描いている。

図４１は、実施例３に係る送信用鍵テーブルの第１切替例を示す図である。第１切替例は、受信用鍵テーブルに送信用鍵テーブルとそれより過去および未来の共通鍵テーブルが組み入れられる場合に適用される。以下の説明では、過去および未来の共通鍵テーブルがそれぞれ一つ組み入れられる場合を想定する。すなわち、受信鍵テーブルが三つ存在する場合を想定する。なお、未来の共通鍵テーブルについては複数、組み入れられてもよい。

通常時、鍵更新部１５８は通常切替期間（本実施例３では２年）ごとに送信用鍵テーブルを切り替える。緊急事態発生時、鍵更新部１５８は現在の送信用鍵テーブルを維持しつつ、それより世代的に未来の共通鍵テーブルをシステム運用管理装置３００から提供される新たな共通鍵テーブルに更新する。この更新を本明細書では緊急更新という。この更新期間は、通常切替期間の切替残期間に関係なく、送信用鍵テーブルの更新に必要な期間を確保できるように設定される。たとえば、全ての端末装置１０の８割の端末装置１０が更新完了する期間に設定されてもよい。残りの端末装置１０はリコール品として個別に更新する。

第１切替例では、緊急更新時、鍵更新部１５８は過去の共通鍵テーブルを無効化する。システム運用管理装置３００は、過去の共通鍵テーブルの削除指令を発行するか、端末装置１０に格納される全ての共通鍵テーブルを書き換えるための新たな共通鍵テーブルを提供する。後者の場合、鍵更新部１５８は格納される全ての共通鍵テーブルを新たな共通鍵テーブルに上書きする。

緊急更新期間終了後の、送信用鍵テーブルの最初の切替期間（以下、緊急切替期間という）は、通常切替期間より短く設定される。すなわち、緊急更新期間終了後に使用する最初の送信用鍵テーブルの利用期間は、通常の利用期間より短く設定される。第１切替例では、送信用鍵テーブルより一単位過去の共通鍵テーブルも受信用鍵テーブルに含まれる。したがって、緊急切替期間では緊急事態発生時に送信用鍵テーブルであった共通鍵テーブルを用いて暗号されたデータの受信を許容することになる。この共通鍵テーブルは漏洩または漏洩の可能性があるため、できるだけその受信を許容する期間を短くすることが好ましい。そこで、第１切替例では緊急切替期間が通常切替期間より短く設定される。緊急切替期間後の切替期間では漏洩または漏洩の可能性がある共通鍵テーブルを用いて暗号されたデータの受信を許容しないため、緊急切替期間後の切替期間は通常切替期間となる。

図４２は、実施例３に係る送信用鍵テーブルの第２切替例を示す図である。第２切替例は、受信用鍵テーブルに送信用鍵テーブルとそれより未来の共通鍵テーブルが組み入れられる場合に適用される。

通常時、鍵更新部１５８は通常切替期間ごとに送信用鍵テーブルを切り替える。緊急事態発生時、鍵更新部１５８は現在の送信用鍵テーブルを維持しつつ、それより世代的に未来の共通鍵テーブルを緊急更新する。第２切替例では、第１切替例のように緊急切替期間は設定されない。第２切替例では、送信用鍵テーブルより過去の共通鍵テーブルが受信用鍵テーブルに含まれないため、漏洩または漏洩の可能性がある共通鍵テーブルを用いて暗号化されたデータの受信を許容しない。したがって、緊急更新期間後の最初の切替期間を通常切替期間より短くする必要がない。

図４３は、実施例３に係る共通鍵テーブルの追加または更新を説明するための図である。システム運用管理機関のシステム運用管理装置３００は、複数の共通鍵テーブルを生成し、車両メーカの共通鍵テーブル設定装置４６０に提供する。共通鍵テーブル設定装置４６０は、提供された複数の共通鍵テーブルを、車両１００に新規に搭載された端末装置１０に書き込む。この書き込む複数の共通鍵テーブルの種類は出荷時期により異なる。

システム運用管理装置３００は、送信用鍵テーブルの切替タイミングが到来すると、路車間サービス提供者端末装置４００にテーブル切替指示を発行する。路車間サービス提供者端末装置４００は、システム運用管理装置３００から受け付けたテーブル切替指示を基地局装置２０に伝達する。基地局装置２０は、路車間サービス提供者端末装置４００から受け付けたテーブル切替指示を路車間通信でブロードキャスト送信する。車両１００に既に搭載された端末装置１０は、そのテーブル切替指示を受け付けると、送信用鍵テーブルを切り替える。また、端末装置１０は、受け付けたテーブル切替指示を車車間通信でブロードキャスト送信する。別の端末装置１０は、テーブル切替指示を受け付けると、送信用鍵テーブルを切り替える。システム運用管理装置３００からのテーブル切替指示は、共通鍵テーブル設定装置４６０および新規の端末装置１０を介して既存の端末装置１０に伝達されてもよい。

なお、送信用鍵テーブルの切替タイミングは端末装置１０が判断して切り替えていくようにしてもよい。ここでは、路車間通信で使用するマスタ鍵も、車車間通信で使用されている通信鍵と同様に共通鍵テーブルから選択されるものとする。また、図２３における鍵ＩＤは、路車間通信でも使用する。なお、予め車車間通信で使用されている通信鍵とマスタ鍵の範囲を分けておいてもよい。この場合、双方の共通鍵テーブルに帰属する鍵の数が同じである必要はなく、鍵寿命の観点から、通信鍵より路車間マスタ鍵は少なくてもよい。

システム運用管理装置３００は、送信用鍵テーブルの切替タイミングが到来すると、路車間サービス提供者端末装置４００にテーブル切替指示を発行する。路車間サービス提供者端末装置４００は、システム運用管理装置３００からテーブル切替指示を受け取ると、基地局装置２０に送信用鍵テーブルのテーブル切替指示を発行する。基地局装置２０は、テーブル切替指示を受け取ると、自身の使用する送信用鍵テーブルを切り替える。そして、切り替えた共通鍵テーブルよりマスタ鍵を選択して、メッセージ形式が認証付き暗号化データまたは認証付きデータのセキュリティフレームを含むパケット信号を報知する。

車両１００に既に搭載された端末装置１０は、そのパケット信号を受信すると受信処理を行う。セキュリティ処理部１５は、受信したパケット信号に含まれるセキュリティフレームのＭＡＣを検証する。検証に成功すると、受信したセキュリティフレームの鍵ＩＤからテーブルＩＤを取り出して、自身の送信用鍵テーブルのテーブルＩＤと比較する。自身の送信用鍵テーブルより未来の世代の共通鍵テーブルを用いている場合、送信用鍵テーブルをそれに切り替える。また、他の端末装置１０から車車間通信で受信したパケット信号に基づいて切り替えるようにしても良い。

車両１００に既に搭載された端末装置１０は、前述のパケット信号を受信すると受信処理を行う。セキュリティ処理部１５は、受信したパケット信号に含まれるセキュリティフレームのＭＡＣを検証する。検証に成功すると、受信したセキュリティフレームの鍵ＩＤからテーブルＩＤを取り出して、自身の送信用鍵テーブルより未来の世代の共通鍵テーブルを用いている場合、そのテーブルＩＤと送信元の機器ＩＤを保持する。そして、例えば、１０台の他の端末装置１０から、未来の世代の同じ共通鍵テーブルを用いていると判断された場合、送信用鍵デーブルをそれに切り替える。両者の切り替え判断は併用できる。新規の端末装置１０の送信用鍵テーブルは、事前に切り替えて提供されるので、基地局装置２０が無い場所であっても、切替を伝搬させることができる。すなわち、基地局装置２０が無い場所を移動する車両であっても、切替後の他の端末装置１０からのパケット信号を受信することによって切り替わる。なお、ＭＡＣ検証は、発信元の真正性が確認できない点に鑑み、異なる複数（例えば１０台）の基地局装置２０または他の端末装置１０から受信したパケット信号の検証の成功に基づいて、送信用鍵デーブルを切り替えるようにする。また、実施例１およびその変形例１〜変形例６のごとく、路車間通信のパケット信号に電子署名がついている場合、電子署名は発信元の真正性が確認できることに鑑みて、受信したパケット信号に対する電子署名の検証成功時と、ＭＡＣの検証成功時の切替の判断基準を変えてもよい。例えば、基地局装置２０から受信したパケット信号に含まれるセキュリティフレームの電子署名の検証に成功したとき、あるいは、複数台（例えば１０台）の他の端末装置１０から受信したパケット信号に含まれるセキュリティフレームのＭＡＣの検証に成功したときとなる。

また、緊急事態発生時、システム運用管理装置３００は新しい共通鍵テーブルを、路車間サービス提供者端末装置４００および基地局装置２０を介して既存の端末装置１０に伝達するとともに、共通鍵テーブル設定装置４６０および新規の端末装置１０を介して既存の端末装置１０に伝達する。共通鍵テーブルを更新する際、図３２−図３３に示した手法を用いることができる。

なお、共通鍵テーブルの更新は次のように行われてもよい。まず、端末装置１０は自己の機器ＩＤを含む更新要求信号をシステム運用管理装置３００に送信する。システム運用管理装置３００は、各機器ＩＤに対応する公開鍵で新たな共通鍵テーブルを暗号化し、端末装置１０に送信する。両者の通信は、路車間サービス提供者端末装置４００および基地局装置２０を介して実行されてもよいし、その他のネットワークを介して実行されてもよい。端末装置１０は、暗号化された共通鍵テーブルを受信すると、ユニークな秘密鍵で復号する。

また、各機器ＩＤに対応する公開鍵にかえて各機器ＩＤに対応する共通鍵を使用しても良い。システム運用管理装置３００は、各機器ＩＤを受け取って、その機器ＩＤに対応する共通鍵を使用して新たな共通鍵テーブルを暗号化し、端末装置１０に送信する。このとき、端末装置１０とシステム運用管理装置３００間の通信路については特に限定を加えない。

以上説明したように本実施例３によれば、複数の共通鍵テーブルを一度に端末装置１０に提供し、テーブル切替指示に応じて切り替えて使用することにより、共通鍵テーブルの更新追加回数を削減できる。したがって、漏洩のリスクを低減できる。なお、漏洩が発生した場合、共通鍵テーブルを緊急更新することにより、セキュリティを確保できる。

１０ 端末装置、 １１ アンテナ、 １２ ＲＦ部、 １３ 変復調部、 １４ ＭＡＣフレーム処理部、 １５ セキュリティ処理部、 １５１ 検証部、 １５１ａ 証明書検証部、 １５１ｂ メッセージ検証部、 １５１ｃ ダイジェスト保持部、 １５１ｄ 認証鍵保持部、 １５１ｅ ステータス管理部、 １５２ 復号部、 １６１ 受信処理部、 １６２ 通知部、 １７ データ生成部、 １８ 記憶部、 １９ 制御部、 ２０ 基地局装置、 ２１ アンテナ、 ２２ ＲＦ部、 ２３ 変復調部、 ２４ ＭＡＣフレーム処理部、 ２５ セキュリティ処理部、 ２６ データ生成部、 ２５１ 署名部、 ２５２ 暗号部、 ２７ ネットワーク通信部、 ２８ 記憶部、 ２９ 制御部、 １００ 車両、 ２０２ エリア、 ２０４ エリア外、 ５００ 通信システム、 １５６ 暗復号部、 １５７ 復号部、 １５８ 鍵更新部、 ２５６ 暗復号部、 ２５７ 暗号部、 ２５８ 鍵更新部、 ２７ ネットワーク通信部、 ２８ 記憶部、 ２９ 制御部、 ３００ システム運用管理装置、 ４００ 路車間サービス提供者端末装置、 ４５０ サービス工場端末装置、 ４５１ 小電力基地局装置。

本発明に係る端末装置はＩＴＳに利用可能である。

Claims (3)

1. 路側機からパケット信号を報知する路車間通信、および車載器からパケット信号を報知する車車間通信を用いる通信システム内における車載器に用いられる処理装置であって、
   共通鍵暗号方式により暗号化されたパケット信号が入力される入力部と、
   前記入力部に入力されたケット信号から取り出されたデータを復号する処理部と、
   を備え、
   前記路側機から報知されるパケット信号から取り出されたデータは、パケット送信のたびに生成される通信鍵により暗号化されており、
   他の車載器から報知されるパケット信号から取り出されたデータは、車載器間で共有されている、複数の通信鍵を含む鍵テーブル内のいずれかの通信鍵により暗号化されており、
   前記路側機と本車載器間でマスタ鍵が共有され、
   前記路側機から報知されるパケット信号には、前記マスタ鍵により暗号化された通信鍵が含まれ、
   前記他の車載器から報知されるパケット信号には、前記鍵テーブル内から選択された通信鍵の識別情報が含まれていることを特徴とする処理装置。
2. 前記路側機から報知されるパケット信号に含まれるメッセージに、公開鍵暗号方式により暗号化された電子署名が付加されていることを特徴とする請求項１に記載の処理装置。
3. 前記処理部は、共通鍵暗号方式により暗号化したデータを出力する出力部をさらに備え、
   前記出力部は、前記鍵テーブル内から選択された通信鍵によりデータを暗号化して出力するとともに、当該通信鍵の識別情報を出力することを特徴とする請求項１または２に記載の処理装置。