JP6335570B2 - 無線装置 - Google Patents

Description

本発明は、通信技術に関し、セキュリティ処理がなされたパケット信号を受信する無線装置に関する。

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

特開２００７−１０４３１０号公報

ブロードキャストによる情報伝達において、電子署名によるメッセージ検証は、発信元の特定ができるが処理が重く、回路規模が増大する。回路規模の増大はコストアップ要因となる。また処理遅延によって適切なタイミングで情報を得ることができない場合が発生し、サービスに支障をきたす場合がある。ＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）によるメッセージ検証は、処理は軽いが発信元の特定ができない。

本発明はこうした状況に鑑みてなされたものであり、その目的は、軽負荷で発信元の特定ができるメッセージ検証技術を提供することにある。

上記課題を解決するために、本発明のある態様の無線装置は、発信元固有の公開鍵証明書、代表値リスト、アプリケーションデータ、公開鍵証明書に含まれる公開鍵で検証可能な署名、共通鍵暗号方式によるメッセージ認証コードが付加された第１パケット信号、及び発信元固有の公開鍵証明書のダイジェスト、アプリケーションデータ、共通鍵暗号方式によるメッセージ認証コードが付加された第２パケット信号を、他の無線装置から受信する受信部と、第１パケット信号に含まれる公開鍵証明書の署名および第１パケット信号に含まれる代表値リストを少なくとも含むデータ列から生成された署名を検証するための第１検証部と、第１パケット信号または第２パケット信号に含まれるメッセージ認証コードを検証するための第２検証部と、第２パケット信号に含まれるアプリケーションデータを少なくとも含むデータ列から演算された代表値と、代表値リスト内に含まれている、第２パケット信号に含まれるアプリケーションデータを少なくとも含む予め演算されたデータ列の代表値とを比較する比較部と、第１検証部による署名の検証結果、第２検証部によるメッセージ認証コードの検証結果、比較部による比較結果をもとに、アプリケーションデータを構成するメッセージを承認するか否か判定する判定部と、を備える。

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

本発明によれば、軽負荷で発信元の特定ができるメッセージ検証を実現できる。

本発明の実施例に係る通信システムの構成を示す図である。 図２（ａ）−（ｄ）は、通信システムにおいて規定されるスーパーフレームのフォーマットを示す図である。 図３（ａ）−（ｂ）は、サブフレームの構成を示す図である。 図４（ａ）−（ｄ）は、通信システムにおいて規定される各レイヤのフレームのフォーマットを示す図である。 図５（ａ）−（ｂ）は、セキュリティメッセージのデータ構造の一例を示す図である。 セキュリティメッセージのデータ構造の別の一例を示す図である。 基地局装置の構成を示す図である。 車両に搭載された端末装置の構成を示す図である。 実施例に係る通信システムを用いた車車間通信における通常のメッセージ送受信手順を説明するための図である。 メッセージ形式のデータ構造の一例を示す図である。 検証部の構成例を示す図である。 実施例に係る端末装置でのメッセージ検証処理の一例を示すフローチャートである。 図１２のＭＡＣ検証のサブルーチンを示すフローチャートである。 図１２の署名検証のサブルーチンを示すフローチャートである。 図１２のハッシュ一致検証のサブルーチンを示すフローチャートである。 実施例に係る端末装置でのメッセージ検証処理の別の例を示すフローチャートである。 図１６のＭＡＣ検証のサブルーチンを示すフローチャートである。 図１６の署名検証のサブルーチンを示すフローチャートである。 図１６のハッシュ一致検証のサブルーチンを示すフローチャートである。 図２０（ａ）−（ｂ）は、セキュリティメッセージのデータ構造のさらに別の一例を示す図である。 図１２の署名検証の別のサブルーチンを示すフローチャートである。 図２２（ａ）−（ｂ）は、実施例に係る基地局装置、端末装置において規定されるレイヤの構成例を示す図である。 図２３（ａ）−（ｅ）は、図２２（ａ）−（ｂ）の各レイヤにおける処理の概要を示す図である。 図２４（ａ）−（ｂ）は、実施例に係る基地局装置、端末装置において規定されるレイヤの別の構成例を示す図である。 図２５（ａ）−（ｆ）は、図２４（ａ）−（ｂ）の各レイヤにおける処理の概要を示す図である。 図２６（ａ）−（ｆ）は、図２４（ａ）−（ｂ）の各レイヤにおける別の処理の概要を示す図である。 汎用サービスと特定サービスが併用される通信システムにおけるデータ構造の一例を示す図である。 図２７の「鍵情報」のデータ構造の一例を示す図である。 汎用サービスと特定サービスが混在した通信システムの一例を示す図である。 図３０（ａ）−（ｄ）は、路側機における送信処理の各レイヤにおける処理の概要を示す（その１）。 図３１（ａ）−（ｃ）は、路側機における受信処理の各レイヤにおける処理の概要を示す。 図３２（ａ）−（ｃ）は、汎用車載機における受信処理の各レイヤにおける処理の概要を示す。 図３３（ａ）−（ｄ）は、路側機における送信処理の各レイヤにおける処理の概要を示す（その２）。 図２７のメッセージを路車間メッセージとして、図６のメッセージを車車間メッセージとして受信するときの、検証部における処理を示すフローチャートである。 図３４の署名検証のサブルーチンを示すフローチャートである。 図３４の署名検証対象の判定方法の一例を示すフローチャートである。 図３４の署名検証対象の判定方法の別の例を示すフローチャートである。

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

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

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

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

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

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

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

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

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

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

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

図４（ｄ）は、車車間・路車間共用通信制御情報レイヤのフレームフォーマットを示す。このフレームは、図４（ｃ）のＬＳＤＵに格納される。図示のごとく、フレームには、ＩＲヘッダ、ＡＰＤＵ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）が順に配置される。ＡＰＤＵには、後述するセキュリティメッセージあるいは、通信規約に基づいて送信可能なサイズに分割されたセキュリティメッセージの部分が配置される。

図５（ａ）−（ｂ）は、セキュリティメッセージのデータ構造の一例を示す。これは、基地局装置２０から報知される路車間通信のパケット信号に含まれるセキュリティメッセージに相当する。セキュリティメッセージのデータサイズによって、１つのセキュリティメッセージを分割して、連続する複数の路車間通信のパケット信号に配置して送信する場合もあり得るが、以降では説明を簡単にするために路車間通信の１つのパケット信号、即ち、図３（ｂ）に示されたＲＳＵパケットに１つのセキュリティメッセージが配置されるものとする。図５（ａ）は、図３（ｂ）に示された複数のＲＳＵパケットのうちの、先頭のＲＳＵパケットに配置されるセキュリティメッセージであり、図５（ｂ）は、２番目以降のＲＳＵパケットに配置されるセキュリティメッセージである。図５（ａ）のデータ構造では、「バージョン・メッセージタイプ」、「ＭＡＣ方式ヘッダ」に続いて、「ＭＡＣ方式ペイロード」が配置され、最後に「ＭＡＣ方式フッタ」が配置される。また、「ＭＡＣ方式ヘッダ」には、「鍵ＩＤ」、「Ｎｏｎｃｅ」、「ペイロード長」が含まれ、「ＭＡＣ方式ペイロード」には、「公開鍵証明書」、「後続パケットの認証用ハッシュリスト」、「アプリケーション」、「電子署名」が含まれる。「ＭＡＣ方式フッタ」には、「ＭＡＣ」が含まれる。「Ｎｏｎｃｅ」には、「機器ＩＤ」と「乱数」が含まれる。

「バージョン・メッセージタイプ」のバージョンには、フレームフォーマットのバージョンがセットされる。「バージョン・メッセージタイプ」のメッセージタイプには、データ認証方式を規定する認証タイプ（ＡＴ）と、「ペイロード」に対する保護の形式を指定するメッセージタイプ（ＭＴ）のふたつがセットされる。「鍵ＩＤ」には、鍵を識別するための識別情報がセットされる。「Ｎｏｎｃｅ」には、暗号化処理（暗号化あるいはＭＡＣ生成）において結果を攪乱するために用いる通信毎にユニークな値がセットされる。ここでは「乱数」と「機器ＩＤ」がセットされる。「機器ＩＤ」には、パケット信号の発信元である端末装置１０あるいは基地局装置２０に対して割り当てられた機器ＩＤをセットされる。ここで、機器ＩＤは、端末装置１０あるいは基地局装置２０に対してユニークに付与された識別番号である。

「乱数」には、パケット信号の送信時に送信元が発生させた乱数がセットされる。すなわち、パケット信号の発信毎にユニークな値がセットされる。ここでは、「乱数」としているが、乱数に代えてメッセージの生成日時あるいは発信日時を示す「日時情報」にしてもよい。この場合、日時情報はパケット信号の発信毎にユニークである必要があるため、スーパーフレームの周期よりも細かい分解能が要求される。但し、精度は要求されない。「ペイロード長」には、「ペイロード」のバイト数がセットされる。

「公開鍵証明書」には、送信元の基地局装置２０に固有の公開鍵に対する公開鍵証明書がセットされる。公開鍵証明書は公開鍵とその公開鍵の所有主体を結びつける証明書である。公開鍵証明書には、署名者の識別情報、公開鍵証明書の識別情報（機器ＩＤであってもよい）、有効期限、公開鍵（鍵生成アルゴリズム、サイズなどを含む）、署名者の署名などが含まれる。本実施例では、署名者は認証局（ＣＡ：Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）とする。当該署名は、例えば、ＲＳＡ、ＤＳＡ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）、ＥＣＤＳＡ（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ−ＤＳＡ）などの公開鍵暗号方式により生成される。本実施例では、ＥＣＤＳＡを採用する。「後続パケットの認証用ハッシュリスト」には、後続のセキュリティメッセージ、より詳細には後続のセキュリティメッセージの「アプリケーション」に対するハッシュ値のリストがセットされる。「アプリケーション」には、路車間アプリケーションデータがセットされる。

「電子署名」には、「後続パケットの認証用ハッシュリスト」、「アプリケーションデータ」に対する署名がセットされる。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。さらに、署名をセットした後、ＭＡＣ値が導出されて「ＭＡＣ」にセットされる。この例では、ＭＡＣの演算対象は「ＭＡＣ方式ヘッダ」の「Ｎｏｎｃｅ」と「ペイロード長」と「ＭＡＣ方式ペイロード」であり、暗号化の対象は「ＭＡＣ方式ペイロード」と「ＭＡＣ方式フッタ」である。

図５（ｂ）のデータ構造では、「バージョン・メッセージタイプ」、「ＭＡＣ方式ヘッダ」に続いて、「ＭＡＣ方式ペイロード」が配置され、最後に「ＭＡＣ方式フッタ」が配置される。「ＭＡＣ方式ヘッダ」と「ＭＡＣ方式フッタ」の構造は、図５（ａ）と同一なので説明を省略する。また、「ＭＡＣ方式ペイロード」には、「証明書ダイジェスト」、「アプリケーションデータ」が含まれる。「証明書ダイジェスト」は、送信元の基地局装置２０に固有の公開鍵に対する公開鍵証明書のダイジェストがセットされる。ここではダイジェストとして公開鍵証明書のボディ、すなわち、公開鍵証明書の署名の対象部に対するハッシュ値、例えば、ＳＨＡ−２２４、ＳＨＡ−２２５によって求められた値、あるいはその一部を当てるとする。なお、公開鍵証明書に含まれる署名、署名の一部、公開鍵、証明書の識別情報（例えば、シリアル番号）、または／かつ機器ＩＤをダイジェストとして代用してもよい。さらに、ダイジェストとして機器ＩＤを代用とする場合、図示しない「送信元機器ＩＤ」にセットされている機器ＩＤと同一の値であれば「ダイジェスト」を省略してもよい。すなわち「証明書ダイジェスト」には、署名検証に使用する発信元の基地局装置２０に固有の公開鍵に紐付け可能な、公開鍵証明書に固有な値、或いは、発信元の基地局装置２０に固有な値であれば、いかなる値がセットされてもよい。ＭＡＣ値が導出されて「ＭＡＣ」にセットされる。図５（ａ）と同様に、ＭＡＣの演算対象は「ＭＡＣ方式ヘッダ」の「Ｎｏｎｃｅ」と「ペイロード長」と、「ＭＡＣ方式ペイロード」である。暗号化の対象は「ＭＡＣ方式ペイロード」と「ＭＡＣ方式フッタ」である。

図６は、セキュリティメッセージのデータ構造の別の一例を示す。これは、端末装置１０から報知される車車間通信のパケット信号に含まれるセキュリティメッセージに相当する。車車間通信では、路車間通信と比較して大きなサイズのパケット信号が送信できないこと、報知されるパケット信号の総数が多いこと、情報の精度が路車間送信のパケット信号に含まれる情報より低いことなどから、公開鍵暗号方式が使用されない。その代わりに、共通鍵暗号方式によるＭＡＣ（メッセージ認証コード）を使用して、パケット信号に含まれる情報の完全性を認証する。このデータ構造では、「バージョン・メッセージタイプ」、「ＭＡＣ方式ヘッダ」に続いて、「ＭＡＣ方式ペイロード」が配置され、最後に「ＭＡＣ方式フッタ」が配置される。「ＭＡＣ方式ヘッダ」には、「鍵ＩＤ」、「Ｎｏｎｃｅ」、「機器管理コード」が含まれる。なお図示しないが「ＭＡＣ方式ヘッダ」には、「ペイロード長」がさらに含まれてもよい。「ＭＡＣ方式ペイロード」には、「アプリケーション」が含まれる。「ＭＡＣ方式フッタ」には、「ＭＡＣ」が含まれる。「Ｎｏｎｃｅ」には、「機器ＩＤ」と「乱数」が含まれる。

「鍵ＩＤ」には、端末装置１０と基地局装置２０間、あるいは、ある端末装置１０と他の端末装置１０の間で事前に共有されている通信鍵を指定するための識別情報である鍵ＩＤがセットされる。「機器管理コード」は、端末装置１０の稼働状態を他の端末装置１０および基地局装置２０に通知するための状態コードがセットされる。「機器ＩＤ」には、パケット信号の発信元である端末装置１０に対して割り当てられた機器ＩＤがセットされる。ここで、機器ＩＤは、端末装置１０に対してユニークに付与された識別番号である。

「乱数」には、パケット信号の送信時に送信元が発生させた乱数がセットされる。すなわち、パケット信号の発信毎にユニークな値がセットされる。ここでは、「乱数」としているが、乱数に変えてメッセージの生成日時あるいは発信日時を示す「日時情報」にしてもよい。この場合、日時情報はパケット信号の発信毎にユニークである必要があるため、スーパーフレームの周期よりも細かい分解能が要求される。但し、精度は要求されない。

「アプリケーション」には、車車間アプリケーションデータがセットされる。ＭＡＣの演算対象は、「ＭＡＣ方式ヘッダ」の「Ｎｏｎｃｅ」と「機器管理コード」と「ＭＡＣ方式ペイロード」であり、暗号化の対象は、「ＭＡＣ方式ペイロード」と「ＭＡＣ方式フッタ」である。また以降では、ＭＡＣ方式ペイロードを単にペイロードとよぶものとする。

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

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

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

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

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

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

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

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

セキュリティ処理部２５は、セキュリティメッセージを生成または解釈する。セキュリティ処理部２５は、送信処理として、データ生成部２６からアプリケーションデータを受け取ると、ＭＡＣフレーム処理部２４に出力すべきセキュリティメッセージを、受け取ったアプリケーションデータ、記憶部２８に記憶されているデータ、認証局から受け取った秘密鍵、公開鍵証明書、通信鍵（共通鍵）などを利用して生成する。

例えば、図５（ａ）−（ｂ）に示す「ＭＡＣ方式ペイロード」の「アプリケーション」に、データ生成部２６から受け取ったアプリケーションデータをセットし、そのデータ長を「ＭＡＣ方式ヘッダ」の「ペイロード長」にセットする。また、図５（ｂ）に示す「ＭＡＣ方式ペイロード」の「アプリケーション」に対するハッシュ値を演算し、図５（ａ）に示す「ＭＡＣ方式ペイロード」の「後続パケットの認証用ハッシュリスト」にセットする。また、「ＭＡＣ方式ペイロード」の「後続パケットの認証用ハッシュリスト」と「アプリケーション」に対する署名を演算し、「ＭＡＣ方式ペイロード」の「電子署名」にセットする。また、「ＭＡＣ方式ヘッダ」の「鍵ＩＤ」に、使用する通信鍵の鍵ＩＤをセットする。また、当該通信鍵を用いて生成されるＭＡＣ値を「ＭＡＣ」にセットする。そして、その他のセキュリティヘッダを付加してセキュリティメッセージを生成する。その後、指定されたメッセージ形式が認証付き暗号化データの場合、「ＭＡＣ方式ペイロード」および「ＭＡＣ」を当該通信鍵を用いて暗号化することで、メッセージを秘匿する。なお、メッセージタイプが平文である場合、これらの処理は省略される。

セキュリティ処理部２５は、受信処理として、ＭＡＣフレーム処理部２４からのセキュリティメッセージを受けつける。セキュリティ処理部２５は、セキュリティメッセージのうちのセキュリティヘッダの内容を確認する。例えば、受け付けたセキュリティメッセージが図６の車車間通信のメッセージ（以下、車車間メッセージとも呼ぶ）で、メッセージタイプが認証付きデータである場合、メッセージのＭＡＣ検証処理を実行する。メッセージタイプが認証付き暗号化データである場合、メッセージの復号処理を実行し、ＭＡＣ検証処理を実行する。なお、メッセージタイプが平文である場合、これらの処理は省略される。受け付けたセキュリティメッセージが図５（ａ）−（ｂ）の路車間通信のメッセージ（以下、路車間メッセージとも呼ぶ）で、メッセージタイプが認証付きデータである場合、ＭＡＣおよび署名検証、ハッシュ一致確認処理を実行する。メッセージタイプが認証付き暗号化データである場合、メッセージの復号処理を実行し、ＭＡＣおよび署名検証、ハッシュ一致確認処理を実行する。なお、メッセージタイプが平文である場合、これらの処理は省略される。上述のように、基地局装置２０も車車間通信および路車間通信のパケット信号を受信し、パケット信号に含まれるメッセージを解釈する。また、セキュリティヘッダを確認することによって車車間メッセージなのか、路車間メッセージなのかを特定し、それに応じた受信処理を実行する。

セキュリティ処理部２５は、署名部１２５１、暗号部１２５２および記憶部１２５３を含む。ここでは、基地局装置２０からのパケット送信に注目するため、送信処理として実行されるセキュリティメッセージを生成する処理に注目する。受信処理として行われるセキュリティメッセージを解釈する処理については、後述する端末装置１０の受信処理と同じである。

記憶部１２５３は、本実施例では図示しない認証局が発行する秘密鍵と、この秘密鍵と対をなす公開鍵を含む公開鍵証明書、公開鍵証明書のダイジェスト、機器ＩＤ、複数の通信鍵を内部に格納している。このうち秘密鍵と公開鍵証明書は、基地局装置２０に固有である。署名部１２５１は、ハッシュ関数を用いて署名対象に対するハッシュ値を演算する。また、記憶部１２５３が格納する秘密鍵と、演算したハッシュ値を用いて署名対象に対する署名を生成する。暗号部１２５２は、記憶部１２５３に格納された通信鍵の１つを選択してＭＡＣ演算を実行し、ＭＡＣ対象に対するＭＡＣ値を求める。暗号部１２５２は、ＭＡＣ演算に用いた通信鍵を用いて暗号対象を暗号化する。

ＭＡＣは、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）−ＣＢＣ（Ｃｉｐｈｅｒ Ｂｌｏｃｋ Ｃｈａｉｎｉｎｇ）モードを利用したＭＡＣアルゴリズムを適用して生成される。なお、ＭＡＣの生成には、Ｎｏｎｃｅやペイロード長も利用される。暗号化は、ＡＥＳ＿ＣＴＲ（ＣｏｕｎＴｅＲ）モードを適用する。本実施例では、メッセージ形式が認証付き暗号化データの場合には、通信鍵を用いたＡＥＳ−ＣＣＭ（Ｃｏｕｎｔｅｒ ｗｉｔｈ ＣＢＣ−ＭＡＣ）モードを適用するため、ペイロードに対するＭＡＣの付加およびペイロードとＭＡＣの暗号化を行う。なお、ＡＥＳ―ＣＣＭモードを適用せずに、ペイロードより暗号化を行った後、ＭＡＣの付加を行ってもよいし、暗号化のみを行ってもよい。なお、ペイロードを対象としたＭＡＣの生成、およびペイロードとセキュリティフッタの暗号化には、通信鍵の他に、Ｎｏｎｃｅやペイロード長が利用される。ＣＢＣ−ＭＡＣおよびＣＣＭモードのアルゴリズムによるものであり、Ｎｏｎｃｅの使用により、ペイロードと通信鍵が同じであっても、異なったＭＡＣ値、暗号化の結果が得られる。

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

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

アンテナ１１、ＲＦ部１２、変復調部１３およびＭＡＣフレーム処理部１４は、図７のアンテナ２１、ＲＦ部２２、変復調部２３およびＭＡＣフレーム処理部２４の構成および動作と基本的に共通する。以下、これらの構成要素については、相違点を中心に説明する。アンテナ１１、ＲＦ部１２、変復調部１３およびＭＡＣフレーム処理部１４は、ＭＡＣの付加や暗号化等のセキュリティ処理がなされたデータを格納したパケット信号を報知する。また、アンテナ１１、ＲＦ部１２、変復調部１３およびＭＡＣフレーム処理部１４は、共通鍵暗号方式によるセキュリティ処理がなされたデータを受信する。

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

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

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

記憶部１８は、種々の情報を記憶する。例えば、本実施例では基地局装置２０から取得される道路情報、自己または他の端末装置１０から取得される車両情報を保持する。制御部１９は、端末装置１０全体の処理を制御する。

セキュリティ処理部１５は、セキュリティメッセージを生成または解釈する。セキュリティ処理部１５は、送信処理として、ＭＡＣフレーム処理部１４に出力すべきセキュリティメッセージを、記憶部１８に記憶されたデータをもとに生成する。例えば、図６に示す「ＭＡＣ方式ペイロード」の「アプリケーション」に、データ生成部１７から受け取ったアプリケーションデータをセットする。また、「ＭＡＣ方式ヘッダ」の「鍵ＩＤ」に、ＭＡＣ生成に使用する通信鍵の鍵ＩＤをセットし、「Ｎｏｎｃｅ」の「機器ＩＤ」、「乱数」に自己の機器ＩＤと、生成した乱数をセットする。また、鍵ＩＤによって共通鍵テーブルより選択された通信鍵を用いて生成されるＭＡＣ値を「ＭＡＣ方式フッタ」の「ＭＡＣ」にセットする。通信鍵は、共通鍵テーブルから任意に選択される。

セキュリティ処理部１５は、その他の情報を付加してセキュリティメッセージを生成する。メッセージ形式が、認証付き暗号化データの場合、ペイロードおよびＭＡＣを当該通信鍵を用いて暗号化することで、メッセージを秘匿する。なお、メッセージタイプが平文である場合、これらの処理は省略される。このようにセキュリティ処理部１５は、共通鍵テーブルに格納された共通鍵のうち、いずれかを使用することによって、データに対するセキュリティ処理を実行する。送信処理におけるセキュリティ処理とは、前述のごとく、ＭＡＣを生成することや、暗号化することである。

セキュリティ処理部１５は、受信処理として、ＭＡＣフレーム処理部１４からのセキュリティメッセージを受け付ける。セキュリティ処理部１５は、セキュリティメッセージのうちのセキュリティヘッダの内容を確認する。例えば、受け付けたセキュリティメッセージが図６の車車間メッセージで、メッセージタイプが認証付きデータである場合、メッセージの検証処理を実行する。メッセージ形式が認証付き暗号化データである場合、メッセージの復号処理および検証処理を実行する。なお、メッセージ形式が平文である場合、これらの処理は省略される。受け付けたセキュリティメッセージが図５（ａ）−（ｂ）の路車間通信メッセージで、メッセージタイプが認証付きデータである場合、ＭＡＣおよび署名検証、ハッシュ一致確認処理を実行する。メッセージタイプが認証付き暗号化データである場合、メッセージの復号処理を実行し、ＭＡＣおよび署名検証、ハッシュ一致確認処理を実行する。なお、セキュリティヘッダを確認することによって車車間メッセージなのか、路車間メッセージなのかを特定し、それに応じた受信処理を実行する。

メッセージタイプが認証付きデータまたは認証付き暗号化データである場合、セキュリティ処理部１５は、図５（ａ）−（ｂ）または図６に示すセキュリティメッセージを受け付けると、鍵ＩＤにしたがって、共通鍵テーブルに格納された共通鍵のうち、セキュリティメッセージに対して使用された共通鍵を通信鍵として取り出す。

セキュリティ処理部１５は、取り出した通信鍵によって、セキュリティ処理の送信処理とは逆の受信処理を実行する。すなわち、メッセージタイプが認証付きデータの場合、「Ｎｏｎｃｅ」、「ペイロード長」、「ＭＡＣ方式ペイロード」に対するＭＡＣ値を生成し、「ＭＡＣ」に格納されたＭＡＣ値と比較する。一致すればメッセージの完全性が確認される。また、メッセージタイプが認証付き暗号化データの場合、「ＭＡＣ方式ペイロード」および「ＭＡＣ方式フッタ」を復号し、復号後の「Ｎｏｎｃｅ」、「ペイロード長」、「ＭＡＣ方式ペイロード」に対するＭＡＣ値を生成し、「ＭＡＣ」に格納されたＭＡＣ値と比較する。一致すればメッセージの完全性が確認される。

また、図５（ａ）に示すセキュリティメッセージでは、「電子署名」の検証を行う。検証に成功すれば、メッセージの発信元の真正性が確認できる。図５（ｂ）に示すセキュリティメッセージでは、「アプリケーション」に対するハッシュ値を演算し、同じグループの図５（ａ）に示すセキュリティメッセージの「後続パケットの認証用ハッシュリスト」に含まれる自身に対するハッシュ値と比較する。同じグループの図５（ａ）に示すセキュリティメッセージの署名検証に成功し、かつハッシュ値が一致すれば、メッセージの発信元の真正性が確認される。セキュリティ処理の受信処理とは、メッセージの検証処理やメッセージの復号処理である。

セキュリティ処理部１５は、検証部１１５１、復号部１１５２および記憶部１１５３を含む。記憶部１１５３は、本実施例では図示しない認証局が発行する認証用の公開鍵と、自身の機器ＩＤ、共通鍵テーブルを内部に格納している。復号部１１５２は、セキュリティメッセージの「鍵ＩＤ」により特定される通信鍵を記憶部１１５３から取得して、暗号対象を復号する。検証部１１５１は、ハッシュ関数を用いたハッシュ値の演算と、ハッシュ値および記憶部１１５３に格納されている認証用の公開鍵を用いて基地局装置２０の公開鍵証明書の署名を検証する。また「電子署名」に格納された署名を、公開鍵証明書に含まれる公開鍵を用いて検証する。また、セキュリティメッセージの「鍵ＩＤ」により特定される通信鍵を用いて、ＭＡＣ検証をする。なお、認証用の公開鍵は、認証局において公開鍵証明書の署名を生成するのに用いた秘密鍵と対をなす公開鍵である。なお、復号および検証は送信側の暗号アルゴリズムに対応する復号アルゴリズムにより実行される。また、メッセージ形式が平文である場合、復号および検証は実行されない。

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

受信側の端末装置１０（図右）のＲＦ部１２は、当該パケット信号をアンテナ１１を介して受信する。当該パケット信号は、変復調部１３およびＭＡＣフレーム処理部１４を経て、セキュリティ処理部１５に渡される。セキュリティ処理部１５は、当該パケット信号に格納された鍵ＩＤにより特定される通信鍵を共通鍵テーブルから読み出し、当該パケット信号に格納された暗号化送信データを、当該通信鍵で復号し、ＭＡＣ検証する。ＭＡＣ検証が成功したら、暗号化送信データは平文の送信データに復元される。このような共通鍵暗号に関わる送信処理および受信処理は、基地局装置２０においてもなされる。以降では、路車間送信期間に基地局装置２０から送信される図５（ａ）と図５（ｂ）に従うセキュリティメッセージを路車間メッセージ、車車間送信期間に端末装置１０から送信される図６に従うセキュリティメッセージを車車間メッセージと呼ぶものとする。また、図３（ｂ）の先頭のＲＳＵパケットには、図５（ａ）に従う路車間メッセージ（先頭の路車間メッセージと呼ぶ）が、後続のＲＳＵパケットには、図５（ｂ）に従う路車間メッセージ（後続の路車間メッセージと呼ぶ）が含まれる。

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

図１０は、「メッセージ形式」の詳細である。先頭の２ビットである認証タイプ（ＡＴ）は、１ビットの２つのフラグ情報ＭＡＣ ＦｌａｇとＳＩＧ Ｆｌａｇからなる。ＭＡＣ Ｆｌａｇは、共通鍵暗号方式によるＭＡＣ認証に対応するか否かを示し、ＳＩＧ Ｆｌａｇは、公開鍵暗号方式による署名認証に対応するか否かを示す。ＭＡＣ認証のみに対応する場合、ＭＡＣ Ｆｌａｇ＝１、ＳＩＧ Ｆｌａｇ＝０となる。ＭＡＣ認証と署名認証の両方に対応する場合、ＭＡＣ Ｆｌａｇ＝１、ＳＩＧ Ｆｌａｇ＝１となる。メッセージタイプ（ＭＴ）には、平文データ形式（＝０）、認証付きデータ形式（＝１）および認証付き暗号化データ形式（＝２）がある。また、認証タイプ（ＡＴ）を利用して、車車間メッセージ（図６）と路車間メッセージ（図５（ａ）−（ｂ））を特定できるようにすることもできる。例えば、車車間メッセージ（図６）ではＡＴ＝１、先頭の路車間メッセージ（図５（ａ））ではＡＴ＝３、後続の路車間メッセージ（図５（ｂ））ではＡＴ＝２とすれば、セキュリティメッセージのデータ構造を特定することが可能である。

図１１は、検証部１１５１の構成例を示す。構成例に係る検証部１１５１は、ハッシュ比較部１１５１ａ、署名検証部１１５１ｂ、ダイジェスト保持部１１５１ｃ、ＭＡＣ検証部１１５１ｄ、判定部１１５１ｅを含む。

署名検証部１１５１ｂは、先頭の路車間メッセージに含まれる公開鍵証明書の署名、およびハッシュリストを少なくとも含むデータ列から生成された署名を検証する。図５（ａ）のデータ構造では、当該データ列は、ハッシュリストとアプリケーションデータで構成される。公開鍵証明書の署名は、認証局が発行する認証用の公開鍵を用いて検証する。当該データ列に対する署名は、公開鍵証明書に含まれる公開鍵を用いて検証する。

署名検証部１１５１ｂは、先頭の路車間メッセージに含まれるハッシュリストをダイジェスト保持部１１５１ｃに格納する。また署名検証部１１５１ｂは、先頭の路車間メッセージに含まれる公開鍵証明書のダイジェストを生成し、ダイジェスト保持部１１５１ｃに格納する。ハッシュ比較部１１５１ａは、ダイジェスト保持部１１５１ｃに保持される公開鍵証明書のダイジェストと、受信した先頭の路車間メッセージに含まれる公開鍵証明書から生成した公開鍵証明書のダイジェストとが一致する場合、当該先頭の路車間メッセージに含まれる公開鍵証明書の署名検証成功と判定してもよい。

ＭＡＣ検証部１１５１ｄは、先頭の路車間メッセージ、後続の路車間メッセージ、および車車間メッセージに含まれるＭＡＣを検証する。ＭＡＣは、鍵ＩＤで特定される通信鍵を用いて検証する。

ハッシュ比較部１１５１ａは、後続の路車間メッセージに含まれるアプリケーションデータを少なくとも含むデータ列からハッシュ値を演算する。ハッシュ比較部１１５１ａは、演算したハッシュ値と、ダイジェスト保持部１１５１ｃに保持されるハッシュリスト内のハッシュ値とを比較する。

判定部１１５１ｅは、署名検証部１１５１ｂによる署名の検証結果、ＭＡＣ検証部１１５１ｄによるＭＡＣの検証結果、ハッシュ比較部１１５１ａによるハッシュの比較結果をもとに、セキュリティメッセージを承認するか否か判定する。車車間メッセージでは、ＭＡＣ検証に成功したとき、先頭の路車間メッセージでは、ＭＡＣ検証に成功し、かつ署名検証に成功したとき、後続の路車間メッセージでは、ＭＡＣ検証に成功し、ハッシュ値が一致し、かつ先頭の路車間メッセージの署名検証に成功したとき、セキュリティメッセージを承認する。車車間メッセージでは、ＭＡＣ検証に失敗したとき、先頭の路車間メッセージでは、ＭＡＣ検証に失敗、または署名検証に失敗したとき、後続の路車間メッセージでは、ＭＡＣ検証の失敗、先頭の路車間メッセージの署名検証の失敗およびハッシュ値の不一致がひとつでも発生したとき、メッセージを否認する。

図１２は、本実施例に係る、端末装置１０でのメッセージ検証処理の一例を示すフローチャートである。受信部は、基地局装置２０または他の端末装置１０から報知されたパケット信号を受信する（Ｓ１０）。なお受信部は、アンテナ１１、ＲＦ部１２、変復調部１３、ＭＡＣフレーム処理部１４により実現される。

受信したパケット信号のセキュリティメッセージ内の「メッセージタイプ」のフラグが参照され、メッセージが暗号化データである場合（Ｓ１１のＹ）、復号部１１５２は、セキュリティメッセージの暗号化部分を復号する（Ｓ１２）。図４、図５（ａ）、及び図５（ｂ）に示すデータ構造では「ＭＡＣ方式ペイロード」および「ＭＡＣ方式フッタ」が暗号化部分である。復号部１１５２は、セキュリティメッセージの「鍵ＩＤ」により特定される通信鍵を記憶部１１５３から取得して、「ＭＡＣ方式ペイロード」及び「ＭＡＣ方式フッタ」を復号する。メッセージが暗号化データでない場合（Ｓ１１のＮ）、ステップＳ１２はスキップされる。

メッセージがＭＡＣ付きデータである場合（Ｓ１３のＹ）、ＭＡＣ検証部１１５１ｄはＭＡＣ検証を実行する（Ｓ１４）。ＭＡＣ検証の詳細は後述する。メッセージがＭＡＣ付きデータでない場合（Ｓ１３のＮ）、ステップＳ１４はスキップされる。

メッセージが署名付きデータである場合（Ｓ１５のＹ）、ステップＳ１６に進み、署名付きデータでない場合（Ｓ１５のＮ）、ステップＳ１９に進む。本実施例では路車間メッセージでは署名を使用し、車車間メッセージでは署名を使用しないため、基地局装置２０から報知されたパケット信号の場合はステップＳ１６に進み、他の端末装置１０から報知されたパケット信号の場合はステップＳ１９に進む。

ステップＳ１６では、メッセージを構成する複数のパケットのうち、先頭のパケットであるか否か判定する（Ｓ１６）。先頭のパケットである場合（Ｓ１６のＹ）、署名検証部１１５１ｂは署名検証を実行する（Ｓ１７）。署名検証の詳細は後述する。先頭以外のパケットである場合（Ｓ１６のＮ）、ハッシュ比較部１１５１ａはハッシュ一致検証を実行する（Ｓ１８）。ハッシュ一致検証の詳細は後述する。

判定部１１５１ｅは、実行された検証の全ての結果が成功の場合、受信したメッセージを正当なメッセージと判定する（Ｓ１９）。車車間メッセージの場合、ＭＡＣ検証が成功したら正当と判定する。路車間メッセージの場合、ＭＡＣ検証、署名検証およびハッシュ一致検証が成功したら正当と判定する。いずれかが失敗したら正当でないと判定する。

ステップＳ１０〜ステップＳ１９までの処理は、電源オンの間（Ｓ２０のＮ）、繰り返し実行される。電源オフされると（Ｓ２０のＹ）、全体の処理を終了する。

図１３は、図１２のＭＡＣ検証のサブルーチンを示すフローチャートである。ＭＡＣ検証部１１５１ｄは、セキュリティメッセージのＭＡＣ対象部分のＭＡＣ値を演算する（Ｓ１４２）。図５（ａ）に示す路車間メッセージの先頭パケットのセキュリティメッセージでは、「Ｎｏｎｃｅ」、「ペイロード長」、「公開鍵証明書」、「後続パケットの認証用ハッシュリスト」、「アプリケーション」、「電子署名」がＭＡＣ対象部分である。図５（ｂ）に示す路車間メッセージの後続パケットのセキュリティメッセージでは、「Ｎｏｎｃｅ」、「ペイロード長」、「証明書ダイジェスト」、「アプリケーション」がＭＡＣ対象部分である。図６に示す車車間メッセージのパケットでは、「Ｎｏｎｃｅ」、「機器管理コード」、「アプリケーション」がＭＡＣ対象部分である。

ＭＡＣ検証部１１５１ｄは、セキュリティメッセージの「ＭＡＣ」に格納されたＭＡＣ値と、演算したＭＡＣ値を比較し（Ｓ１４３）、一致したときは（Ｓ１４３のＹ）、判定部１１５１ｅに検証成功を通知し（Ｓ１４４）、一致しないときは（Ｓ１４３のＮ）、判定部１１５１ｅに検証失敗を通知する（Ｓ１４５）。検証成功であれば、メッセージの完全性を確認できる。

図１４は、図１２の署名検証のサブルーチンを示すフローチャートである。サブルーチンは、署名検証部１１５１ｂは、セキュリティメッセージの「公開鍵証明書」に格納された公開鍵証明書のダイジェストを演算する（Ｓ１７２）。本実施例では公開鍵証明書の署名対象部分のハッシュ値を演算する。署名検証部１１５１ｂは、演算した公開鍵証明書のダイジェスト及び「後続パケットの認証用ハッシュリスト」に格納されたハッシュリストをダイジェスト保持部１１５１ｃに退避させる（Ｓ１７３）。

署名検証部１１５１ｂは、公開鍵証明書の署名を、予め保持する認証用の公開鍵を用いて検証する（Ｓ１７４）。この署名検証は、公開鍵証明書の検証に成功したときに、公開鍵証明書のダイジェスト、あるいは、識別番号などの代表値を記憶部１１５３に保持しておき、ダイジェスト保持部１１５１ｃに代表値が保持されているときには、代表値の一致判定で代替してもよい。ダイジェスト保持部１１５１ｃに保持される公開鍵証明書のダイジェストと、演算された公開鍵証明書の代表値が一致すれば、以前に受信した基地局装置２０からのパケット信号に含まれるセキュリティメッセージと判定できる。なお、ダイジェスト保持部１１５１ｃに代表値が保持されていないときは、必ず署名の検証を行う。公開鍵証明書の署名検証が失敗した場合（Ｓ１７４のＮ）、判定部１１５１ｅに検証失敗を通知する（Ｓ１７８）。検証成功であれば、メッセージの発信元の真正性を確認できる。

公開鍵証明書の署名検証が成功した場合（Ｓ１７４のＹ）、署名検証部１１５１ｂは、図５（ａ）に従う路車間メッセージの場合の電子署名の対象部分である「後続の路車間メッセージのための認証用ハッシュリスト」、「アプリケーション」を対象とするハッシュを演算する（Ｓ１７５）。署名検証部１１５１ｂは、ステップＳ１７４で署名の検証に成功した公開鍵証明書の公開鍵を用いて、セキュリティメッセージの「電子署名」に格納された電子署名と、演算したハッシュに基づく署名検証の確認を行う（Ｓ１７６）。署名検証が成功した場合（Ｓ１７６のＹ）、判定部１１５１ｅに検証成功を通知し（Ｓ１７７）、署名検証が失敗した場合（Ｓ１７６のＮ）、判定部１１５１ｅに検証失敗を通知する（Ｓ１７８）。検証成功であれば、先頭の路車間メッセージの発信元の真正性を確認できる。

図１５は、図１２のハッシュ一致検証のサブルーチンを示すフローチャートである。ハッシュ比較部１１５１ａは、ダイジェスト保持部１１５１ｃにハッシュリストが保持されているか否か確認する（Ｓ１８２）。複数の基地局装置２０からパケット信号が報知されている場合、複数のハッシュリストがダイジェスト保持部１１５１ｃに保持されるが、公開鍵証明書のダイジェストを用いることにより、同一の基地局装置２０により生成されたハッシュリストを特定できる。ステップＳ１８２において、同一の基地局装置２０のハッシュリストが保持されていない場合（Ｓ１８２のＮ）、判定部１１５１ｅに検証失敗を通知する（Ｓ１８６）。同一の基地局装置２０のハッシュリストが保持されている場合（Ｓ１８２のＹ）、ハッシュ比較部１１５１ａは、セキュリティメッセージの「アプリケーション」のハッシュ値を演算する（Ｓ１８３）。

ハッシュ比較部１１５１ａは、ダイジェスト保持部１１５１ｃに保持されるハッシュリスト内のハッシュ値と、演算したハッシュ値を比較する（Ｓ１８４）。その際、パケットの番号が同じもの同士を比較する。ハッシュ値が一致したときは（Ｓ１８４のＹ）、判定部１１５１ｅに検証成功を通知し（Ｓ１８５）、一致しないときは（Ｓ１８４のＮ）、判定部１１５１ｅに検証失敗を通知する（Ｓ１８６）。検証成功であれば、後続の路車間メッセージの真正性を確認できる。

図１２から図１５では、ＭＡＣ検証、署名検証、ハッシュ一致検証を時系列順に処理する例を想定したが、以下、ＭＡＣ検証、署名検証、ハッシュ一致検証を並行して処理する例を説明する。この例は、ＭＡＣ検証用の専用ハードウェア、署名検証用の専用ハードウェア、ハッシュ一致検証用の専用ハードウェアを実装する場合や、複数のコアで複数の検証処理を別々に処理できる場合に適用できる。

図１６は、本実施例に係る、端末装置１０でのメッセージ検証処理の別の例を示すフローチャートである。ステップＳ１０〜ステップＳ１２までの処理は、図１２のフローチャートと同じである。

受信したパケット信号のセキュリティメッセージが検証可能な状態になると、ＭＡＣ検証部１１５１ｄ、署名検証部１１５１ｂ、ハッシュ比較部１１５１ａは、それぞれ独立に検証処理を実行する（Ｓ１４、Ｓ１７、Ｓ１８）。判定部１１５１ｅは、全ての検証結果が揃った時点で、受信したメッセージが正当なメッセージであるか否か判定する（Ｓ１９）。ステップＳ１０〜ステップＳ１９までの処理は、電源オンの間（Ｓ２０のＮ）、繰り返し実行される。電源オフされると（Ｓ２０のＹ）、全体の処理を終了する。

図１７は、図１６のＭＡＣ検証のサブルーチンを示すフローチャートである。ＭＡＣ検証部１１５１ｄは、受信したパケット信号のセキュリティメッセージ内の「メッセージタイプ」のフラグを参照し、メッセージがＭＡＣ付きデータである場合（Ｓ１４１のＹ）、ステップＳ１４２に進む。ＭＡＣ付きデータでない場合（Ｓ１４１のＮ）、判定部１１５１ｅに対象外であることを通知する（Ｓ１４６）。ステップＳ１４２以降の処理は、図１３と同じである。

図１８は、図１６の署名検証のサブルーチンを示すフローチャートである。署名検証部１１５１ｂは、受信したパケット信号のセキュリティメッセージ内の「メッセージタイプ」のフラグを参照し、メッセージが署名付きデータであり、かつ先頭の路車間メッセージである場合（Ｓ１７１のＹ）、ステップＳ１７２に進む。そうでない場合（Ｓ１７１のＮ）、判定部１１５１ｅに対象外であることを通知する（Ｓ１７９）。ステップＳ１７２以降の処理は、図１４と同じである。

図１９は、図１６のハッシュ一致検証のサブルーチンを示すフローチャートである。ハッシュ比較部１１５１ａは、受信したパケット信号のセキュリティメッセージ内の「メッセージタイプ」のフラグを参照し、メッセージが署名付きデータであり、かつ後続の路車間メッセージである場合（Ｓ１８１のＹ）、ステップＳ１８２に進む。そうでない場合（Ｓ１８１のＮ）、判定部１１５１ｅに対象外であることを通知する（Ｓ１８７）。ステップＳ１８２以降の処理は、図１５と同じである。なお、「電子署名」が「アプリケーション」の前に配置される場合、ステップＳ１８１において、メッセージが署名付きデータであれば、ステップＳ１８２に進む。

以上説明したように、署名、ＭＡＣ、ハッシュリストを併用したメッセージフォーマットを採用することにより、軽負荷で発信元の特定ができるメッセージ検証を実現できる。すなわち、署名検証により発信元を特定できる。署名検証が成功したら、同一の公開鍵証明書を含むメッセージのＭＡＣ検証成功およびハッシュ値一致によりメッセージを承認する。これにより、処理負荷を軽減できる。また署名検証を公開鍵証明書のダイジェストの一致で代替することにより、処理負荷をさらに軽減できる。署名検証コアと共通鍵コアを併用することで、発信元の特定と、リアルタイムでのメッセージ検証の両方を実現できる。

基地局装置２０から報知される路車間通信のパケット信号に含まれるセキュリティメッセージは次のように構成されてもよい。図２０（ａ）−（ｂ）は、セキュリティメッセージのデータ構造のさらに別の一例を示す。図５（ａ）−（ｂ）の変形例である。図２０（ａ）は、図３（ｂ）に示された複数のＲＳＵパケットのうちの、先頭のＲＳＵパケットのセキュリティメッセージであり、図５（ａ）に相当する。図２０（ｂ）は、２番目以降のＲＳＵパケットのセキュリティメッセージであり、図５（ｂ）に相当する。

図５（ａ）のデータ構造では「電子署名」が「アプリケーション」の後に配置されるが、図２０（ａ）のデータ構造では「電子署名」が「アプリケーション」の前に配置される。図２０（ａ）のデータ構造では、先頭のＲＳＵパケットの「パケットの認証用ハッシュリスト」には、グループを構成するすべてのセキュリティメッセージの「アプリケーション」に対するハッシュ値を配置したリストがセットされる。電子署名の対象は「パケットの認証用ハッシュリスト」のみである。これによって処理を単一化できる。また、先頭のＲＳＵパケットのアプリケーションデータの通信喪失による欠落によって、「パケットの認証用ハッシュリスト」に対する電子署名の検証ができなくなることを防止できる。また、早期に署名検証処理を始めることができる。図２０（ｂ）のデータ構造と図５（ｂ）のデータ構造は同じである。図２０（ａ）に従う路車間メッセージを先頭の路車間メッセージ、図２０（ｂ）に従う路車間メッセージを後続の路車間メッセージと呼ぶ。

なお、図２０（ａ）−（ｂ）に従う路車間メッセージの場合でも、端末装置１０は、図１２のフローチャートにしたがいメッセージ検証処理を行う。但し、先頭の路車間メッセージの「アプリケーションデータ」に対するハッシュ値も「パケットの認証用ハッシュリスト」に配置されているため、先頭の路車間メッセージについても図１２のステップＳ１８のハッシュ一致検証が実行されるように変更される。すなわち、ステップＳ１８は、ステップＳ１５のＹとステップＳ１６の間で処理される。

図２１は、図２０（ａ）−（ｂ）に従う路車間メッセージの場合の署名検証のサブルーチンを示すフローチャートである。図１４のフローチャートと図２１のフローチャートは基本的に同じであるが、ステップＳ１７５のハッシュの演算処理が異なる。図２１のフローチャートでは、署名検証部１１５１ｂは、図２０（ａ）に従う路車間メッセージの場合の電子署名の対象部分である「後続パケットの認証用ハッシュリスト」のハッシュを演算する（Ｓ１７５ａ）。演算して求めたハッシュと、路車間メッセージに含まれる電子署名に基づいて「ハッシュリスト」の署名検証を確認する（Ｓ１７６ａ）。その他の処理は、図１４のフローチャートと同じである。ＭＡＣ検証およびハッシュ一致検証のサブルーチンは、図１３、図１５と同じである。

同様に、図２０（ａ）−（ｂ）に従う路車間メッセージの場合でも、端末装置１０は、図１６〜図１９のフローチャートに従いメッセージ検証処理を行う。但し、署名検証の対象が、「後続パケットの認証用ハッシュリスト」と「アプリケーションデータ」から、「後続パケットの認証用ハッシュリスト」に変更されているため、図１８のステップＳ１７５において「後続パケットの認証用ハッシュリスト」に対してのみのハッシュを演算するように変更し、ステップＳ１７６において「ハッシュリストとアプリケーションの署名検証成功」を確認するように変更する。また、先頭の路車間メッセージの「アプリケーションデータ」に対するハッシュ値も「パケットの認証用ハッシュリスト」に配置されているため、図１９のステップＳ１８１において、署名付きデータかどうかの判断を行うように変更し、先頭の路車間メッセージのときにも、ステップＳ１８２に移行するように変更する。

以下では、これまで説明した処理をレイヤとの関連で説明する。図２２（ａ）は、基地局装置２０において、図２２（ｂ）は端末装置１０において規定されるレイヤの構成を示す。図２２（ａ）の基地局装置２０における送信処理のレイヤ構成を説明する。アプリケーションレイヤは、データ生成部２６またはネットワーク通信部２７に含まれる。具体的には、基地局装置２０の記憶部２８に事前に保持されている道路線形情報やセンサ設置情報、基地局装置２０と併設された信号機の灯消情報、あるいは基地局装置２０の周辺に設置されたセンサによって検知された車両や人の位置や移動などを示すセンサ情報など基地局装置２０から発信されるアプリケーションデータに対応するアプリケーションレイヤはデータ生成部２６に含まれる。工事情報、落下物情報、渋滞情報あるいは緊急車両などの交通管制センタからネットワークを介して供されるアプリケーションデータに対応するアプリケーションレイヤはネットワーク通信部２７に含まれる。分割処理層、パケット管理層、セキュリティ層は、図７のセキュリティ処理部２５に含まれ、無線送信層は、図７のＲＦ部２２、変復調部２３、ＭＡＣフレーム処理部２４に含まれる。

図２２（ｂ）の端末装置1０における受信処理のレイヤ構成を説明する。アプリケーションレイヤは、図８の受信処理部１６１に含まれ、分割処理層、パケット管理層、セキュリティ層は、図８のセキュリティ処理部１５に含まれ、無線受信層は、図８のＲＦ部１２、変復調部１３、ＭＡＣフレーム処理部１４に含まれる。

アプリケーションレイヤは、１種類あるいは複数種類のアプリケーションによって構成される。ここでは、３種類のアプリケーションＡＰＰ１、ＡＰＰ２およびＡＰＰ３によって構成され、それぞれがアプリケーションデータＤ１、Ｄ２およびＤ３を提供するものとする。分割処理層には、送信対象となるアプリケーションデータがアプリケーションレイヤより入力される。

図２３（ａ）−（ｅ）は、基地局装置２０における送信処理の各レイヤにおける処理の概要を示す。なお、横軸は時間を示す。図２３（ａ）は、分割処理層に入力されるアプリケーションデータを示す。分割処理層は、複数のアプリケーションから入力されたアプリケーションデータを送信順序に並べ、それぞれのアプリケーションデータのサイズと下位の各層、特にセキュリティ層によって付加されるヘッダあるいはフッタといった付加データのサイズを考慮して、それを送信可能なサイズに分割する。図２３（ｂ）は、分割処理層によって分割されたデータの系列を示す。例えば、Ｄ１は、Ｄ１（ｉ）とＤ１（ｉｉ）に分割される。分割されたデータのそれぞれには、ＥＬヘッダが付加される。図２２（ａ）に戻る。ＥＬヘッダには、受信時に分割されたアプリケーションデータを再構成するための結合情報が含まれている。分割処理層は、分割したデータをパケット管理層に出力する。

パケット管理層は、分割されたデータのうち、先頭に現在の日時を送信日時として付加する。送信日時はリプレイス攻撃対策として付加する。図２３（ｃ）は、パケット管理層によって、送信日時が付加されたデータの系列を示す。図２２（ａ）に戻る。パケット管理層は、送信日時が付加されたデータをセキュリティ層に出力する。セキュリティ層は、送信日時が付加されたデータに対してセキュリティ処理を実行する。図２３（ｄ）は、セキュリティ処理がなされたデータを示す。例えば、ＭＡＣヘッダ、公開鍵証明書、ハッシュリスト、署名、ＭＡＣ、ダイジェストが、データに付加される。ハッシュリストは、データ単位に生成されるので、Ｄ１（ｉ）、Ｄ１（ｉｉ）等のそれぞれに対して生成されたハッシュ値を含む。図２２（ａ）に戻る。セキュリティ層は、セキュリティ処理がなされたデータをパケット管理層に出力し、パケット管理層は、これを無線送信層に出力する。無線送信層は、各データをパケット信号に格納し、パケット信号を報知する。図２３（ｅ）は、パケット信号を示す。ここで、ＳＬ１、ＳＬ２等は、前述の路車間送信期間を示し、Ｐ１、Ｐ２等は、パケット信号を示す。

端末装置１０の受信処理は、図２３における処理を（ｅ）から（ｂ）に逆順で進み、ＥＬヘッダを参照してアプリケーションデータＤ１、Ｄ２およびＤ３を再構成して、それぞれを対応するアプリケーションＡＰＰ１、ＡＰＰ２およびＡＰＰ３に出力する。

次に、データを分割する状況下において、セキュリティ処理を簡易にする処理を説明する。これまでは、データを分割してからハッシュリストを生成していた。前述のごとく、ハッシュリストのサイズは、分割されたデータの数に依存する。つまり、当該サイズは、可変値であり、固定値ではない。そのため、ハッシュリストのサイズが大きくなることによって、ひとつのパケット信号に格納できなくなった場合に、さらにデータを分割し、ハッシュリストが再度作成される。このような処理を簡易にするために、データを分割する前にハッシュリストを生成し、ハッシュリストが付加されたデータを分割する。データの数は入力時に認識されるので、ハッシュリストのサイズは、その時点で固定される。その結果、分割処理においてハッシュリストのサイズは、固定値とみなされるので、処理が簡易になる。

図７において、セキュリティ処理部２５は、複数種類のアプリケーションデータを入力する。セキュリティ処理部２５は、複数種類のアプリケーションデータのそれぞれに対して、公開鍵暗号方式を使用することによって導出した各データの代表値が含まれたリストを生成する。ここでは、アプリケーションデータ毎にハッシュ関数を適用することによって、ハッシュ値を生成する。さらに、セキュリティ処理部２５は、複数のアプリケーションデータのそれぞれに対するハッシュ値をまとめることによってハッシュリストを生成する。この段階において、ハッシュリストは固定値となる。セキュリティ処理部２５は、ハッシュリストと、複数種類のアプリケーションデータとを複数に分割する。その際、先頭のアプリケーションデータの前段にハッシュリストが付加される。また、分割はアプリケーションプログラム単位になされる。さらに、ＭＡＣフレーム処理部２４は、分割結果のそれぞれをパケット信号に格納することによって、複数のパケット信号を生成する。変復調部２３、ＲＦ部２２は、複数のパケット信号を報知する。

図２４（ａ）は、基地局装置２０において、図２４（ｂ）は端末装置１０において規定されるレイヤの構成を示す。図２２（ａ）−（ｂ）と同様に、ここでも、基地局装置２０における送信処理のレイヤ構成を説明する。アプリケーションレイヤは、データ生成部２６またはネットワーク通信部２７に含まれる。分割管理層、上位セキュリティ層、パケット管理層、下位セキュリティ層は、図７のセキュリティ処理部２５に含まれ、無線送信層は、図７のＲＦ部２２、変復調部２３、ＭＡＣフレーム処理部２４に含まれる。図２４（ｂ）の端末装置1０における受信処理のレイヤ構成を説明する。アプリケーションレイヤは、図８の受信処理部１６１に含まれ、分割処理層、上位セキュリティ層、パケット管理層、下位セキュリティ層は、図８のセキュリティ処理部１５に含まれ、無線受信層は、図８のＲＦ部１２、変復調部１３、ＭＡＣフレーム処理部１４に含まれる。

図２５（ａ）−（ｆ）は、基地局装置２０における送信処理の各レイヤにおける処理の概要を示す。図２５（ａ）は、分割処理層に入力されるアプリケーションデータを示し、これは図２３（ａ）と同一である。図２４（ａ）に戻る。分割処理層は、入力したアプリケーションデータのうち、先頭に送信日時を付加する。図２５（ｂ）は、送信日時が付加されたアプリケーションデータの系列を示す。図２４（ａ）に戻る。分割処理層は、送信日時が付加されたアプリケーションデータを上位セキュリティ層に出力する。

上位セキュリティ層は、送信日時が付加されたアプリケーションデータに対してセキュリティ処理を実行する。図２５（ｃ）は、セキュリティ処理がなされたデータを示す。例えば、公開鍵証明書、ハッシュリスト、署名、ダイジェストが、アプリケーションデータに付加される。図２４（ａ）に戻る。上位セキュリティ層は、セキュリティ処理がなされたアプリケーションデータを分割処理層に出力する。

分割処理層は、セキュリティ処理がなされたアプリケーションデータのサイズに応じて、それを分割する。図２５（ｄ）は、分割処理層によって分割されたデータの系列を示す。図２３（ｂ）と同様に、Ｄ１は、Ｄ１（ｉ）とＤ１（ｉｉ）に分割される。分割されたデータのそれぞれには、ＥＬヘッダが付加される。図２４（ａ）に戻る。分割処理層は、分割したデータをパケット管理層に出力し、パケット管理層は、これを下位セキュリティ層に出力する。

下位セキュリティ層は、分割されたデータに対してセキュリティ処理を実行する。図２５（ｅ）は、セキュリティ処理がなされたデータを示す。例えば、ＭＡＣヘッダ、ＭＡＣがデータに付加される。図２４（ａ）に戻る。下位セキュリティ層は、セキュリティ処理がなされたデータをパケット管理層に出力し、パケット管理層は、これを無線送信層に出力する。無線送信層は、各データをパケット信号に格納し、パケット信号を報知する。図２５（ｆ）は、パケット信号を示しており、これは、図２３（ｅ）と同一である。端末装置１０の受信処理は、図２５における処理を（ｆ）から（ｂ）に逆順で進み、ＥＬヘッダを参照してアプリケーションデータＤ１、Ｄ２およびＤ３を再構成して、それぞれを対応するアプリケーションＡＰＰ１、ＡＰＰ２およびＡＰＰ３に出力する。

これまで基地局装置２０は、ハッシュリストと先頭のデータとを同一のパケット信号に格納しているが、これらを別のパケット信号に含めてもよい。つまり、セキュリティ処理部２５は、複数種類のデータが含まれていないパケット信号にハッシュリストを含める。そのため、データが含まれたパケット信号と、ハッシュリストが含まれたパケット信号とが別に生成される。また、ここまで端末装置１０を路車間メッセージの受信先として説明したが、ある基地局装置２０が送信した路車間メッセージを別の基地局装置２０が受信することもできる。この場合、上述した端末装置１０の受信に関する内容は、基地局装置２０にも適用されることは明らかである。

図２６（ａ）−（ｆ）は、各レイヤにおける別の処理の概要を示す。これらは、図２５（ａ）−（ｆ）と同様に示されているので、差異のみを説明する。図２６（ｃ）は、セキュリティ処理がなされたデータを示す。ここで、ハッシュリストは、Ｄ１に連結されずに、別々に構成されている。

これまで、基地局装置２０および端末装置１０から報知されるパケット信号は、原則的に、全ての基地局装置２０および端末装置１０が受信可能なことを前提とした。即ち、汎用サービスを前提とした。以下、特定の基地局装置２０または特定の端末装置１０に対してのみデータを提供する特定サービスについて説明する。特定サービスには、基地局装置２０間（路側機間）でデータをやりとりする路路間サービス、基地局装置２０から特定の端末装置１０にデータを提供する路車間特定サービスがある。路車間特定サービスは、例えば有償契約を結んでいる車載機のみにデータを提供するサービスである。いずれも基地局装置２０が送信する路車間メッセージによって情報伝達を行うサービスとする。

図２７は、汎用サービスと特定サービスが併用される通信システムにおけるデータ構造の一例を示す図である。コンテナとは、複数のサービスに対するデータをまとめたものである。コンテナは、複数のメッセージで構成される。図中、Ｎ（自然数）はコンテナを構成するセキュリティメッセージの数を、Ｍ（正の整数）はコンテナを識別するための識別番号である。メッセージ＃１は、「ヘッダ」、「鍵情報」、「公開鍵証明書」、「ハッシュリスト」、「署名」、「フレームＩＤ、メッセージＩＤ、分割数」、「アプリケーション」、「ＭＡＣ」が配置される。メッセージ＃１のデータ構造は、図２０（ａ）のセキュリティメッセージのデータ構造に、メッセージ＃２、・・・・、メッセージ＃Ｎのデータ構造は、図２０（ｂ）のセキュリティメッセージのデータ構造に基本的に対応している。

「ハッシュリスト」には、コンテナを構成する複数のメッセージ♯１〜♯Ｎのそれぞれのダイジェストがセットされる。ダイジェストは、「フレームＩＤ、メッセージＩＤ、分割数」および「アプリケーション」に対するハッシュ値が使用される。「署名」には、「ハッシュリスト」を、公開鍵証明書に含まれる公開鍵と対をなす秘密鍵で暗号化して生成される電子署名がセットされる。フレームＩＤはコンテナの識別情報である。メッセージＩＤはメッセージの識別情報である。分割数はコンテナの分割数である。「ＭＡＣ」には、「公開鍵証明書」、「ハッシュリスト」、「署名」、「フレームＩＤ、メッセージＩＤ、分割数」、「アプリケーション」に対するＭＡＣ値がセットされる。「公開鍵証明書」、「ハッシュリスト」、「署名」、「フレームＩＤ、メッセージＩＤ、分割数」、「アプリケーション」、「ＭＡＣ」は暗号化される。

メッセージ＃２〜＃Ｎは、「ヘッダ」、「鍵情報」、「署名者ＩＤ」、「フレームＩＤ、メッセージＩＤ、分割数」、「アプリケーション」、「ＭＡＣ」が配置される。メッセージ＃２〜♯Ｎのデータ構造は、図５（ｂ）のセキュリティメッセージのデータ構造に基本的に対応している。

「署名者ＩＤ」には、メッセージ♯１の「署名」を作成した署名者の識別情報がセットされる。図２０（ｂ）における「証明書ダイジェスト」に相当する。「ＭＡＣ」には、「フレームＩＤ、メッセージＩＤ、分割数」、「アプリケーション」に対するＭＡＣ値がセットされる。「署名者ＩＤ」、「フレームＩＤ、メッセージＩＤ、分割数」、「アプリケーション」、「ＭＡＣ」は暗号化される。

図２８は、図２７の「鍵情報」のデータ構造の一例を示す図である。「鍵情報」には、「鍵ＩＤ」、「暗号化通信鍵」が含まれる。「鍵ＩＤ」には、「テーブルＩＤ」、「サービスＩＤ」、「個別ＩＤ」が含まれる。「暗号化通信鍵」には、送信元で発生させた乱数をマスタ鍵で暗号化した通信鍵がセットされる。「テーブルＩＤ」には、通信システム５００を構成する基地局装置２０および端末装置１０間で予め共有される共通鍵テーブルの識別情報がセットされる。各共通鍵テーブルは少なくともひとつのマスタ鍵を格納する。「サービスＩＤ」には、メッセージ送信のサービス種別を特定するための識別情報がセットされる。「個別ＩＤ」には、マスタ鍵そのものを特定するための識別情報がセットされる。「鍵情報」は、送信元の基地局装置２０が使用した通信鍵を受信先の端末装置１０あるいは別の基地局装置２０に通知するための情報であり、図２０（ａ）−（ｂ）における「鍵ＩＤ」に相当する。

図２７、図２８に示すようなハイブリッド形式のセキュリティメッセージを採用する通信システム５００において、サービス種別ごとにコンテナを構成するとオーバヘッドが大きくなる。これに対して、複数のサービスに対するデータを同一コンテナで送信すると送信順序によっては、サービスに対応するデータを受信できない事態が発生する。以下、この問題を解決する手法を説明する。

前提として、サービス種別ごとにマスタ鍵を設定するとともに、端末装置１０および基地局装置２０は対応するサービスのマスタ鍵を保持する。複数のサービスに対するデータを同一コンテナで送信する場合、先頭のメッセージは必ず汎用サービスのデータを配置する。汎用サービスのマスタ鍵は、全ての端末装置１０および基地局装置２０で共有されている。また、汎用サービスのマスタ鍵を使用して生成される先頭のメッセージの「アプリケーション」は空としてもよい。これらにより、セキュリティによるオーバヘッドの増加を抑えつつ、汎用サービスと特定サービスを混在させることができる。

図２９は、汎用サービスと特定サービスが混在した通信システムの一例を示す図である。図２９の通信システムには、サービス事業者Ａの路側機２０Ａ１、路側機２０Ａ２、サービス事業者Ｂの路側機２０Ｂ１、路側機２０Ｂ２、汎用車載機１０Ａ、特定車載機１０Ｂが含まれる。サービス事業者Ａの路側機２０Ａ１、路側機２０Ａ２の鍵テーブルには、路車間マスタ鍵Ａと路路間マスタ鍵Ａが格納されている。路車間マスタ鍵Ａは、路車間汎用サービスの路車間通信で使用されるマスタ鍵であり、全ての車載機１０（汎用車載機１０Ａ、特定車載機１０Ｂ）の鍵テーブルに事前に格納されている。路路間マスタ鍵Ａは、サービス事業者Ａの路側機間通信で使用されるマスタ鍵である。

サービス事業者Ｂの路側機２０Ｂ１の鍵テーブルには、路車間マスタ鍵Ｂと路路間マスタ鍵Ｂが格納されている。サービス事業者Ｂの路側機２０Ｂ２の鍵テーブルには、路車間マスタ鍵Ｂ、路車間マスタ鍵ｂと路路間マスタ鍵Ｂが格納されている。路車間マスタ鍵Ｂは、路車間汎用サービスの路車間通信で使用されるマスタ鍵であり、全ての車載機１０（汎用車載機１０Ａ、特定車載機１０Ｂ）の鍵テーブルに事前に格納されている。路車間マスタ鍵ｂは、路車間特定サービスの路車間通信で使用されるマスタ鍵であり、特定車載機１０Ｂの鍵テーブルにのみ格納されている。路路間マスタ鍵Ｂは、サービス事業者Ｂの路側機間通信で使用されるマスタ鍵である。

汎用車載機１０Ａの鍵テーブルには、路車間マスタ鍵Ａと路車間マスタ鍵Ｂが格納されている。特定車載機１０Ｂの鍵テーブルには、路車間マスタ鍵Ａ、路車間マスタ鍵Ｂ、路車間マスタ鍵ｂが格納されている。特定車載機１０Ｂのユーザは、サービス事業者Ｂと特定サービスを契約しており、特定車載機１０Ｂはサービス事業者Ｂの路側機２０Ｂ２から報知された特定サービスのパケット信号を受信して解読できる。汎用車載機１０Ａは、このパケット信号を解読できない。

図３０（ａ）−（ｄ）は、路側機２０Ａ１における送信処理の各レイヤにおける処理の概要を示す（その１）。なお、路側機２０Ａ１における送信処理のレイヤ構成は図２２（ａ）と基本的に同じである。図３０（ａ）は、分割処理層に入力されるアプリケーションデータを示す。アプリケーションデータＡＰＰ３、アプリケーションデータＡＰＰ１、アプリケーションデータＡＰＰ２の順に入力される。アプリケーションデータＡＰＰ３は特定サービスのアプリケーションデータであり、アプリケーションデータＡＰＰ１、アプリケーションデータＡＰＰ２は汎用サービスのアプリケーションデータである。

分割処理層は、汎用サービスのアプリケーションが先頭にくるよう並び替える。図３０（ａ）では、アプリケーションデータＡＰＰ１、アプリケーションデータＡＰＰ２、アプリケーションデータＡＰＰ３の順に並び替える。図３０（ｂ）は、並び替えられたアプリケーションデータを示す。

セキュリティ層は、並び替えられたアプリケーションデータに対してセキュリティ処理を実行する。具体的には各アプリケーションデータの前にセキュリティヘッダＳＨを付加し、その後にセキュリティフッタＳＦを付加する。アプリケーションデータＡＰＰ１、アプリケーションデータＡＰＰ２は路車間マスタ鍵Ａを用いて署名生成、ＭＡＣ生成、暗号化がなされ、アプリケーションデータＡＰＰ３は路路間マスタ鍵Ａを用いて署名生成、ＭＡＣ生成、暗号化がなされる。

図３０（ｃ）は、セキュリティ処理がなされたアプリケーションデータを示す。分割処理層は、セキュリティ処理がなされたアプリケーションデータを、サイズに応じて分割する。図３０（ｄ）は、分割されたアプリケーションデータを示す。図３０（ｄ）では、アプリケーションデータＡＰＰ１を５つに分割している。分割処理層は、分割したデータのそれぞれにＥＬヘッダを付加する。無線送信層は、各データをパケット信号に格納し、パケット信号を報知する。

図３１（ａ）−（ｃ）は、路側機２０Ａ２における受信処理の各レイヤにおける処理の概要を示す。なお、路側機２０Ａ２における受信処理のレイヤ構成は図２２（ｂ）と基本的に同じである。図３１（ａ）は、無線受信層で受信されたデータを示す。分割処理層は、分割されているデータを併合する。図３１（ｂ）は、併合されたアプリケーションデータを示す。分割処理層は、併合する際に各データに付加されたＥＬヘッダを除去する。

セキュリティ層は、各アプリケーションデータのセキュリティヘッダＳＨとセキュリティフッタＳＦに格納された情報を用いて、暗号化部分の復号、署名検証、ハッシュ一致検証、ＭＡＣ検証を実行する。路側機２０Ａ２は、路車間マスタ鍵Ａも路路間マスタ鍵Ａも保持しているため、アプリケーションデータＡＰＰ１、アプリケーションデータＡＰＰ２、アプリケーションＡＡＰ３を全て解読できる。図３１（ｃ）は、解読されたアプリケーションデータを示す。

図３２（ａ）−（ｃ）は、汎用車載機１０Ａにおける受信処理の各レイヤにおける処理の概要を示す。なお、汎用車載機１０Ａにおける受信処理のレイヤ構成は図２２（ｂ）と基本的に同じである。図３２（ａ）は、無線受信層で受信されたデータを示す。分割処理層は、分割されているデータを併合する。図３２（ｂ）は、併合されたアプリケーションデータを示す。分割処理層は、併合する際に各データに付加されたＥＬヘッダを除去する。

セキュリティ層は、各アプリケーションデータのセキュリティヘッダＳＨとセキュリティフッタＳＦに格納された情報を用いて、暗号化部分の復号、署名検証、ハッシュ一致検証、ＭＡＣ検証を実行する。汎用車載機１０Ａは、路車間マスタ鍵Ａは保持しているが、路路間マスタ鍵Ａは保持していない。したがって、アプリケーションデータＡＰＰ１、アプリケーションデータＡＰＰ２は解読できるが、アプリケーションＡＡＰ３は解読できない。アプリケーションＡＡＰ３は路路間マスタ鍵Ａを用いて生成された通信鍵で暗号化されているため、路路間マスタ鍵Ａを保持しない汎用車載機１０Ａは、アプリケーションＡＡＰ３を復号できない。

ここで、図３０（ａ）−（ｄ）の処理でアプリケーションデータの並び替えが行われなかった場合について考えると、汎用車載機１０Ａが受信する順番は、アプリケーションＡＡＰ３、アプリケーションＡＡＰ１、アプリケーションＡＡＰ２となる。前述したように汎用車載機１０Ａは、アプリケーションＡＡＰ３を解読できない。アプリケーションＡＡＰ３のセキュリティヘッダＳＨ３には、アプリケーションＡＡＰ１、アプリケーションＡＡＰ２からそれぞれ導出されたハッシュ値を含むハッシュリストがセットされている。このハッシュリストを復号できないため、アプリケーションＡＡＰ１、アプリケーションＡＡＰ２の復号はできても、ハッシュ一致検証ができない。従って、アプリケーションＡＡＰ１、アプリケーションＡＡＰ２の真正性が確認できない。

このように特定サービスのアプリケーションデータが先頭メッセージに配置されると、特定サービスに対応していない機器では、そのアプリケーションデータだけでなく、同一コンテナ内の後続する全てのアプリケーションデータも検証できなくなる。これに対して、汎用サービスのアプリケーションデータを先頭メッセージに配置すると、同一コンテナ内の後続する全てのアプリケーションデータが検証不能になる事態を回避できる。同様の効果は、先頭のアプリケーションデータを空にし、汎用サービスで使用するマスタ鍵を用いてセキュリティ処理することでも実現できる。

図３３（ａ）−（ｄ）は、路側機２０Ａ１における送信処理の各レイヤにおける処理の概要を示す（その２）。図３３（ａ）−（ｂ）は、図３０（ａ）−（ｂ）と同じである。セキュリティ層は、並び替えられたアプリケーションデータに対してセキュリティ処理を実行する。その際、先頭メッセージのアプリケーションを空に設定し、汎用サービスで使用されるマスタ鍵（この例では路車間マスタ鍵Ａ）を使用してセキュリティヘッダＳＨ１、セキュリティフッタＳＦ１を生成し、空のアプリケーションの前後に付加する。

図３３（ｃ）は、セキュリティ処理がなされたアプリケーションデータを示す。分割処理層は、セキュリティ処理がなされたアプリケーションデータを、サイズに応じて分割する。図３３（ｄ）は、分割されたアプリケーションデータを示す。図３３（ｄ）では、アプリケーションデータＡＰＰ１を４つに分割し、アプリケーションデータＡＰＰ３を２つに分割している。分割処理層は、分割したデータのそれぞれにＥＬヘッダを付加する。無線送信層は、各データをパケット信号に格納し、パケット信号を報知する。

これまで、基地局装置２０および端末装置１０から報知されるパケット信号を受信した別の基地局装置２０および端末装置１０は、パケット信号から取り出した路車間メッセージのコンテナの先頭路車間メッセージに対する署名検証を、原則的に、すべて実行することを前提としていた。しかしながら、スーパーフレーム期間に受信するパケット信号に含まれるコンテナ（路車間メッセージの署名検証およびハッシュリストの管理単位）の数が増加すると、処理負荷が大きい署名検証では、処理遅延の増加によってスーパーフレーム期間内に処理が終了しないようなケースが発生する。例えば図２において、スーパーフレームを構成するサブフレームの数を８、各サブフレームを一台の基地局装置２０が占有し、それぞれの基地局装置２０が２つのコンテナに帰属する路車間メッセージを送信すると、受信先では、最大１６回の署名検証を行わなければならなくなる。１スーパーフレーム期間に２回の署名検証を行う処理能力しかない場合、すべてのコンテナの先頭メッセージに対する署名検証は実行できないこととなる。すべてのコンテナの先頭メッセージに対する署名検証が実行できる処理能力を持たせることも考えられるが、１スーパーフレーム期間に１６回の署名検証を実行するためには、非常に高速なＣＰＵ或いは大規模な専用回路を必要とする。これにより、コストの上昇、署名検証処理の上限を一意に決められないなどの問題が発生する。

このような問題を回避するために、同一基地局装置２０からのパケット信号がスーパーフレーム周期で送信される特性から、署名検証を間引くことが考えられる。過去の同一基地局装置２０からの路車間メッセージ（署名者ＩＤが同じである路車間メッセージ）の署名検証結果と、ハッシュリストとハッシュ値の一致の確認と、ＭＡＣ検証結果とによって、署名検証を間引いたコンテナ内の路車間メッセージの検証結果とする認証方式が考えられる。同一基地局装置２０からの過去の署名検証結果によって、発信元の基地局装置２０の真正性を、ハッシュリストとハッシュ値の一致の確認によってコンテナの構成の正当性確認を、ＭＡＣ検証によってメッセージの真正性と改ざんの確認を行うこととなる。

図３４は、図２７のメッセージを路車間メッセージとして、図６のメッセージを車車間メッセージとして受信するときの、図１１の検証部１１５１における処理を示すフローチャートである。

図１１の検証部１１５１の署名検証部１１５１ｂは、１スーパーフレーム期間に２回の署名検証を行う能力を有し、最大２つの「署名検証リクエスト」を受け付ける。また、署名検証結果を公開鍵証明書に含まれる署名者ＩＤ（例えば、シリアル番号）と、メッセージのフレームＩＤとともにダイジェスト保持部１１５１ｃに退避する。この時、ダイジェスト保持部１１５１ｃに同じ署名者ＩＤに対する署名検証結果が既に退避されているときは、その退避されている署名検証を書き換える。これによって、署名者ＩＤによって識別される基地局装置２０から送信されたメッセージに対する最も新しい署名検証結果を得ることができるようになる。

ハッシュ比較部１１５１ａは、路車間メッセージに含まれるアプリケーションデータを少なくとも含むデータ列からハッシュ値を演算する。ハッシュ比較部１１５１ａは、「ハッシュ一致検証リクエスト」に対して演算したハッシュ値と、ダイジェスト保持部１１５１ｃに保持されるハッシュリスト内のハッシュ値とを比較し、その結果を報告する。

ＭＡＣ検証部１１５１ｄは、「ＭＡＣ検証リクエスト」に対して先頭の路車間メッセージ、後続の路車間メッセージ、および車車間メッセージに対する共通鍵暗号に係わる処理をする。メッセージに含まれる鍵ＩＤあるいは鍵情報から通信鍵を特定、抽出し、この通信鍵を用いてＭＡＣを求め、メッセージに含まれるＭＡＣと比較するＭＡＣ検証を実行し、結果を通知する。

判定部１１５１ｅは、メッセージの解釈、署名検証部１１５１ｂ、ハッシュ比較部１１５１ａ、ＭＡＣ検証部１１５１ｄへのリクエスト、および、メッセージからアプリケーションデータを抽出し、アプリケーションデータと署名検証部１１５１ｂ、ハッシュ比較部１１５１ａ、ＭＡＣ検証部１１５１ｄからの検証結果をまとめて外部に通知する。署名検証結果は、署名者ＩＤに基づいて、ダイジェスト保持部１１５１ｃより取得する。また、判定部１１５１ｅは、先頭の路車間メッセージに含まれる公開鍵証明書の署名者ＩＤとフレームＩＤ、ハッシュリストを紐付けして、ダイジェスト保持部１１５１ｃに退避する。なお、検証結果が失敗である場合、アプリケーションデータの通知をしないようにしてもよい。

以下、図３４のフローチャートを具体的に説明する。判定部１１５１ｅは、受信したメッセージがＭＡＣ付きデータであるか否か判定する（Ｓ２１）。ＭＡＣ付きデータである場合（Ｓ２１のＹ）、ＭＡＣ検証部１１５１ｄに「ＭＡＣ検証リクエスト」を発行する（Ｓ２２）。ＭＡＣ検証部１１５１ｄは、上記の図１３に示したフローチャートに示したＭＡＣ検証処理を実行する。

判定部１１５１ｅは、ＭＡＣ検証部１１５１ｄからＭＡＣ検証結果を受けると、ＭＡＣ検証が成功であったか失敗であったかを判定する（Ｓ２３）。成功の場合（Ｓ２３のＹ）、判定部１１５１ｅは、受信したメッセージが、先頭の路車間メッセージか、後続の路車間メッセージであるか、車車間メッセージであるかを判定する（Ｓ２４）。受信したメッセージが、先頭の路車間メッセージである場合（Ｓ２４のＮ）、判定部１１５１ｅは、当該メッセージに含まれるハッシュリストに、署名者ＩＤ（例えば、公開鍵証明書のシリアル番号）及びフレームＩＤを紐付けして、ダイジェスト保持部１１５１ｃに退避する（Ｓ２５）。判定部１１５１ｅは、当該メッセージが署名検証対象であるか否かを判定する（Ｓ２６）。この判定方法の具体例は後述する。

当該メッセージが署名検証対象である場合（Ｓ２６のＹ）、判定部１１５１ｅは、署名検証部１１５１ｂに「署名検証リクエスト」を発行する（Ｓ２７）。当該メッセージが署名検証対象でない場合（Ｓ２６のＮ）、「署名検証リクエスト」は発行されない。

図３５は、図３４の署名検証のサブルーチンを示すフローチャートである。このフローチャートに示す処理では、パラメータとしてＳｔａｔｅ、Ｅｎｔｒｙの２つを使用する。署名検証部１１５１ｂは複数バンクで構成される。バンク数はＥｎｔｒｙの最大数に設定される。本実施例ではＥｎｔｒｙの最大数が２で、署名検証部１１５１ｂは２バンクで構成される。すなわち、同時に２つの署名検証のリクエストを受け付け、Ｅｎｔｒｙによって管理される。また、署名検証部１１５１ｂの署名検証のリクエストを受け付けるリクエストスレッドと、署名検証処理を実行する処理スレッドは並列に動作する。なお図３５のステップＳ７１０、ステップＳ７１２の記号は、ステップＳ７２などの記号と同様に判断を示すものとする。以後のフローチャートについても同様である。

Ｓｔａｔｅの初期値としてｒｅａｄｙを設定し、Ｅｎｔｒｙの初期化として０を設定する（Ｓ７１）。判定部１１５１ｅから「署名検証リクエスト」が発行されると（Ｓ７２のＹ）、署名検証部１１５１ｂのリクエストスレッドは、Ｅｎｔｒｙをインクリメントする（Ｓ７３）。Ｅｎｔｒｙが最大値の２の場合（Ｓ７４のＹ）、Ｓｔａｔｅにｂｕｓｙを設定する（Ｓ７５）。Ｅｎｔｒｙが２以下の場合（Ｓ７４のＮ）、ステップＳ７２に遷移し、リクエスト待ち状態になる。Ｓｔａｔｅにｂｕｓｙを設定した後、Ｅｎｔｒｙを監視し（Ｓ７６）、Ｅｎｔｒｙが２以外になると（Ｓ７６のＮ）、Ｓｔａｔｅにｒｅａｄｙを設定し（Ｓ７７）、ステップＳ７２に遷移し、リクエスト待ち状態になる。

Ｅｎｔｒｙがゼロより大きい場合（Ｓ７８のＹ）、署名検証部１１５１ｂの処理スレッドは、受信したメッセージの公開鍵証明書のハッシュを演算し（Ｓ７９）、公開鍵証明書の署名を検証する（Ｓ７１０）。公開鍵証明書の署名検証に成功すると（Ｓ７１０のＹ）、署名検証部１１５１ｂの処理スレッドは、受信したメッセージのハッシュリストのハッシュを演算し（Ｓ７１１）、ハッシュリストの署名を検証する（Ｓ７１２）。ハッシュリストの署名検証に成功すると（Ｓ７１２のＹ）、「署名検証リクエスト」に係るメッセージの署名検証成功をダイジェスト保持部１１５１ｃに退避する（Ｓ７１３）。

公開鍵証明書の署名検証に失敗した場合（Ｓ７１０のＮ）、またはハッシュリストの署名検証に失敗した場合（Ｓ７１２のＮ）、「署名検証リクエスト」に係るメッセージの署名検証失敗をダイジェスト保持部１１５１ｃに退避する（Ｓ７１４）。署名検証結果の退避が終了すると、Ｅｎｔｒｙをデクリメントし（Ｓ７１５）、ステップＳ７８に遷移する。Ｅｎｔｒｙがゼロの間（Ｓ７８のＮ）、処理待ち状態となり、Ｅｎｔｒｙが１又は２の場合（Ｓ７８のＹ）、ステップＳ７９以降の処理を実行する。

図３４に戻る。ステップＳ２４にて受信したメッセージが後続の路車間メッセージである場合（Ｓ２４のＹ）、又は先頭の路車間メッセージであり（Ｓ２４のＮ）、署名検証に関する処理（Ｓ２５〜Ｓ２７）が終了した後、判定部１１５１ｅは、ハッシュ比較部１１５１ａに「ハッシュ一致検証リクエスト」を発行する（Ｓ２８）。ハッシュ比較部１１５１ａは、上記の図１５に示したフローチャートに示したハッシュ比較処理を実行する。

判定部１１５１ｅは、受信したメッセージに含まれる署名者ＩＤに基づき、ダイジェスト保持部１１５１ｃから当該署名者ＩＤを持つメッセージの署名検証結果を取得する（Ｓ２９）。署名検証結果を取得するとステップＳ３１に遷移する。ステップＳ２１にて、受信したメッセージがＭＡＣ付きデータでない場合（Ｓ２１のＮ）、対象外通知を生成して（Ｓ３０）、ステップＳ３１に遷移する。またステップＳ２３にて、ＭＡＣ検証が失敗であった場合（Ｓ２３のＮ）、ステップＳ２４にて、受信したメッセージが車車間メッセージである場合（Ｓ２１のＢ）もステップＳ３１に遷移する。

判定部１１５１ｅは、受信したメッセージからアプリケーションデータを抽出する（Ｓ３１）。判定部１１５１ｅは、抽出したアプリケーションデータと、各種の検証結果を受信処理部１６１に通知する（Ｓ３２）。

図３６は、図３４の署名検証対象の判定方法の一例を示すフローチャートである。以下に説明する判定方法では、順位管理リストと候補リストを使用する。順位管理リストは、署名者ＩＤ、優先順位、受信マークの３つの項目を有する。優先順位（優先レベル）の段階は、（路車間サブフレームの最大数／スーパーフレーム期間の検証回数×２）以上に設定される。路車間サブフレームの最大数は、同時受信する基地局装置２０の最大数に設定される。優先順位の初期値は中間値に設定される。

順位管理リストのサイズは、路車間サブフレームの最大数に設定される。受信マークは、スーパーフレーム期間における初回受信でセット、スーパーフレーム期間の先頭でクリアされるパラメータである。

候補リストは、順位管理リストでのエントリと、スーパーフレーム周期で優先順位が最も高いものによるエントリの２つを有する。候補リストのサイズは、スーパーフレーム期間に処理できる最大数に設定される。

以下、図３６のフローチャートを具体的に説明する。判定部１１５１ｅは、順位管理リストを初期値する（Ｓ６１）。判定部１１５１ｅは、受信したメッセージがスーパーフレーム期間の先頭であるか否か判定する（Ｓ６２）。先頭の場合（Ｓ６２のＹ）、判定部１１５１ｅは、その時点で最も優先順位が高い署名者ＩＤを署名検証候補として候補リストに登録する（Ｓ６３）。判定部１１５１ｅは、一つ前のスーパーフレーム期間に受信が無かった署名者ＩＤに対する優先順位を１つ下げ（Ｓ６４）、当該署名者ＩＤの受信マークをクリアする（Ｓ６５）。ステップＳ６２にて、受信したメッセージがスーパーフレーム期間の先頭でない場合（Ｓ６２のＮ）、ステップＳ６３〜Ｓ６５をスキップする。

次に判定部１１５１ｅは、受信したメッセージが、ステップＳ６７以降の判定処理を実行すべき先頭の路車間メッセージであるか否か判定する（Ｓ６６）。先頭の路車間メッセージではなく後続の路車間メッセージ又は車車間メッセージである場合（Ｓ６６のＮ）、ステップＳ６２に遷移し、ステップＳ６２以降の処理を繰り返す。先頭の路車間メッセージである場合（Ｓ６６のＹ）、判定部１１５１ｅは、当該メッセージに含まれる署名者ＩＤが順位管理リストに登録されているか否か判定する（Ｓ６７）。登録されていない場合（Ｓ６７のＮ）、順位管理リストに空きエントリが存在するか否か判定する（Ｓ６８）。

空きエントリが存在する場合（Ｓ６８のＹ）、判定部１１５１ｅは当該署名者ＩＤを、空きエントリに、当該署名者ＩＤの優先順位は中間値に設定して登録する（Ｓ６９）。空きエントリが存在しない場合（Ｓ６８のＮ）、判定部１１５１ｅは当該署名者ＩＤを、その時点で最も優先順位が低いエントリに、当該署名者ＩＤの優先順位は中間値に設定して上書き登録する（Ｓ６１０）。当該署名者ＩＤが順位管理リストに新たに登録された後、当該署名者ＩＤに対する受信マークをセットし(ステップＳ６１７)、ステップＳ６１５に遷移する。

ステップＳ６７にて、受信したメッセージに含まれる署名者ＩＤが順位管理リストに登録されている場合（Ｓ６７のＹ）、判定部１１５１ｅは、当該署名者ＩＤに対する受信マークがセットされているか否か判定する（Ｓ６１１）。セットされていない場合（Ｓ６１１のＮ）、判定部１１５１ｅは、当該署名者ＩＤに対する優先順位を１つ上げ（Ｓ６１２）、当該署名者ＩＤに対する受信マークをセットする（Ｓ６１３）。次に判定部１１５１ｅは、当該署名者ＩＤが候補リストに登録されているか否か判定する（Ｓ６１４）。登録されている場合（Ｓ６１４のＹ）、ステップＳ６１５に遷移する。登録されていない場合（Ｓ６１４のＮ）、当該署名者ＩＤを含む受信したメッセージを署名検証対象外と判定する（Ｓ６１９）。その後、ステップＳ６２に遷移し、ステップＳ６２以降の処理を繰り返す。

ステップＳ６１１にて、当該署名者ＩＤに対する受信マークがセットされている場合（Ｓ６１１のＹ）、ステップＳ６１２〜Ｓ６１４をスキップし、当該署名者ＩＤを含む受信したメッセージを署名検証対象外と判定する（Ｓ６１９）。その後、ステップＳ６２に遷移し、ステップＳ６２以降の処理を繰り返す。

ステップＳ６１５では判定部１１５１ｅは、署名検証部１１５１ｂのＳｔａｔｅがｒｅａｄｙであるか否か確認する。Ｓｔａｔｅがｒｅａｄｙではなくｂｕｓｙの場合（Ｓ６１５のＮ）、当該署名者ＩＤを含む受信したメッセージを署名検証対象外と判定する（Ｓ６１９）。その後、ステップＳ６２に遷移し、ステップＳ６２以降の処理を繰り返す。

ステップＳ６１５にてＳｔａｔｅがｒｅａｄｙの場合（Ｓ６１５のＹ）、当該署名者ＩＤに対する優先順位を中間値に設定する（Ｓ６１６）。判定部１１５１ｅは、当該署名者ＩＤを含む受信したメッセージを署名検証対象と判定する（Ｓ６１８）。その後、ステップＳ６２に遷移し、ステップＳ６２以降の処理を繰り返す。

ステップＳ６９およびステップＳ６１０では、優先順位を中間値に設定するとしたが、優先順位を最も高く設定するようにしてもよい。優先順位を最も高く設定することで、当該基地局装置２０から初めて路車間メッセージを受信したスーパーフレームあるいはその後のより直近のスーパーフレームで署名検証が行われるようになる。

図３７は、図３４の署名検証対象の判定方法の別の例を示すフローチャートである。この例では、候補リストを使用せずに順位管理リストのみを使用する。以下、図３６のフローチャートとの相違点を説明する。図３７のフローチャートでは、ステップＳ６３及びステップＳ６１４が省略される。またステップＳ６７のＹとステップＳ６１１の間に、ステップＳ６１０５が挿入され、ステップＳ６１７が、テップＳ６１６とステップＳ６１８の間に移動する。

ステップＳ６１０５では判定部１１５１ｅは、受信したメッセージに含まれる署名者ＩＤが、順位管理リスト内で上位２位以内か否か判定する。上位２位以内であれば（Ｓ６１０５のＹ）、ステップＳ６１５に遷移し、上位２位以内でなければ（Ｓ６１０５のＮ）、ステップＳ６１１に遷移する。

図３７のフローチャートでは、１つの基地局装置２０から複数のコンテナを受信する場合にスーパーフレーム期間で最初に受信したコンテナの先頭の路車間メッセージを受信したときに署名検証がｂｕｓｙであった場合、その後受信したコンテナの先頭の路車間メッセージに対して署名検証の機会を与えられるようになる。また、図３６のフローチャートと同様に、ステップＳ６９およびステップＳ６１０では、優先順位を中間値に設定するとしたが、優先順位を最も高く設定するようにしてもよい。優先順位を最も高く設定することで、当該基地局装置２０から初めて路車間メッセージを受信したスーパーフレームあるいはその後のより直近のスーパーフレームで署名検証が行われるようになる。

さらに、図３６および図３７のフローチャートにおいて公開鍵証明書の検証を間引くようにしてもよい。すなわち、署名検証が実施され、かつ、署名検証に成功した公開鍵証明書を、あるいは公開鍵証明書の識別情報、公開鍵等を記録しておき、受信したメッセージに含まれる公開鍵証明書が、それと一致すると判断される場合、公開鍵証明書の署名検証を間引く。

以上のように、署名検証を間引くことによって、署名検証処理の負荷を軽減し、コストダウンを図ることができる。また、スーパーフレーム期間に送信されるコンテナの数に上限を定める必要がない。図３４〜図３７のフローチャートに従えば、基地局装置２０から始めて受信したパケット信号に含まれるコンテナ、すなわち、コンテナを送信した送信元の基地局装置２０からのコンテナに対する署名検証結果を保持しない場合、そのコンテナの署名検証を優先的に実行する。また、パケット信号を受信したことのある基地局装置２０からのパケット信号に含まれるコンテナ、すなわち、コンテナを送信した送信元の基地局装置２０からのコンテナに対する署名検証結果を保持しない場合、基地局装置２０ごとに均等に署名検証を実施することができる。

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

なお、本実施の形態に係る発明は、以下に記載する項目によって特定されてもよい。

［項目１］
発信元固有の公開鍵証明書、代表値リスト、アプリケーションデータ、前記公開鍵証明書に含まれる公開鍵で検証可能な署名、共通鍵暗号方式によるメッセージ認証コードが付加された第１パケット信号、及び発信元固有の公開鍵証明書のダイジェスト、アプリケーションデータ、共通鍵暗号方式によるメッセージ認証コードが付加された第２パケット信号を、他の無線装置から受信する受信部と、
前記第１パケット信号に含まれる公開鍵証明書の署名および前記第１パケット信号に含まれる前記代表値リストを少なくとも含むデータ列から生成された署名を検証するための第１検証部と、
前記第１パケット信号または前記第２パケット信号に含まれるメッセージ認証コードを検証するための第２検証部と、
前記第２パケット信号に含まれるアプリケーションデータを少なくとも含むデータ列から演算された代表値と、前記代表値リスト内に含まれている、前記第２パケット信号に含まれるアプリケーションデータを少なくとも含む予め演算されたデータ列の代表値とを比較する比較部と、
前記第１検証部による署名の検証結果、前記第２検証部によるメッセージ認証コードの検証結果、前記比較部による比較結果をもとに、前記アプリケーションデータにより構成されるメッセージを承認するか否か判定する判定部と、
を備えることを特徴とする無線装置。

［項目２］
前記第１パケット信号に含まれる代表値リストを一時保持するための保持部をさらに備え、
前記第１検証部は、前記第１パケット信号に含まれる代表値リストを前記保持部に格納し、
前記第２検証部は、前記保持部に保持される代表値リスト内の代表値と、前記第２パケット信号に含まれるアプリケーションデータを少なくとも含むデータ列から演算された代表値とを比較することを特徴とする項目１に記載の無線装置。

［項目３］
前記第１検証部は、前記第１パケット信号に含まれる公開鍵証明書のダイジェストを生成して前記保持部に格納し、
前記第１検証部は、前記保持部に保持される公開鍵証明書のダイジェストと、受信した第１パケット信号に含まれる公開鍵証明書から生成した公開鍵証明書のダイジェストとが一致する場合、当該第１パケット信号に含まれる公開鍵証明書の署名検証成功と判定することを特徴とする項目２に記載の無線装置。

［項目４］
アプリケーションデータと発信元固有の公開鍵証明書と前記公開鍵証明書に含まれる公開鍵で検証可能な署名と共通鍵暗号方式によるメッセージ認証子を含む第１のメッセージと、アプリケーションデータと発信元を特定する情報と共通鍵暗号方式によるメッセージ認証子を含む１つ以上の第２のメッセージとを生成し、
前記第１のメッセージおよび１つ以上の前記第２のメッセージを１つのグループとして送信する無線装置であって、
１つ以上の全ての無線装置での受信が許可されるサービスに属するアプリケーションデータと、１つ以上の特定の無線装置のみが受信が許可されるサービスに属するアプリケーションデータを受け取り、
前記第１のメッセージは、自身のアプリケーションデータおよび１つ以上の前記第２のメッセージにそれぞれ含まれるアプリケーションデータに対するダイジェストあるいはメッセージ認証子を含む認証用リストを含み、前記署名は前記認証用リストに対する署名であり、
前記第１のメッセージに含まれる前記アプリケーションデータは、受け取った全ての無線装置での受信が許可されるサービスに属するアプリケーションデータの１つであり、
前記第２のメッセージの前記メッセージ認証子は、当該メッセージに含まれる前記公開鍵証明書の特定情報と前記アプリケーションデータに対するものであり、
前記第２のメッセージに含まれる前記アプリケーションデータは、受け取った全ての無線装置での受信が許可されるサービスに属するアプリケーションデータあるいは特定の無線装置のみが受信が許可されるアプリケーションデータの内の１つであることを特徴とする無線装置。

［項目５］
当該メッセージに含まれる前記アプリケーションデータのサービスに固有の共通鍵の中から１つを選択し、選択した共通鍵を前記メッセージ認証子の生成に用いる通信鍵とし、前記通信鍵を用いて前記メッセージ認証子を生成することを特徴とする項目４に記載の無線装置。

［項目６］
前記メッセージ認証子の生成に用いる通信鍵を乱数生成し、前記通信鍵を用いて前記メッセージ認証子を生成し、
当該メッセージに含まれる前記アプリケーションデータのサービスに固有の共通鍵の中から１つを選択し、選択した共通鍵を用いて暗号化した前記通信鍵を当該メッセージに含めることを特徴とする項目４に記載の無線装置。

［項目７］
前記第１のメッセージに含まれる前記公開鍵証明書と前記認証用リストと前記署名と前記アプリケーションデータと前記メッセージ認証子とを前記メッセージ認証子の生成に用いた前記通信鍵を用いて暗号化して、送信することを特徴とする項目５または６に記載の無線装置。

［項目８］
一部あるいは全ての前記第２のメッセージに含まれる前記公開鍵証明書の特定情報と前記アプリケーションデータとを前記メッセージ認証子の生成に用いた前記通信鍵を用いて暗号化して、送信することを特徴とする項目５から７のいずれかに記載の無線装置。

［項目９］
前記第１のメッセージおよび前記第２のメッセージを、１つ以上のパケット信号に分割して、送信することを特徴とする項目４から８のいずれかに記載の無線装置。

［項目１０］
前記第１のメッセージは前記アプリケーションデータのバイト数が０であることを特徴とする項目４から８のいずれかに記載の無線装置。

１０ 端末装置、 １１ アンテナ、 １２ ＲＦ部、 １３ 変復調部、 １４ ＭＡＣフレーム処理部、 １５ セキュリティ処理部、 １１５１ 検証部、 １１５２ 復号部、 １１５３ 記憶部、 １７ データ生成部、 １８ 記憶部、 １９ 制御部、 ２０ 基地局装置、 ２１ アンテナ、 ２２ ＲＦ部、 ２３ 変復調部、 ２４ ＭＡＣフレーム処理部、 ２５ セキュリティ処理部、 １２５１ 署名部、 １２５２ 暗号部、 １２５３ 記憶部、 ２６ データ生成部、 ２７ ネットワーク通信部、 ２８ 記憶部、 ２９ 制御部、 １００ 車両、 １６１ 受信処理部、 １６２ 通知部、 ２００ 外部ネットワーク、 ２０２ エリア、 ２０４ エリア外、 ５００ 通信システム。

Claims (2)

1. 発信元固有の公開鍵証明書、代表値リスト、アプリケーションデータ、前記公開鍵証明書に含まれる公開鍵で検証可能な署名、共通鍵暗号方式によるメッセージ認証コードが付加された第１パケット信号、及び発信元固有の公開鍵証明書の識別情報、アプリケーションデータ、共通鍵暗号方式によるメッセージ認証コードが付加された第２パケット信号を、他の無線装置から受信する受信部と、
   前記第１パケット信号に含まれる公開鍵証明書の識別情報、及び前記代表値リストを一時保持するための保持部と、
   前記第１パケット信号に含まれる公開鍵証明書の署名および前記第１パケット信号に含まれる前記代表値リストを少なくとも含むデータ列から生成された署名を検証するための第１検証部と、
   前記第１パケット信号または前記第２パケット信号に含まれるメッセージ認証コードを検証するための第２検証部と、
   前記第２パケット信号に含まれるアプリケーションデータを少なくとも含むデータ列から演算された代表値と、前記代表値リスト内に含まれている代表値とを比較する比較部と、
   前記第１検証部による署名の検証結果、前記第２検証部によるメッセージ認証コードの検証結果、前記比較部による比較結果をもとに、前記アプリケーションデータにより構成されるメッセージを承認するか否か判定する判定部と、
   を備え、
   前記第１検証部は、前記第１パケット信号の署名検証に成功すると、前記第１パケット信号に含まれる公開鍵証明書の識別情報、及び前記代表値リストを前記保持部に格納し、
   前記比較部は、前記保持部に保持される代表値リスト内の代表値と、前記第２パケット信号に含まれるアプリケーションデータを少なくとも含むデータ列から演算された代表値とを比較することを特徴とする無線装置。
2. 前記第１検証部は、前記保持部に保持される公開鍵証明書の識別情報と、受信した第１パケット信号に含まれる公開鍵証明書から生成した公開鍵証明書の識別情報とが一致する場合、当該第１パケット信号に含まれる公開鍵証明書の署名検証成功と判定することを特徴とする請求項１に記載の無線装置。