JP6112467B2 - 通信装置 - Google Patents

Description

本発明は、通信技術に関し、特に共通鍵暗号方式によるセキュリティ処理を実行する通信装置に関する。

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

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

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

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

上記課題を解決するために、本発明のある態様の通信装置は、複数の共通鍵が含まれた部分共通鍵テーブルを複数結合することによって形成されるべき共通鍵テーブルを管理する管理部と、管理部において管理されている共通鍵テーブルのうち、いずれかの共通鍵を使用することによって、データに対するセキュリティ処理を実行する処理部と、処理部においてセキュリティ処理がなされたデータを送信あるいは受信する通信部とを備える。管理部は、共通鍵テーブルに新たな部分共通鍵テーブルを追加することによって、共通鍵テーブルを更新する。

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

本発明によれば、共通鍵暗号化方式を用いた通信システムのセキュリティを効率的に向上させることができる。

本発明の実施例１に係る通信システムの構成を示す図である。 図２（ａ）−（ｄ）は、通信システムにおいて規定されるスーパーフレームのフォーマットを示す図である。 図３（ａ）−（ｂ）は、サブフレームの構成を示す図である。 図４（ａ）−（ｆ）は、通信システムにおいて規定される各レイヤのフレームのフォーマットを示す図である。 図５（ａ）−（ｂ）は、セキュリティフレームのデータ構造の一例を示す図である。 セキュリティフレームのデータ構造の別の一例を示す図である。 基地局装置の構成を示す図である。 車両に搭載された端末装置の構成を示す図である。 本実施例に係る通信システムを用いた路車間通信における通常のメッセージ送受信手順を説明するための図である。 本実施例に係る通信システムを用いた路車間通信における路車間マスタ鍵の更新手順を説明するための図である。 本実施例に係る通信システムを用いた車車間通信における通常のメッセージ送受信手順を説明するための図である。 図１２（ａ）−（ｂ）は、共通鍵テーブルのフォーマットを示す図である。 共通鍵テーブルの運用方法の一例を示す図である。 図１４（ａ）−（ｂ）は、セキュリティフレームのデータ構造のさらに別の一例を示す図である。 本発明の実施例２に係る車車間通信パケット信号に含まれるセキュリティフレームのデータ構造の一例を示す図である。 メッセージ形式のデータ構造の一例を示す図である。 路車間通信パケット信号に含まれるセキュリティフレームのデータ構造の一例を示す図である。 フレーム認証リストのデータ構造の一例を示す図である。 端末装置おける路車間通信パケットの処理例を示す図である。 基地局装置の構成を示す図である。 車両に搭載された端末装置の構成を示す図である。 検証部の構成例を示す図である。 構成例に係るＲＳＵパケットの受信処理を示すフローチャートである。 構成例に係るＲＳＵパケットのＲＳＵ検証処理を示すフローチャートである。 構成例に係るＲＳＵパケットのＭＡＣ検証処理を示すフローチャートである。 車車間通信パケット信号に含まれるセキュリティフレームのデータ構造の一例を示す図である。 路車間通信パケット信号に含まれるセキュリティフレームのデータ構造の一例を示す図である。 検証部の構成例を示す図である。 構成例に係るＲＳＵパケットの受信処理を示すフローチャートである。 構成例に係るＲＳＵパケットのＲＳＵ検証処理を示すフローチャートである。 構成例に係るＲＳＵパケットのＭＡＣ検証処理を示すフローチャートである。 図３２（ａ）−（ｂ）は、図２０の基地局装置において規定されるレイヤの構成を示す図である。 図３３（ａ）−（ｅ）は、図３２の各レイヤにおける処理の概要を示す図である。 図３４（ａ）−（ｂ）は、本発明の実施例３に係る基地局装置において規定されるレイヤの構成を示す図である。 図３５（ａ）−（ｆ）は、図３４の各レイヤにおける処理の概要を示す図である。 図３６（ａ）−（ｆ）は、図３４の各レイヤにおける別の処理の概要を示す図である。 図３７（ａ）−（ｂ）は、本発明の実施例４に係る路車間通信パケット信号に含まれるセキュリティフレームのデータ構造の一例を示す図である。 本発明の実施例４に係る路車間通信パケット信号に含まれるセキュリティフレームのデータ構造の別の一例を示す図である。

（実施例１）
本発明の実施例の基礎となった知見は、次の通りである。なりすまし防止や秘匿性確保のための技術として暗号方式がある。暗号化方式には、大別すると公開鍵暗号化方式と共通鍵暗号化方式がある。前者では事前に送信元と受信先が鍵を共有する必要がないこと、送信元ごとに鍵を設定できることから後者よりセキュリティは高い。しかし、同じ暗号強度の場合、前者は後者に比べてデータ量が多く、かつ、処理負荷が大きいため実装コストが高くなる。すなわち、両者はトレードオフの関係にある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「乱数」は、パケット信号の送信時に送信元が発生した乱数がセットされる。すなわち、パケット信号の発信毎にユニークな値がセットされる。ここでは、「乱数」としているが、乱数に変えてメッセージの発信日時を示すセットする「日時情報」にしてもよい。この場合、日時情報はパケット信号の発信毎にユニークである必要があるため、スーパーフレームの周期よりも細かい分解能が要求される。但し、精度は要求されない。「ペイロード長」には、「ＭＡＣ方式ペイロード」のバイト数がセットされる。「アプリケーション」には、車車間アプリケーションデータがセットされる。図５（ａ）と同様に、ＭＡＣの演算対象は、「ＭＡＣ方式ヘッダ」の「Ｎｏｎｃｅ」と「ペイロード長」と「ＭＡＣ方式ペイロード」であり、暗号化の対象は、「ＭＡＣ方式ペイロード」と「ＭＡＣ方式フッタ」である。また、図５（ａ）−（ｂ）、図６のセキュリティフレームにおいて「アプリケーション」に先行して配置されるデータが、図４の「セキュリティヘッダ」に「アプリケーション」に続いて配置されるデータが、図４の「セキュリティフッタ」に相当する。また、以降では、ＭＡＣ方式ペイロードを単にペイロードとよぶものとする。

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

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

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

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

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

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

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

ネットワーク通信部２７は、外部ネットワーク２００に接続される。ネットワーク通信部２７は、外部ネットワーク２００から工事や渋滞等に関する道路情報を受けつける。また、ネットワーク通信部２７は、路車間通信用のマスタ鍵（以下、路車間マスタ鍵という）、暗号化更新鍵テーブルおよびテーブル更新鍵を受けつける。また、ネットワーク通信部２７は、セキュリティ処理部２５による処理結果を外部ネットワーク２００へ出力したり、記憶部２８に蓄積して、定期的に外部ネットワーク２００へ出力したりする。

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

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

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

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

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

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

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

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

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

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

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

記憶部１８は、種々の情報（例えば、路車間マスタ鍵、共通鍵テーブル、テーブル更新鍵）を記憶する。また、本実施例では基地局装置２０から取得される道路情報、自己または他の端末装置１０から取得される車両情報、ならびに基地局装置２０から取得される暗号化新しい路車間マスタ鍵、暗号化更新共通鍵テーブルおよび暗号化テーブル更新鍵を保持する。前述のごとく、共通鍵テーブルは、複数の部分共通鍵テーブルを複数結合することによって形成されている。また、部分共通鍵テーブルには、共通鍵暗号方式における共通鍵が複数含まれている。制御部１９は、端末装置１０全体の処理を制御する。

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

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

セキュリティ処理部１５は、受信処理として、ＭＡＣフレーム処理部１４からのセキュリティフレームを受け付ける。セキュリティ処理部１５は、セキュリティフレームのうちのセキュリティヘッダの内容を確認する。メッセージタイプが認証付きデータである場合、暗復号部１５１にてメッセージの検証処理を実行する。メッセージ形式が認証付き暗号化データである場合、暗復号部１５１にてメッセージの復号処理および検証処理を実行する。なお、メッセージ形式が平文である場合、これらの処理は省略される。つまり、メッセージタイプが認証付きデータまたはメッセージ形式が認証付き暗号化データである場合、セキュリティ処理部１５は、図５（ａ）−（ｂ）に示すセキュリティフレームを受け付けると、記憶部１８に保持されたマスタ鍵によってセキュリティヘッダの暗号化通信鍵を復号して通信鍵を取り出す。図６に示すセキュリティフレームを受け付けると、鍵ＩＤにしたがって、記憶部１８に保持された共通鍵のうち、セキュリティフレームに対して使用された共通鍵を通信鍵として取り出す。そして取り出した通信鍵によって、セキュリティ処理の送信処理とは逆の受信処理を実行する。すなわち、メッセージタイプが認証付きデータの場合、「ＭＡＣ方式ペイロード」に対するＭＡＣを生成し、「ＭＡＣ」の値と比較する。一致すればメッセージの完全性が確認される。また、メッセージタイプが認証付き暗号化データの場合、「ＭＡＣ方式ペイロード」および「ＭＡＣ方式フッタ」を復号し、複合語の「ＭＡＣ方式ペイロード」に対するＭＡＣを生成し、「ＭＡＣ」の値と比較する。一致すればメッセージの完全性が確認される。また、図５（ａ）に示すセキュリティフレームでは、「電子署名」の検証を行う。検証に成功すれば、メッセージの発信元の真正性が確認できる。図５（ｂ）に示すセキュリティフレームでは、「アプリケーション」のハッシュを演算し、同じグループの図５（ａ）に示すセキュリティフレームの「後続パケットの認証用ハッシュリスト」に含まれる自身に対するハッシュと比較する。同じグループの図５（ａ）に示すセキュリティフレームの署名検証に成功し、かつ、ハッシュ一致すれば、メッセージの発信元の真正性が確認される。セキュリティ処理の受信処理とは、メッセージの検証処理やメッセージの復号処理である。

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

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

鍵更新部１５３は、自己（端末装置１０）が保持すべき路車間マスタ鍵の更新処理および車車間通信用の共通鍵テーブルの更新処理を行う。前述のごとく、共通鍵テーブルは、複数の部分共通鍵テーブルによって形成されている。ここで、共通鍵テーブルを形成するために結合可能な部分共通テーブル数は予め定められている。鍵更新部１５３は、共通鍵テーブルに新たな部分共通鍵テーブルを追加することによって、共通鍵テーブルを更新する。

具体的に説明すると、結合可能な部分共通鍵テーブル数に達するまで、鍵更新部１５３は、共通鍵テーブルの更新のために、新たな部分共通鍵テーブルを追加する。そのため、共通鍵テーブルに含まれる共通鍵数は増加する。一方、結合可能な部分共通鍵テーブル数に達してから、鍵更新部１５３は、共通鍵テーブルの更新のために、共通鍵テーブルに既に含まれた部分共通鍵テーブルを新たな部分共通鍵テーブルによって置き換える。そのため、共通鍵テーブルに含まれる共通鍵数は一定である。なお、鍵更新部２５３においても、共通鍵テーブルは同様に更新される。

セキュリティ処理部１５が、検証や復号を実行する際、メッセージ認証コードの生成や暗号化に通信鍵として使用された共通鍵を含め部分共通鍵テーブルを記憶部１８に保持していない場合、その旨を鍵更新部１５３に出力する。鍵更新部１５３は、その旨を通知部１６２に通知させる。例えば、通知部１６２は、最新の共通鍵に対応していないことをモニタに表示したり、音声として出力したりする。ランプの点灯、エラーメッセージの表示、問い合わせを促すメッセージの表示によって、通知がなされてもよい。これによって、運転者は、記憶部１８に保持される鍵テーブルに最新の部分共通鍵テーブルが含まれないこと、すなわち、現在の共通鍵が最新の共通鍵に対応していないこと認識する。さらに、マスタ鍵にも鍵ＩＤが付与されているので、マスタ鍵が記憶部１８に保持されていない場合、鍵更新部１５３は、その旨を通知する。周辺の端末装置１０や基地局装置２０が更新されることによって当該端末装置１０との鍵の共有がなされなくなった場合に、運転者への通知がなされる。鍵更新部１５３は、メッセージ認証コードの生成や暗号化に使用された共通鍵を記憶部１８に保持していない場合、基地局装置２０や他の端末装置１０に対して共通鍵の更新を要求する。これは、運転者からの指示によってなされてもよいし、自動的になされてもよい。

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

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

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

図１０は、本実施例に係る通信システム５００を用いた路車間通信における路車間マスタ鍵の更新手順を説明するための図である。図示しない装置において、更新用の新しい路車間マスタ鍵を生成する。この更新用の新しい路車間マスタ鍵は、定期的に生成されてもよいし、路車間マスタ鍵の漏洩が発覚した場合に生成されてもよいし、その両方であってもよい。基地局装置２０の鍵更新部２５３は、新しい路車間マスタ鍵を受けつけると、自己の路車間マスタ鍵を更新する。具体的には、現路車間マスタ鍵を、前路車間マスタ鍵として、受けつけた新しい路車間マスタ鍵を現路車間マスタ鍵として、記憶部２８に記録する。

そして、更新後の一定期間、現路車間マスタ鍵（受けつけた新しい路車間マスタ鍵）をパケット信号に格納して報知するように制御する。暗号部２５２は、現路車間マスタ鍵（受けつけた新しい路車間マスタ鍵）を前路車間マスタ鍵を用いて暗号化する。この暗号化には共通鍵暗号化方式が用いられてもよいし、公開鍵暗号化方式が用いられてもよい。暗号化された新しい路車間マスタ鍵は、パケット信号に格納されて報知される。

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

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

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

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

図１２（ａ）−（ｂ）は、共通鍵テーブルのフォーマットを示す。図１２（ａ）は、初期状態の共通鍵テーブルを示す。図示のごとく、テーブルＩＤ＝１のみに、Ｋ個の通信鍵が含まれる。Ｋ個の通信鍵のまとまりが、ひとつの部分共通鍵デーブルに相当する。図１２（ｂ）は、更新された状態の共通鍵テーブルを示す。図示のごとく、テーブルＩＤ＝１と２のふたつの部分共通鍵テーブルが含まれる。また、鍵テーブルには、Ｃｕｒｒｅｎｔ Ｔａｂｌｅ ＩＤには送信処理に利用する部分共通鍵テーブルのテーブルＩＤがセットされている。図１２（ａ）では、テーブルＩＤ＝１の部分共通鍵テーブルが、図１２（ｂ）では、テーブルＩＤ＝２の部分共通鍵テーブルから通信鍵として使用する共通鍵が選択される。

図１３は、共通鍵テーブルの運用方法の一例を示す。図１３では、共通鍵テーブルが、４つの部分共通鍵テーブルによって形成されているとする。初期状態（出荷時）には、端末装置１０にはひとつの部分共通鍵テーブル（バージョン＝１、テーブルＩＤ＝１）が、Ｃｕｒｒｅｎｔ Ｔａｂｌｅ ＩＤをテーブルＩＤ＝１が保持される。送信側の端末装置１０はこの部分共通鍵テーブル（バージョン＝１、テーブルＩＤ＝１）からひとつの通信鍵を選択して、ＭＡＣ生成および暗号化に使用する。なお、共通鍵テーブルを形成する部分共通鍵テーブルの数は４に限定されるものではない。また、初期状態（出荷時）に、端末装置１０に複数の部分共通鍵テーブルが保持されていても良い。

この部分共通鍵テーブル（バージョン＝１、テーブルＩＤ＝１）に対して、新たな部分共通鍵テーブル（バージョン＝２、テーブルＩＤ＝２）が追加され、Ｃｕｒｒｅｎｔ Ｔａｂｌｅ ＩＤをテーブルＩＤ＝２に変更される。送信側の端末装置１０はＣｕｒｒｅｎｔ Ｔａｂｌｅ ＩＤで示される最新の部分共通鍵テーブル（バージョン＝２、テーブルＩＤ＝２）からひとつの通信鍵を選択して、ＭＡＣ生成および暗号化に使用する。同様に、部分共通鍵テーブル（バージョン＝３、テーブルＩＤ＝３）、部分共通鍵テーブル（バージョン＝４、テーブルＩＤ＝４）の順に新たな部分共通鍵テーブルが追加される。

４つの部分共通鍵テーブルが端末装置１０に保持された後、共通鍵テーブルを更新する場合、一番古い部分共通鍵テーブル（バージョン＝１、テーブルＩＤ＝１）に、新たな部分共通鍵テーブル（バージョン＝５、テーブルＩＤ＝１）が上書き（更新）される。以下、この処理が繰り返される。なお、図１３において太線で囲われた部分共通鍵テーブルは、最新の部分共通鍵テーブルである。

本実施例の実施例によれば、共通鍵テーブルをまとめて更新するのではなく、部分共通鍵テーブルを追加するように更新するので、部分共通鍵テーブルの個別性を高めることができる。また、部分共通鍵テーブルの個別性が高められるので、一部の部分共通鍵テーブルが漏洩した場合であっても、共通鍵テーブルの全体が漏洩する可能性を低減できる。また、共通鍵テーブルの全体が漏洩する可能性が低減されるので、通信システムの安全性を向上できる。また、共通鍵テーブルをまとめて更新するのではなく、部分共通鍵テーブルを追加するように更新するので、更新時のデータ量を低減できる。

また、共通鍵テーブルのサイズを超えるまでは、部分共通鍵テーブルを追加し、共通鍵テーブルのサイズに達すると、部分共通鍵テーブルを置き換えるので、共通鍵テーブルのサイズを制限できる。また、共通鍵を記憶していない場合、その旨を運転者に通知するので、共通鍵の更新を運転者に促すことができる。また、共通鍵を記憶していない場合、共通鍵の更新を要求するので、新たな共通鍵を使用可能にできる。

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

基地局装置２０から報知される路車間通信のパケット信号に含まれるセキュリティフレームが次のように構成されてもよい。図１４（ａ）−（ｂ）は、セキュリティフレームのデータ構造のさらに別の一例を示す。図５（ａ）−（ｂ）の変形例であり、図１４（ａ）は、図３（ｂ）に示された複数のＲＳＵパケットのうちの、先頭のＲＳＵパケットのセキュリティフレームであり、図５（ａ）に相当し、図１４（ｂ）は、２番目以降のＲＳＵパケットのセキュリティフレームであり、図５（ｂ）に相当する。先頭のＲＳＵパケットの「フレームの認証用ハッシュ値」には、グループを構成するすべてのセキュリティフレームの「アプリケーション」に対するハッシュ値を配置したリストをセットする。電子署名の対象は「フレームの認証用ハッシュ値」のみである。これによって処理の単一化、先頭のＲＳＵパケットのアプリケーションデータの通信喪失による欠落によって、「フレームの認証用ハッシュ値」に対する電子署名の検証ができなくなることが防止されるとともに、早期に署名検証処理を始めることができる。なお、図５（ａ）では、アプリケーションデータに先行して配置される「バージョン・メッセージ」、「ＭＡＣ方式ヘッダ」、「公開鍵証明書」、「パケットの認証用ハッシュ値」、「電子署名」がセキュリティヘッダに、アプリケーションデータに続いて配置される「ＭＡＣ方式フッタ」がセキュリティフッタとなる。図５（ｂ）では、「バージョン・メッセージ」、「ＭＡＣ方式ヘッダ」、「証明書ダイジェスト」がセキュリティヘッダに、アプリケーションデータに続いて配置される「ＭＡＣ方式フッタ」がセキュリティフッタとなる。

通信鍵を双方鍵テーブルから選択される場合、あるいは双方マスタ鍵で暗号化されて送付される場合もある。

（実施例２）
本発明の実施例の基礎となった知見は、次の通りである。通信内容の秘匿性を確保するには、通信データに対して暗号方式を利用したメッセージ認証を行う手法が有効である。暗号方式には、大別すると公開鍵暗号化方式と共通鍵暗号化方式がある。前者は後者と比較し、セキュリティは高いがデータ量が多く、かつ、処理負荷が大きいため実装コストが高くなる。すなわち、両者はトレードオフの関係にある。路車間通信では、車車間通信より公共性が強いため、なりすましやデータ改ざんを防ぐ要請がより大きくなる。そこで、路側機から車載器に、公開鍵証明書および電子署名付きのデータを格納したパケット信号を報知するシステムが検討されている。

しかしながら、すべてのパケット信号に含まれる公開鍵証明書および電子署名の検証を実行するには高速な処理が必要となり、端末装置に高速のハードウエアを搭載する必要性が発生する。これらの検証処理には公開鍵暗号方式が用いられるため、演算量が多くなり回路規模が増大し、コストアップする要因となる。さらには処理遅延によって適切なタイミングで情報を得ることができず、ユーザが適切なタイミングでサービスを享受できなくなる。本発明はこうした状況に鑑みてなされたものであり、その目的は、セキュリティを向上させつつ、パケット信号を受信する際の処理負荷を軽減させる技術を提供することにある。

ここで、路車間通信として、基地局装置は、交差点情報および渋滞情報などが格納されたパケット信号を報知する。なお、「無線装置」は、基地局装置であってもよいし、端末装置であってもよい。

本発明の実施例に係る通信システム５００の構成は、図１と同様であるので、ここでは説明を省略する。通信システム５００において規定されるスーパーフレームのフォーマットは、図２（ａ）−（ｄ）と同様である。基地局装置２０は、１つまたは複数のサブフレームの先頭部分に路車送信期間を設定し、パケット信号を発信する。ここでは、説明を簡単にするため１つの基地局装置２０は１つのサブフレームを使用して、パケット信号を送信するものとする。図２（ｂ）において、第１基地局装置２０ａの電波到達距離内に配置される他の基地局装置２０および端末装置１０は、この期間にパケット信号を報知することはない。

このように、基地局装置２０は、自身がパケット信号（情報）を報知するために１つのサブフレームの路車送信期間を独占することで、固有の報知期間をスーパーフレーム内に設けている。スーパーフレーム内に設定可能なサブフレームは有限（本実施の形態では８個）ではあるが、複数の基地局装置２０の電波到達距離を考慮して、スーパーフレームを選択すれば、基地局装置２０の設置台数を制限することはない。逆に、スーパーフレーム内のすべてのサブフレームに対して基地局装置２０が設置されるものとは限らない。

サブフレームの構成は、図３（ａ）−（ｂ）と同様である。図３では、１つの基地局装置２０は、５つのＲＳＵパケット、すなわちＲＳＵパケット１、ＲＳＵパケット２、ＲＳＵパケット３、ＲＳＵパケット４、ＲＳＵパケット５を順に送信する。通信システム５００において規定される各レイヤのフレームのフォーマットは、図４（ａ）−（ｆ）と同様である。

図１５は、端末装置１０が送信する車車間通信のパケット信号のセキュリティレイヤのフレームフォーマットの詳細な構成例を示す。車車間通信では、大きなパケット信号が送信できないこと、報知されるパケット信号の総数が多いこと、情報の精度が路車間送信のパケット信号に含まれる情報より低いことなどから、公開鍵暗号方式は使用せず、共通鍵暗号方式によるＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）を使用して、パケット信号に含まれる情報の完全性を認証する。このデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ＩＤ」、「送信元機器ＩＤ」、「乱数」、「データ長」が配置され、その後に「ペイロード」が配置され、最後にセキュリティフッダとして「ＭＡＣ」が配置される。ここで、「」は、セキュリティフレームを構成するフィールドを表している。

「バージョン」はフレームフォーマットのバージョンをセットする。「メッセージ形式」は、データ認証方式を規定する認証タイプ（ＡＴ）と、「ペイロード」に対する保護の形式を指定するメッセージタイプ（ＭＴ）の２つをセットする。図１６は、「メッセージ形式」の詳細である。先頭の２ビットである認証タイプ（ＡＴ）は、１ビットの2つのフラグ情報ＭＡＣ ＦｌａｇとＳＩＧ Ｆｌａｇからなる。ＭＡＣ Ｆｌａｇは、共通鍵暗号方式によるＭＡＣ認証に対応するか否かを示し、ＳＩＧ Ｆｌａｇは、公開鍵暗号方式による署名認証に対応するか否かを示す。ＭＡＣ認証のみに対応する車車間通信パケット信号では、ＭＡＣ Ｆｌａｇ＝１、ＳＩＧ Ｆｌａｇ＝０となる。メッセージタイプ（ＡＴ）は、いずれの形式も設定できる。メッセージタイプ（ＭＴ）は、平文データ形式（＝０）、認証付きデータ形式（＝１）および認証付き暗号化データ形式（＝２）がある。

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

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

「データ長」は、「ペイロード」のバイト数がセットされる。「ペイロード」には、アプリケーションデータがセットされる。「ＭＡＣ」は、メッセージタイプ（ＡＴ）が、認証付きデータ形式（＝１）または認証付き暗号化データ形式（＝２）の場合に、ＭＡＣの値がセットされる。

次に、図１５のセキュリティフレームに対する暗号技術について説明する。ここでは、共通鍵暗号方式として、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）を採用するものとする。具体的には、データ形式が認証付きデータ形式（＝１）の場合には、ＣＢＣ−ＭＡＣ（Ｃｉｐｈｅｒ Ｂｌｏｃｋ Ｃｈａｉｎｉｎｇ − Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）を、認証付き暗号化データ形式（＝２）である場合、ＣＣＭ（Ｃｏｕｎｔｅｒ ｗｉｔｈ ＣＢＣ Ｍｏｄｅ）とする。なおＣＣＭは、メッセージ認証にＣＢＣ−ＭＡＣを、データ秘匿（暗号化）にＣＴＲ（ＣｏｕｎＴｅＲ）モードを用いた暗号化認証モードである。処理を簡単化するために、データ形式が認証付きデータ形式（＝１）におけるＭＡＣの演算対象および演算手順は、ＣＣＭにおけるＭＡＣの演算対象および演算手順に従うものとする。

「鍵ＩＤ」にセットされている鍵ＩＤに当該通信鍵を用いて、ＭＡＣ値を求める。ＣＣＭのＣＢＣ−ＭＡＣ演算では、通信鍵を用いた暗号化において暗号結果を攪乱するために用いる通信毎にユニークな値であるｎｏｎｃｅが、ＣＢＣ−ＭＡＣ演算およびＣｏｕｎｔｅｒモードのＣｏｕｎｔｅｒブロックに使用される。図１５のセキュリティフレームでは、ｎｏｎｃｅとして、「送信元機器ＩＤ」と「乱数」に、それぞれセットされている機器ＩＤと乱数を連結して使用する。この乱数は送信元の端末装置１０において送信時に生成した乱数であり、乱数のデータ長の範囲でユニークさが保証されている。なお、ｎｏｎｃｅとして乱数のみを使用してもよい。ＭＡＣの演算は、ｎｏｎｃｅとデータ長を、「ペイロード」にセットされているアプリケーションデータの先頭に連結したデータを対象として行う。

この例では、ＭＡＣの演算対象は「機器ＩＤ」、「乱数」、「データ長」と「ペイロード」であり、暗号対象は、「ペイロード」および「ＭＡＣ」である。自明ではあるが暗号化を行うのはＭＡＣ値を求めた後になる。

図１７は、基地局装置２０が送信する路車間通信パケット信号のセキュリティレイヤのフレームの詳細な構成例を示す。図１７（ａ）は、図３のＲＳＵパケット１のセキュリティフレームであり、図１７（ｂ）は、図３のＲＳＵパケット２〜５のセキュリティフレームである。つまり、ＲＳＵ期間の先頭のＲＳＵパケットのセキュリティフレームは図１７（ａ）に従い、同一のＲＳＵ期間にて送信される残りのＲＳＵパケットのセキュリティフレームは図１７（ｂ）に従う。

図１７（ａ）のデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ＩＤ」、「送信元機器ＩＤ」、「乱数」、「データ長」、「公開鍵証明書」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」が配置され、その後に「ペイロード」が配置され、最後にセキュリティフッダとして「電子署名」と「ＭＡＣ」が配置される。「バージョン」、「メッセージ形式」、「鍵ＩＤ」、「送信元機器ＩＤ」、「乱数」、「ペイロード」および「ＭＡＣ」については、図１５のデータ構造のそれと同じなので説明を割愛する。但し、このデータ構造はＭＡＣ認証と署名認証に両対応するので、ＭＡＣ Ｆｌａｇ＝１、ＳＩＧ Ｆｌａｇ＝１となる。

「データ長」は、「公開鍵証明書」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」、「ペイロード」および「電子署名」の総バイト数がセットされる。「公開鍵証明書」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」、「ペイロード」および「電子署名」を１つのフィールドとしてとらえると、図１５のセキュリティフレームと同一のデータ構造となる。

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

「フレーム番号」は、ＲＳＵ期間に配置されるセキュリティフレームの順序、すなわちＲＳＵパケット順序をセットする。フレーム番号が０スタートとすると、図１７（ａ）のデータ構造を持つセキュリティフレームは、先頭に配置されるセキュリティフレームであることから、０をセットする。「最終フレーム番号」は、ＲＳＵ期間に送信される最後のセキュリティフレームの番号、すなわち、ＲＳＵ期間に配置されるＲＳＵパケットの総数−１をセットする。図３に従う基地局装置２０が送信したＲＳＵパケットのセキュリティフレームの場合、４をセットする。また、フレーム番号が１スタートとしてもよい。この場合、図１７（ａ）データ構造を持つセキュリティフレームの「フレーム番号」に１を、「最終フレーム番号」にＲＳＵ期間のフレーム総数をセットする。「フレーム認証リスト」は、後続のセキュリティフレームのデータに対する認証データのリストをセットする。

「電子署名」は、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」「認証データリスト」および「ペイロード」に対する署名がセットされる。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。なお、署名対象には「フレーム認証リスト」が含まれるため、このセキュリティフレームのメッセージタイプ（ＭＴ）によって、署名の必要性が判断できないので、認証タイプ（ＡＴ）＝１の時は、「電子署名」に署名をセットする。次いで、メッセージタイプ（ＭＴ）が、認証付きデータ形式（＝１）、または、認証付き暗号化データ形式（＝２）の時は、署名をセットした後、ＭＡＣ値を求め、「ＭＡＣ」にセットする。そして、暗号化を行う。この例では、ＭＡＣの演算対象は「機器ＩＤ」、「乱数」、「データ長」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」、「ペイロード」および「電子署名」であり、暗号対象は、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」、「認証データリスト」、「ペイロード」、「電子署名」および「ＭＡＣ」である。

図１７（ｂ）のデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ＩＤ」、「送信元機器ＩＤ」、「乱数」、「データ長」、「ダイジェスト」、「フレーム番号」、「最終フレーム番号」が配置され、その後に「ペイロード」が配置され、最後にセキュリティフッダとして「ＭＡＣ」が配置される。「バージョン」、「メッセージ形式」、「鍵ＩＤ」、「送信元機器ＩＤ」、「乱数」、「フレーム番号」、「最終フレーム番号」と「ペイロード」および「ＭＡＣ」については、図１７（ａ）のデータ構造のそれと同じなので説明を割愛する。

図３に従う基地局装置２０が送信したＲＳＵパケットのセキュリティフレームの場合、「最終フレーム番号」は、４をセットされる。ＲＳＵパケット２の「フレーム番号」は、１をセットされる。同様にＲＳＵパケット３、ＲＳＵパケット４、ＲＳＵパケット５の「フレーム番号」は、それぞれ１、２、３、４がセットされる。「データ長」は、「ダイジェスト」、「フレーム番号」、「最終フレーム番号」、「ペイロード」および「電子署名」の総バイト数がセットされる。「ダイジェスト」、「フレーム番号」、「最終フレーム番号」および「ペイロード」を１つのフィールドとしてとらえると、図１５のセキュリティフレームと同一のデータ構造となる。

「ダイジェスト」は、送信元の基地局装置２０に固有の公開鍵に対する公開鍵証明書のダイジェストがセットされる。ここではダイジェストとして公開鍵証明書のボディ、すなわち、公開鍵証明書の署名の対象部に対するハッシュ値、例えば、ＳＨＡ−２２４、ＳＨＡ−２２５によって求められた値、あるいはその一部を当てるとするが、公開鍵証明書に含まれる署名、署名の一部、公開鍵または／かつ機器ＩＤをダイジェストとして代用してもよい。さらに、ダイジェストとして機器ＩＤを代用とする場合、「送信元機器ＩＤ」にセットされている機器ＩＤと同一で値であれば「ダイジェスト」を省略してもよい。この例では、ＭＡＣの演算対象は「機器ＩＤ」、「乱数」、「データ長」、「ダイジェスト」、「フレーム番号」、「最終フレーム番号」および「ペイロード」であり、暗号対象は、「フレーム番号」、「最終フレーム番号」、「ダイジェスト」、「ペイロード」および「ＭＡＣ」である。

なお、１つの基地局装置２０が複数の路車通信期間を使用する場合、後続のＲＳＵ期間に送信されるＲＳＵパケットのセキュリティフレームを、全て図１７（ｂ）としてもよい。この場合、基地局装置２０からスーパーフレームに送信されるＲＳＵパケットのうち、先頭のＲＳＵパケットのセキュリティフレームが図１７（ａ）に、残りのＲＳＵパケットのセキュリティフレームがすべて図１７（ｂ）に従う。

また、図４においてセキュリティフレームが、ＲＳＵパケットに収まるように説明したが、基地局装置２０が複数のアプリケーションデータを連結して送信する場合、アプリケーションデータ単位で、セキュリティフレームを構成するようにしてもよい。この場合、基地局装置２０からスーパーフレームに送信されるアプリケーションデータのうち、先頭に送信されるアプリケーションデータが、図１７（ａ）に従ったセキュリティフレームの「ペイロード」にセットされ、残りのアプリケーションデータが、図１７（ｂ）に従った異なるセキュリティフレームの「ペイロード」にセットされる。この後、パケット単に分割され、ＲＳＵパケットとして送信される。

図１８は、「フレーム認証リスト」にセットする、認証データのリストの構成例を示す。後続するセキュリティフレームのＭＡＣ値をフレーム番号順に並べたリストである。サイズは、（認証データのバイト数）×（総フレーム数−１）となる。セットされるＭＡＣ値は、図１７（ｂ）における「ＭＡＣ」にセットされるＭＡＣ値と同じである。なお、ＭＡＣ値でなく、ハッシュ値のリストとしてもよい。この場合、ハッシュ演算の対象は、「フレーム番号」、「最終フレーム番号」および「ペイロード」である。なお、「フレーム認証リスト」には、後続するセキュリティフレームのＭＡＣ値をフレーム番号順に並べたリストとしたが、ＭＡＣ値に変えて、ハッシュ関数によるダイジェスト値をセットしてもよい。

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

説明の便宜上、第１基地局装置２０ａ、第２基地局装置２０ｂ、第３基地局装置２０ｃ、第４基地局装置２０ｄ、第５基地局装置２０ｅは、図３に従ったＲＳＵパケット送信するものとする。また、ＲＳＵパケット１のセキュリティフレームの公開鍵証明書の検証および署名検証処理を、単に署名検証と呼び、ＲＳＵパケット１〜５のセキュリティフレームに対するＭＡＣ認証処理を、ＭＡＣ認証と呼ぶ。受信したＲＳＵパケットのセキュリティフレームのメッセージタイプ（ＭＴ）が認証付き暗号化データ形式（＝２）のとき、復号後に、署名検証およびＭＡＣ検証は実行される。

図１９において、期間Ｔｖは、基地局装置２０からの電波が受信できずＲＳＵ用コアが処理を停止している期間を示し、期間Ｔｃは署名検証を実行している期間を示し、期間ＴｍはＭＡＣ検証を実行している期間を示し、期間Ｔｍｃは署名検証とＭＡＣ検証を平行して実行している期間を示す。期間Ｔｖは車両１００が、新たに第１基地局装置２０ａの電波圏内に入ると開始する。第１基地局装置２０ａの電波圏内に入り、ＲＳＵパケット１を受信すると、ＲＳＵ１用コアは、第１基地局装置２０ａから報知されるＲＳＵパケット１の署名検証を実行する。そして署名検証に成功すると、期間Ｔｍに移行する。

期間Ｔｍでは、ＲＳＵ１用コアは受信したＲＳＵパケットのＭＡＣ検証を実行し、ＭＡＣ検証の結果を報告する。期間Ｔｍに移行後、一定時間が経過してＲＳＵパケット１を受信すると期間Ｔｍｃに移行する。期間Ｔｍｃでは、期間移行のきっかけとなったＲＳＵパケット１に対する署名検証と、受信するＲＳＵパケットのＭＡＣ検証を平行して行う。そして、ＭＡＣ検証の結果を報告する。また、署名検証が成功すると再び期間Ｔｍに戻る。車両１００が第１基地局装置２０ａの電波圏外に出ると、期間Ｔｖに移行する。その後、車両１００が第５基地局装置２０ｅの電波圏内に入り、第５基地局装置２０ｅからのＲＳＵパケット１を受信すると、再び期間Ｔｃに移行し、第５基地局装置２０ｅからのＲＳＵパケット１の署名検証を実行する。以後の処理は第１基地局装置２０ａに対する処理と同じであるため説明を省略する。ＲＳＵ２用コア〜ＲＳＵ４用コアも、ＲＳＵ１用コアと同様の処理を実行する。

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

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

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

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

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

図２１は、車両１００に搭載された端末装置１０の構成を示す。端末装置１０は、アンテナ１１、ＲＦ部１２、変復調部１３、ＭＡＣフレーム処理部１４、セキュリティ処理部１５、受信処理部１６１、通知部１６２、データ生成部１７、記憶部１８および制御部１９を備える。これは、図８と同様であるので、ここでは差異を中心に説明する。データ生成部１７は、特定した情報を受信処理部１６１に自車の車両情報として出力する。記憶部１８は、種々の情報を記憶する。制御部１９は、端末装置１０全体の処理を制御する。

セキュリティ処理部１５は、セキュリティフレームを生成または解釈する。本実施例では、基地局装置２０からのパケット受信に注目するため、そのパケット信号に格納されたセキュリティフレームを解釈する処理に注目する。セキュリティ処理部１５は、検証部１１５１、復号部１１５２および記憶部１１５３を含む。記憶部は1２３は、本実施例では図示しない認証局が発行する認証用の公開鍵と、自身の機器ＩＤ、複数の通信鍵を内部に格納している。復号部１１５２は、セキュリティフレームの「鍵ＩＤ」により特定される通信鍵を記憶部１１５３から取得して、暗号対象を復号する。検証部１１５１は、ハッシュ関数を用いたハッシュ値の演算と、ハッシュ値および記憶部１１５３に格納されている認証用の公開鍵を用いて基地局装置２０の公開鍵証明書の署名および署名の署名検証、および、セキュリティフレームの「鍵ＩＤ」により特定される記憶部１１５３に格納される通信鍵を用いて、ＭＡＣ検証をする。なお、認証鍵は、認証局において公開鍵証明書の署名を生成するのに用いた秘密鍵と対をなす公開鍵である。

図２２は、検証部１１５１の構成例を示す。構成例に係る検証部１１５１は、ハッシュ演算部１１５１ａ、ＥＣＤＳＡ検証部１１５１ｂ、ダイジェスト保持部１１５１ｃ、ＭＡＣ検証部１１５１ｄ、検証制御部１１５１ｅを含む。この構成例では、各ＲＳＵ用コアは、ダイジェスト保持部１１５１ｃ、検証制御部１１５１ｅによって構成される。

ハッシュ演算部１１５１ａは、ハッシュ関数を用いて公開鍵証明書および、図１７（ａ）に従うセキュリティフレーム、すなわち、ＲＳＵパケット１の署名対象に対するハッシュ値を演算する。ＥＣＤＳＡ検証部１１５１ｂは、基地局装置２０から報知されるパケット信号に含まれる公開鍵証明書に含まれる署名を、記憶部１１５３に保持される認証鍵（公開鍵）を用いて検証し、ＲＳＵパケット１の署名を、ＲＳＵパケット１に含まれる公開鍵証明書の公開鍵を用いて実行する。認証鍵は予め組み込まれていてもよいし、安全な手段で事後的に取得し、記憶部１１５３に格納したものであってもよい。具体的には、ＥＣＤＳＡ検証アルゴリスに従い、公開鍵とハッシュ演算部１１５１ａで求めたハッシュ値と署名とを利用し検証をする。説明の便宜上、ＲＳＵパケット１に含まれる公開鍵証明書の検証と署名対象の検証をひとまとめとにしてＲＳＵ検証と呼ぶ。ＲＳＵ検証の成功（承認ともいう）とは、双方の検証が承認されたことを意味する。

ダイジェスト保持部１１５１ｃは、ＲＳＵ検証が公開鍵証明書および署名対象の検証が成功したセキュリティフレームの公開鍵証明書のダイジェスト、公開鍵、機器ＩＤ等を保持する。説明の便宜上、これらの情報をまとめてＲＳＵ検証情報と呼ぶ。ダイジェスト保持部１１５１ｃは、各ＲＳＵ期間（サブスロット）毎にＲＳＵ検証情報を保持する。すなわち、ＲＳＵ用コアの数だけＲＳＵ検証情報を保持する。公開鍵証明書のダイジェストとして、ここでは公開鍵証明書のハッシュ値を当てるとするが、公開鍵証明書のシリアル番号、公開鍵または／かつ機器ＩＤをダイジェストとして代用してもよい。すなわち、受信したセキュリティフレームから公開鍵証明書あるいは公開鍵証明書と対をなす秘密鍵の所有主体が特定できる情報であればいかなる情報であっても良い。なお、公開鍵証明書のシリアル番号とする場合は、セキュリティフレームの公開鍵証明書のダイジェストを公開鍵証明書のシリアル番号に置き換える必要がある。このようにするとダイジェスト保持部１１５１ｃに保持するデータ量が削減される。ＭＡＣ検証部１１５１ｄは、ＲＳＵパケット１〜５のＭＡＣ対象に対するＭＡＣ値を演算し、演算により求めたＭＡＣ値とセキュリティフレームの「ＭＡＣ」にセットされているＭＡＣ値とを比較することでＭＡＣ検証を行う。両者が一致すると成功（承認ともいう）、不一致だと失敗（否認ともいう）となる。ＭＡＣ検証には、記憶部１１５３に格納されている鍵ＩＤで特定される通信鍵を用いる。ここでは路車間通信の受信にのみ着目して説明しているが、ＭＡＣ検証部１１５１ｄは車車間通信の送受信の処理、すなわち図１５のセキュリティフレームのＭＡＣ検証、ＭＡＣ生成にも利用される。なお、ＭＡＣ検証はＥＣＤＳＡ検証に比べて高速で処理できる。ゆえに、ＭＡＣ検証結果とアプリケーションデータを受信処理部１６１に対して同じタイミングで提供することができる。

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

以下では特に断りがない限り、ダイジェスト保持部１１５１ｃにＲＳＵ検証情報に関する処理はパケット信号を受信したＲＳＵ期間に対応するＲＳＵ検証情報に対する処理である。検証制御部１１５１ｅは、基地局装置２０から報知されるＲＳＵパケット１を受信すると、ハッシュ演算部１１５１ａに、そのＲＳＵパケット１に含まれる公開鍵証明書のダイジェストの演算を指示する。ダイジェストが演算されると、検証制御部１１５１ｅは、演算されたダイジェストとダイジェスト保持部１１５１ｃに保持されるダイジェストとの比較をする。両者が異なる場合、検証制御部１１５１ｅは当該ＲＳＵパケット１に含まれる公開鍵証明書の検証を実行するようＥＣＤＳＡ検証部１１５１ｂに指示する。公開鍵証明書の検証が成功した場合、検証制御部１１５１ｅは当該ＲＳＵパケット１の署名の検証を実行するようＥＣＤＳＡ検証部１１５１ｂに指示する。引き続き署名検証が成功、すなわち、ＲＳＵ検証が成功すると、検証制御部１１５１ｅは、ダイジェスト保持部１１５１ｃに保持されるＲＳＵ検証情報を検証したＲＳＵパケット１のＲＳＵ検証情報に更新する。公開鍵証明書の検証が失敗または署名検証に失敗した（ＲＳＵ検証の失敗、あるいは、否認ともいう）場合処理を終了する。両ダイジェストが対応（より厳密には、一致）する場合、当該パケット信号に含まれるＲＳＵ検証をスキップする。ただし、ＲＳＵ検証後、予め定められた所定の期間が経過するとＲＳＵ認証を行いＲＳＵ検証情報の正当性を再確認する。すなわち、ＲＳＵ検証後の一定期間は、公開鍵証明書のダイジェストの一致をもってＲＳＵ検証成功とみなす。しかしながら、ある基地局装置２０から報知されたＲＳＵパケット１のＲＳＵ検証が一度成功したからといって、そのまま放置すると損なわれるため一定期間毎にＲＳＵ検証を行い信頼性は高める。なお、ＲＳＵパケット１〜２に含まれるアプリケーションデータの真性および正当性は、両ダイジェストの一致とＭＡＣ検証の成功をもって承認と判定する。

次に、ＲＵＳパケットの検証について説明する。ＲＳＵパケットを受信すると、検証制御部１１５１ｅは、ＭＡＣ検証部１１５１ｄに対してＲＳＵパケットのＭＡＣ検証を指示する。ＭＡＣ検証が成功（承認）すると、ＭＡＣ検証部１１５１ｄは、ダイジェスト保持部１１５１ｃに保持されているＲＳＵ認証済みのダイジェストと、当該ＲＳＵパケットの公開鍵証明書のダイジェストの一致を確認する。当該ＲＳＵパケットの公開鍵証明書のダイジェストとは、ＲＳＵパケット１のとき、当該ＲＳＵパケットに含まれる公開鍵証明書を入力として、ハッシュ演算部１１５１ａで算出したハッシュ値である。また、ＲＳＵパケット２〜５のとき、当該ＲＳＵパケットの「ダイジェスト」にセットされているダイジェストである。ダイジェスト保持部１１５１ｃに一致するダイジェストが保持されていると、ＭＡＣ検証部１１５１ｄは当該ＲＳＵパケットの検証成功と判断し、承認を通知する。ダイジェスト保持部１１５１ｃに一致するダイジェストが保持されていないと、ＲＳＵパケットの改ざんはないが、送信先の基地局装置２０の特定ができないと判断し、不定を通知する。ＭＡＣ検証が失敗（否認）すると、検証制御部１１５１ｅは、否認を通知する。

このように判断することで、ＭＡＣ検証終了後に検証結果を出力できるようになり車車間通信のパケットの検証結果とほぼ同等の遅延にて検証結果を提供できる。なお、車車間通信のパケットの検証は、ＭＡＣ値の一致の確認のみであるため説明は詳細な省略する。

図２３は、構成例に係る検証部１１５１が用いられる端末装置１０のＲＳＵパケットの受信処理を示すフローチャートである。ＲＦ部１２はＲＳＵパケットを受信する。このＲＳＵパケットは変復調部１３、ＭＡＣフレーム処理部１４を経て、セキュリティ処理部１５に出力される。セキュリティ処理部１５の検証部１１５１がＲＳＵパケットを受け取ると処理が開始される。検証制御部１１５１ｅはＲＳＵパケットを受け取るとＭＡＣ検証部１１５１ｄにＭＡＣ検証を開始するように指示する（Ｓ１０）。そして受け取ったＲＳＵパケットのフレーム番号を確認する（Ｓ１１）。フレーム番号が０の場合（Ｓ１１のＹ）、ハッシュ演算部１１５１ａに当該ＲＳＵパケットに配置された公開鍵証明書のダイジェストの演算を指示する。指示を受けたハッシュ演算部１１５１ａは公開鍵証明書のダイジェストを演算して求める（Ｓ１２）。検証制御部１１５１ｅは、ハッシュ演算部１１５１ａが演算して求めた公開鍵証明書のダイジェストと、ダイジェスト保持部１１５１ｃに保持される公開鍵証明書のダイジェストとの一致するを比較し、一致するか否か判定する（Ｓ１３）。

ダイジェストが一致しない場合（Ｓ１３のＮ）、検証制御部１１５１ｅはＥＣＤＳＡ検証部１１５１ｂの動作状態をチェックする（Ｓ１７）。ＥＣＤＳＡ検証部１１５１ｂが待機中の場合（Ｓ１７のＹ）、検証制御部１１５１ｅはＥＣＤＳＡ検証部１１５１ｂに当該ＲＳＵパケットのＲＳＵ認証の開始を指示し（Ｓ１４）、当該ＲＳＵパケットに対する処理を終了する。一方、ＥＣＤＳＡ検証部１１５１ｂが稼働中の場合（Ｓ１７のＮ）、検証制御部１１５１ｅはして受信されたＲＳＵパケットのＲＳＵ検証を断念し、当該ＲＳＵパケットに対する処理を終了する。

ダイジェストが一致した場合（Ｓ１３のＹ）、検証制御部１１５１ｅは当該ダイジェストを含むＲＳＵ検証情報がダイジェスト保持部１１５１ｃに保持されてからの経過時間を確認する（Ｓ１６）。これはＲＳＵ検証が成功してからの経過時間を確認することになる。予め定めた所定の時間を経過している場合（Ｓ１６のＹ）、当該ＲＳＵパケットのＲＳＵ検証を試みるためステップＳ１７に移行する。ステップＳ１１にてフレーム番号が０以外の場合（Ｓ１１のＮ）、ＲＳＵ検証は必要ないと判断し、当該ＲＳＵパケットに対する処理を終了する。予め定めた所定の時間を経過していない場合（Ｓ１６のＮ）、処理は終了される。

図２４は、ＥＣＤＳＡ検証部１１５１ｂにおけるＲＳＵパケットのＲＳＵ検証処理を示すフローチャートである。ＲＳＵパケット１を対象とする。ＥＣＤＳＡ検証部１１５１ｂは検証制御部１１５１ｅからＲＳＵパケットのＲＳＵ認証開始の指示を受けると、ＥＣＤＳＡ検証部動作状態を稼働中に変更する（Ｓ３０）。そして、記憶部１１５３に格納されている認証鍵を取得して当該ＲＳＵパケットに含まれる公開証明書の検証を行う（Ｓ３１）。当該検証が成功した場合（Ｓ３１のＹ）、当該公開鍵証明書に含まれる公開鍵を用いて、当該ＲＳＵパケットに含まれる署名の検証を行う（Ｓ３２）。当該検証が成功した場合（Ｓ３２のＹ）、ダイジェスト保持部１１５１ｃに格納されている、当該公開鍵証明書のダイジェストを含むＲＳＵ検証情報に上書きする（Ｓ３３）。このとき経過時間はリセットされる。ステップＳ３０にて当該ＲＳＵパケットに含まれる公開鍵証明書の検証が失敗した場合（Ｓ３１のＮ）またはステップＳ３1にて当該ＲＳＵパケットに含まれる署名の検証が失敗した場（Ｓ３２のＮ）、当該ＲＳＵパケットを受信したＲＳＵ検証情報を破棄する（Ｓ３５）。ステップＳ３３またはステップＳ３５が終了すると、ＥＣＤＳＡ検証部動作状態を待機中に変更して（Ｓ３４）、ＲＳＵ検証の処理を終了する。

図２５は、ＭＡＣ検証部１１５１ｄにおけるＲＳＵパケットのＭＡＣ検証処理を示すフローチャートである。ＭＡＣ検証部１１５１ｄは検証制御部１１５１ｅからＲＳＵパケットのＭＡＣ認証開始の指示を受けると、当該ＲＳＵパケットの鍵ＩＤにしたがって記憶部１１５３に格納されている通信鍵を取得する（Ｓ４０）。ＭＡＣ検証部１１５１ｄは取得した通信鍵を用いて当該ＲＳＵパケットのＭＡＣの演算対象に対するＭＡＣ値を演算する（Ｓ４１）。そして、演算によって得たＭＡＣ値と、当該ＲＳＵパケットに含まれるＭＡＣ値を比較する（Ｓ４２）。２つのＭＡＣ値が一致する場合（Ｓ４２のＹ）、当該ＲＳＵパケットがＲＳＵパケット１のとき、ハッシュ演算部１１５１ａから当該ＲＳＵパケットに含まれる公開鍵証明書のダイジェストを取得する（Ｓ４３）。当該ＲＳＵパケットがＲＳＵパケット２〜５のとき、当該ＲＳＵパケットに含まれるダイジェストを取り出す。ダイジェスト保持部１１５１ｃに保持される公開鍵証明書のダイジェストと取得したダイジェストの比較し、一致するか否か判定する（Ｓ４４）。両者が一致する場合（Ｓ４４のＹ）、ＭＡＣ検証部１１５１ｄは当該ＲＳＵパケットの検証成功と判断し、受信処理部１６１に対して承認を通知する（Ｓ４５）。両者が一致しない場合（Ｓ４４のＮ）、ＭＡＣ検証部１１５１ｄは送信先の基地局装置２０の特定ができないと判断し、受信処理部１６１に対して不定を通知する（Ｓ４７）。ステップＳ４２において、ＭＡＣ検証が失敗（否認）すると（Ｓ４２のＮ）、ＭＡＣ検証部１１５１ｄは受信処理部１６１に対して否認を通知する（Ｓ４６）。ステップＳ４７、Ｓ４５またはＳ４６のいずれかによって、受信処理部１６１に対する検証結果の通知によってＭＡＣ検証の処理が終了する。なお、検証結果の通知にあわせて、ＲＳＵパケットに含まれるアプリケーションデータは受信処理部１６１に提供される。なお、不定とは認証処理の結果が確定していない状態を指す。受信処理部１６１は、認証が不定のパケットに含まれるデータを、予め設定された規則にしたがい処理する。たとえば、認証されるまでそのデータに対する処理を停止していてもよいし、未認証である旨のフラグを立てて通知部１６２に渡してもよいし、メッセージに含まれる情報の重要度に応じて両者を使い分けしてもよい。通知部１６２は未認証である旨のフラグが立っている情報を受領した場合、未認証の情報であることをユーザに認識させる態様で、その情報をユーザに通知することができる。

安全性を高めるために、基地局装置２０の受信圏にいる場合であっても、予め定めた期間毎にＲＳＵ検証を行うようにしている。具体的には、ＥＣＤＳＡ検証部１１５１ｂが検証後の時間経過を確認し、ダイジェスト保持部１１５１ｃに、ダイジェストが保持されている場合であっても、ＲＳＵ検証後予め定めた所定の時間を経過したときは、ＲＳＵ検証を行うことを示した。他に、ダイジェスト保持部１１５１ｃに保持されるダイジェストを、一定時間経過後に削除するようにしてもよい。また、両者を併用してもよい。併用する場合は、ＥＣＤＳＡ検証部１１５１ｂが再度ＲＳＵ検証を行うまでの経過時間に対して、ダイジェスト保持部１１５１ｃからダイジェスト削除するまでの経過を長くする必要がある。

以下では、これまでの認証（以下、「認証１」という）とは別の認証（以下、「認証２」という）を説明する。なお、認証２の説明において認証１の説明と重複する部分については、適宜説明を省略する。

図２６は、端末装置１０が送信する車車間通信のパケット信号のセキュリティレイヤのフレームフォーマットの詳細な構成例を示す。車車間通信では、大きなパケット信号が送信できないこと、報知されるパケット信号の総数が多いこと、情報の精度が路車間送信のパケット信号に含まれる情報より低いことなどから、公開鍵暗号方式は使用せず、共通鍵暗号方式によるＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）を使用して、パケット信号に含まれる情報の完全性を認証する。このデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ＩＤ」、「送信元機器ＩＤ」、「乱数」、「データ長」が配置され、その後にペイロードとして「機器管理コード」、「アプリケーションデータ」が配置され、最後にセキュリティフッダとして「ＭＡＣ」が配置される。ここで、「」は、セキュリティフレームを構成するフィールドを表している。

「機器管理コード」は、端末装置１０の稼働状態を他の端末装置１０および基地局装置２０に通知するための状態コードをセットする。「ＡＰＰデータ」には、アプリケーションデータがセットされる。「ＭＡＣ」は、メッセージタイプ（ＡＴ）が、認証付きデータ形式（＝１）または認証付き暗号化データ形式（＝２）の場合に、ＭＡＣの値がセットされる。

図２７は、基地局装置２０が送信する路車間通信パケット信号のセキュリティレイヤのフレームの詳細な構成例を示す。図２７（ａ）は、図３のＲＳＵパケット１のセキュリティフレームであり、図２７（ｂ）は、図３のＲＳＵパケット２〜５のセキュリティフレームである。つまり、ＲＳＵ期間の先頭のＲＳＵパケットのセキュリティフレームは図２７（ａ）に従い、同一のＲＳＵ期間にて送信される残りのＲＳＵパケットのセキュリティフレームは図２７（ｂ）に従う。

図２７（ａ）のデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ＩＤ」、「送信元機器ＩＤ」、「乱数」、「データ長」、「公開鍵証明書」、「メッセージＩＤ」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」が配置され、その後にペイロードとして「機器管理情報」と「ＡＰＰデータ」が配置され、最後にセキュリティフッダとして「電子署名」と「ＭＡＣ」が配置される。「バージョン」、「メッセージ形式」、「鍵ＩＤ」、「送信元機器ＩＤ」、「乱数」、「ＡＰＰデータ」および「ＭＡＣ」については、図２６のデータ構造のそれと同じなので説明を割愛する。但し、このデータ構造はＭＡＣ認証と署名認証に両対応するので、ＭＡＣ Ｆｌａｇ＝１、ＳＩＧ Ｆｌａｇ＝１となる。

「データ長」は、「公開鍵証明書」、「フレーム番号」、「メッセージＩＤ」、「最終フレーム番号」、「フレーム認証リスト」、「機器管理」、「ＡＰＰデータ」および「電子署名」の総バイト数がセットされる。「公開鍵証明書」、「フレーム番号」、「メッセージＩＤ」、「最終フレーム番号」、「フレーム認証リスト」、「機器管理」、「ＡＰＰデータ」および「電子署名」を１つのフィールドとしてとらえると、図２６のセキュリティフレームと同一のデータ構造となる。

「メッセージＩＤ」は、基地局装置２０が送信する毎に付ける送信固有の番号であり、１つのスーパーフレームで送信される全てＲＳＵパケットに同じ値がセットされる。例えば、送信毎にインクリメントするカウント値である。

「機器管理」は、基地局装置２０から任意の端末装置１０に異常や指示を通知、データの提供を行うためのフィールドであり、「機器管理コード」、「対象機器ＩＤ」、「パラメータ長」、「パラメータ」が配置される。「機器管理コード」は、端末装置１０への通知、データ提供を表すコードがセットされる。このコードは図２６の「機器管理コード」にセットされるコードと同じ体系化にあり、状態通知なのかは通知・データ提供なのかはＭＳＢの１ビットで識別されるものとする。すなわち、ＭＳＢが０のときは状態通知コードとして図２６のセキュリティフレームで使用する。ＭＡＣが１のときは通知・データ提供コードとして図２７（ａ）のセキュリティフレームで使用する。通知・情報提供コードは、その値によってオプションフィールドを配置する。「パラメータ長」、「パラメータ」がオプションフィールドであり、データ提供時に使用する。「対象機器ＩＤ」は、通知あるいは、データ提供を行う端末装置１０の機器ＩＤをセットする。不特定に端末装置１０に対して通知やデータ提供を行うときは、オール０をセットする。「パラメータ長」は、「パラメータ」のバイト数である。「パラメータ」は、提供するデータをセットする。

「電子署名」は、「メッセージＩＤ」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」「認証データリスト」、およびペイロードに対する署名がセットされる。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。なお、署名対象には「フレーム認証リスト」が含まれるため、このセキュリティフレームのメッセージタイプ（ＭＴ）によって、署名の必要性が判断できないので、認証タイプ（ＡＴ）＝１の時は、「電子署名」に署名をセットする。次いで、メッセージタイプ（ＭＴ）が、認証付きデータ形式（＝１）、または、認証付き暗号化データ形式（＝２）の時は、署名をセットした後、ＭＡＣ値を求め、「ＭＡＣ」にセットする。そして、暗号化を行う。この例では、ＭＡＣの演算対象は「機器ＩＤ」、「乱数」、「データ長」、「メッセージＩＤ」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」、ペイロードおよび「電子署名」であり、暗号対象は、「メッセージＩＤ」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」、「認証データリスト」、ペイロード、「電子署名」および「ＭＡＣ」である。

図２７（ｂ）のデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ＩＤ」、「送信元機器ＩＤ」、「乱数」、「データ長」、「ダイジェスト」、「フレーム番号」、「最終フレーム番号」が配置され、その後にペイロードとして「ＡＰＰデータ」が配置され、最後にセキュリティフッダとして「ＭＡＣ」が配置される。「バージョン」、「メッセージ形式」、「鍵ＩＤ」、「送信元機器ＩＤ」、「乱数」、「メッセージＩＤ」、「フレーム番号」、「最終フレーム番号」と「ＡＰＰデータ」および「ＭＡＣ」については、図２７（ａ）のデータ構造のそれと同じなので説明を割愛する。

図３に従う基地局装置２０が送信したＲＳＵパケットのセキュリティフレームの場合、「最終フレーム番号」は、４をセットされる。ＲＳＵパケット２の「フレーム番号」は、1をセットされる。同様にＲＳＵパケット３、ＲＳＵパケット４、ＲＳＵパケット５の「フレーム番号」は、それぞれ1、２、３、４がセットされる。「データ長」は、「ダイジェスト」、「メッセージＩＤ」、「フレーム番号」、「最終フレーム番号」、ペイロードおよび「電子署名」の総バイト数がセットされる。「ダイジェスト」、「メッセージＩＤ」、「フレーム番号」、「最終フレーム番号」およびペイロードを１つのフィールドとしてとらえると、図２６のセキュリティフレームと同一のデータ構造となる。

「ダイジェスト」は、送信元の基地局装置２０に固有の公開鍵に対する公開鍵証明書のダイジェストがセットされる。ここではダイジェストとして公開鍵証明書のボディ、すなわち、公開鍵証明書の署名の対象部に対するハッシュ値、例えば、ＳＨＡ−２２４、ＳＨＡ−２２５によって求められた値、あるいはその一部を当てるとするが、公開鍵証明書に含まれる署名、署名の一部、公開鍵または／かつ機器ＩＤをダイジェストとして代用してもよい。さらに、ダイジェストとして機器ＩＤを代用とする場合、「送信元機器ＩＤ」にセットされている機器ＩＤと同一で値であれば「ダイジェスト」を省略してもよい。この例では、ＭＡＣの演算対象は「機器ＩＤ」、「乱数」、「データ長」、「ダイジェスト」、「メッセージＩＤ」、「フレーム番号」、「最終フレーム番号」およびペイロードであり、暗号対象は、「メッセージＩＤ」、「フレーム番号」、「最終フレーム番号」、「ダイジェスト」、ペイロードおよび「ＭＡＣ」である。

なお、１つの基地局装置２０が複数の路車通信期間を使用する場合、後続のＲＳＵ期間に送信されるＲＳＵパケットのセキュリティフレームを、全て図２７（ｂ）としてもよい。この場合、基地局装置２０からスーパーフレームに送信されるＲＳＵパケットのうち、先頭のＲＳＵパケットのセキュリティフレームが図２７（ａ）に、残りのＲＳＵパケットのセキュリティフレームがすべて図２７（ｂ）に従う。

また、図４においてセキュリティフレームが、ＲＳＵパケットに収まるように説明したが、基地局装置２０が複数のアプリケーションデータを連結して送信する場合、アプリケーションデータ単位で、セキュリティフレームを構成するようにしてもよい。この場合、基地局装置２０からスーパーフレームに送信されるアプリケーションデータのうち、先頭に送信されるアプリケーションデータが、図２７（ａ）に従ったセキュリティフレームの「ＡＰＰデータ」にセットされ、残りのアプリケーションデータが、図２７（ｂ）に従った異なるセキュリティフレームの「ＡＰＰデータ」にセットされる。この後、パケット単に分割され、ＲＳＵパケットとして送信される。

図１８は、「フレーム認証リスト」にセットする、認証データのリストの構成例を示す。後続するセキュリティフレームのＭＡＣ値をフレーム番号順に並べたリストである。サイズは、（認証データのバイト数）×（総フレーム数−１）となる。セットされるＭＡＣ値は、図２７（ｂ）における「ＭＡＣ」にセットされるＭＡＣ値と同じである。なお、ＭＡＣ値でなく、ハッシュ値のリストとしてもよい。この場合、ハッシュ演算の対象は、「メッセージＩＤ」「フレーム番号」、「最終フレーム番号」およびペイロードである。

説明の便宜上、すべての基地局装置２０は、図３に従ったＲＳＵパケット送信するものとする。また、ＲＳＵパケット１のセキュリティフレームの公開鍵証明書の検証および署名検証処理を、単に署名検証と呼び、ＲＳＵパケット１〜５のセキュリティフレームに対するＭＡＣ認証処理を、ＭＡＣ認証と呼ぶ。受信したＲＳＵパケットのセキュリティフレームのメッセージタイプ（ＭＴ）が認証付き暗号化データ形式（＝２）のとき、復号後に、署名検証およびＭＡＣ検証は実行される。

図２８は、検証部１１５１構成例を示す。構成例に係る検証部１１５１は、ハッシュ演算部１１５１ａ、ＥＣＤＳＡ検証部１１５１ｂ、ＲＳＵ検証情報保持部１１５１ｆ、ＭＡＣ検証部１１５１ｄ、検証制御部１１５１ｅを含む。

ＲＵＳ検証結果の格納について説明する。ＲＳＵパケットを受信すると、検証制御部１１５１ｅは、ＲＳＵ検証情報保持部１１５１ｆに保持されているＲＳＵ検証情報に含まれるダイジェストと、当該ＲＳＵパケットの公開鍵証明書のダイジェストの一致を確認する。当該ＲＳＵパケットの公開鍵証明書のダイジェストとは、ＲＳＵパケット１のとき、当該ＲＳＵパケットに含まれる公開鍵証明書を入力として、ハッシュ演算部１１５１ａで算出したハッシュ値である。また、ＲＳＵパケット２〜５のとき、当該パケットの「ダイジェスト」にセットされているダイジェストである。ＲＳＵ検証情報保持部１１５１ｆに一致するダイジェストが保持されていると、検証制御部１１５１ｅは当該ダイジェストを含むＲＳＵ検証情報から、検証結果とメッセージＩＤを取得する。そして、当該ＲＳＵパケットの検証結果として、ＭＡＣ検証結果と取得した検証結果とメッセージＩＤを受信処理部１６１に通知する。

このようにＭＡＣ検証の結果と、直前に行った同じ基地局装置２０から送信されたＲＳＵパケットのＲＳＵ検証結果とそのＲＳＵパケットの識別情報であるメッセージＩＤを、ＲＳＵパケットの検証結果として通知することで、ＭＡＣ検証終了後に検証結果を出力できるようになり車車間通信のパケットの検証結果とほぼ同等の遅延にて検証結果を提供できる。データの活用の有無は受信処理部１６１にて判断する。なお、車車間通信のパケットの検証は、ＭＡＣ値の一致の確認のみであるため説明は詳細な省略する。

図２９は、構成例に係る検証部１１５１が用いられる端末装置１０のＲＳＵパケットの受信処理を示すフローチャートである。ＲＦ部１２はＲＳＵパケットを受信する。このＲＳＵパケットは変復調部１３、ＭＡＣフレーム処理部１４を経て、セキュリティ処理部１５に出力される。セキュリティ処理部１５の検証部１１５１がＲＳＵパケットを受け取ると処理が開始される。検証制御部１１５１ｅはＲＳＵパケットを受け取るとＭＡＣ検証部１１５１ｄにＭＡＣ検証を開始するように指示する（Ｓ１１０）。そして受け取ったＲＳＵパケットのフレーム番号を確認する（Ｓ１１１）。フレーム番号が０の場合（Ｓ１１１のＹ）、ハッシュ演算部１１５１ａに当該ＲＳＵパケットに配置された公開鍵証明書のダイジェストの演算を指示する。指示を受けたハッシュ演算部１１５１ａは公開鍵証明書のダイジェストを演算して求める（Ｓ１１２）。検証制御部１１５１ｅは、ハッシュ演算部１１５１ａが演算して求めた公開鍵証明書のダイジェストと、ＲＳＵ検証情報保持部１１５１ｆに保持される公開鍵証明書のダイジェストとを比較し、一致するか否か判定する（Ｓ１１３）。

ダイジェストが一致しない、または、ダイジェストが一致して検証結果がデータ否認またはＲＳＵ否認の場合（Ｓ１１３のＮ）、検証制御部１１５１ｅはＥＣＤＳＡ検証部１１５１ｂの動作状態をチェックする（Ｓ１１７）。ＥＣＤＳＡ検証部１１５１ｂが待機中の場合（Ｓ１１７のＹ）、検証制御部１１５１ｅはＥＣＤＳＡ検証部１１５１ｂに当該ＲＳＵパケットのＲＳＵ認証の開始を指示し（Ｓ１１４）、当該ＲＳＵパケットに対する処理を終了する。一方、ＥＣＤＳＡ検証部１１５１ｂが稼働中の場合（Ｓ１１７のＮ）、検証制御部１１５１ｅはして受信されたＲＳＵパケットのＲＳＵ検証を断念し、当該ＲＳＵパケットに対する処理を終了する。

ダイジェストが一致し、かつ、検証結果がＲＳＵ承認の場合（Ｓ１１３のＹ）、検証制御部１１５１ｅは当該ダイジェストを含むＲＳＵ検証情報がＲＳＵ検証情報保持部１１５１ｆに保持されてからの経過時間を確認する（Ｓ１１６）。これはＲＳＵ検証が成功してからの経過時間を確認することになる。予め定めた所定の時間を経過している場合（Ｓ１１６のＹ）、当該ＲＳＵパケットのＲＳＵ検証を試みるためステップＳ１４に移行する。ステップＳ１１１にてフレーム番号が０以外の場合（Ｓ１１１のＮ）、ＲＳＵ検証は必要ないと判断し、当該ＲＳＵパケットに対する処理を終了する。予め定めた所定の時間を経過していない場合（Ｓ１１６のＮ）、処理は終了される。

図３０は、ＥＣＤＳＡ検証部１１５１ｂにおけるＲＳＵパケットのＲＳＵ検証処理を示すフローチャートである。ＲＳＵパケット１を対象とする。ＥＣＤＳＡ検証部１１５１ｂは検証制御部１１５１ｅからＲＳＵパケットのＲＳＵ認証開始の指示を受けると、ＥＣＤＳＡ検証部動作状態を稼働中に変更する（Ｓ１３０）。そして、記憶部１１５３に格納されている認証鍵を取得して当該ＲＳＵパケットに含まれる公開証明書の検証を行う（Ｓ１３１）。当該検証が成功した場合（Ｓ１３１のＹ）、当該公開鍵証明書に含まれる公開鍵を用いて、当該ＲＳＵパケットに含まれる署名の検証を行う（Ｓ１３２）。当該検証が成功した場合（Ｓ１３２のＹ）、ＲＳＵ検証結果をＲＳＵ承認としたＲＳＵ検証情報によって、ＲＳＵ検証情報保持部１１５１ｆに格納されているＲＵＳ検証情報に上書きする（Ｓ１３３）。このとき経過時間はリセットされる。当該ＲＳＵパケットに含まれる署名検証が失敗した場合（Ｓ１３２のＮ）、ＲＳＵ検証結果をデータ否認としたＲＳＵ検証情報によって、ＲＳＵ検証情報保持部１１５１ｆに格納されているＲＵＳ検証情報に上書きする（Ｓ１３４）。またはステップＳ１３１にて当該ＲＳＵパケットに含まれる公開鍵証明書の検証が失敗した場（Ｓ１３１のＮ）、ＲＳＵ検証結果をＲＳＵ否認としたＲＳＵ検証情報によって、ＲＳＵ検証情報保持部１１５１ｆに格納されているＲＵＳ検証情報に上書きする（Ｓ１３５）。ステップＳ１３３、ステップ１３４またはステップＳ１３５が終了すると、ＥＣＤＳＡ検証部動作状態を待機中に変更して（Ｓ１３６）、ＲＳＵ検証の処理を終了する。

図３１は、ＭＡＣ検証部１１５１ｄにおけるＲＳＵパケットのＭＡＣ検証処理を示すフローチャートである。ＭＡＣ検証部１１５１ｄは検証制御部１１５１ｅからＲＳＵパケットのＭＡＣ認証開始の指示を受けると、当該ＲＳＵパケットの鍵ＩＤにしたがって記憶部１１５３に格納されている通信鍵を取得する（Ｓ１４０）。ＭＡＣ検証部１１５１ｄは取得した通信鍵を用いて当該ＲＳＵパケットのＭＡＣの演算対象に対するＭＡＣ値を演算する（Ｓ１４１）。そして、演算によって得たＭＡＣ値と、当該ＲＳＵパケットに含まれるＭＡＣ値を比較する（Ｓ１４２）。２つのＭＡＣ値が一致する場合（Ｓ１４２のＹ）、当該ＲＳＵパケットがＲＳＵパケット１のとき、ハッシュ演算部１１５１ａから当該ＲＳＵパケットに含まれる公開鍵証明書のダイジェストを取得する。当該ＲＳＵパケットがＲＳＵパケット２〜５のとき、当該ＲＳＵパケットに含まれるダイジェストを取り出す。ＲＳＵ検証情報保持部１１５１ｆに保持される公開鍵証明書のダイジェストと取得したダイジェストの比較し、一致するか否か判定する（Ｓ１４３）。

両者が一致する場合（Ｓ１４３のＹ）、ＭＡＣ検証部１１５１ｄは当該ＲＳＵパケットのＭＡＣ検証結果（承認）とＲＳＵ検証情報保持部１１５１ｆに保持されるＲＳＵ検証結果とメッセージＩＤを受信処理部１６１に対して通知する（Ｓ１４４）。両者が一致しない場合（Ｓ１４３のＮ）、当該ＲＳＵパケットのＭＡＣ検証結果（承認）とＲＳＵ検証否認を受信処理部１６１に対して通知する（Ｓ１４５）。ステップＳ１４２において、ＭＡＣ検証が失敗（否認）すると（Ｓ１４２のＮ）、公開鍵証明書のダイジェストが一致すれば（Ｓ１４６のＹ）、ＭＡＣ検証部１１５１ｄは当該ＲＳＵパケットのＭＡＣ検証結果（否認）とＲＳＵ検証情報保持部１１５１ｆに保持されるＲＳＵ検証結果とメッセージＩＤを受信処理部１６１に対して通知する（Ｓ１４７）。

両者が一致しない場合（Ｓ１４６のＮ）、当該ＲＳＵパケットのＭＡＣ検証結果（否認）とＲＳＵ検証否認を受信処理部１６１に対して通知する（Ｓ１４８）。ステップＳ１４４、Ｓ１４５、Ｓ１４７またはＳ１４８のいずれかによって、受信処理部１６１に対して検証結果が通知されるとＭＡＣ検証の処理が終了する。なお、検証結果の通知にあわせて、ＲＳＵパケットに含まれるアプリケーションデータは受信処理部１６１に提供される。受信処理部１６１は、２つの検証結果に基づいて、受け取ったアプリケーションデータを、予め設定された規則にしたがい処理する。たとえば、双方が認証された場合のみアプリケーションデータを採用してもよいし、２つの検証結果にうち、１つが承認で他方が否認または不定のとき、未認証である旨のフラグを立てて通知部１６２に渡してもよいし、メッセージに含まれる情報の重要度に応じて両者を使い分けしてもよい。

通知部１６２は未認証である旨のフラグが立っている情報を受領した場合、未認証の情報であることをユーザに認識させる態様で、その情報をユーザに通知することができる。なお、機器管理情報は重要データ扱いであることが望ましい。この場合、受信処理部１６１は危機管理情報を取り出したＲＳＵパケットのメッセージＩＤと機器管理情報とＭＡＣ検証結果を保持し、後続のＲＳＵパケットに対するアプリケーションデータとともに提供されるＲＳＵ認証結果とメッセージデータを手確認して保持している機器管理情報を採用するかどうかを決定する。２つのメッセージＩＤが一致して、ＲＳＵ認証が承認のとき危機管理情報を採用する。メッセージＩＤが一致してＲＳＵ認証が承認でないとき、および、保持するメッセージＩＤを受け取ったメッセージＩＤを追い越したとき、保持している機器管理情報は破棄される。このようにすることで、重要なデータは、ＲＳＵ認証によって承認されたＲＳＵパケットらのみ取り出せるようにすることができる。

以上で説明した認証１は、次のようにまとめられてもよい。
（１）路側機（ＲＳＵ）の送信エリアに達した車載器がエリアに到達したとき署名検証（公開鍵証明書とフレームへの署名検証、以下、ＲＵＳ認証と呼ぶ）を行い、その後ＭＡＣ検証（以下、フレーム認証と呼ぶ）のみに切り換える。
（２）通信エリアへの到達は、ＲＳＵ認証済みのＲＳＵの公開鍵証明書のダイジェスト（公開鍵証明書のボディのハッシュ値またはその一部、あるいは、公開鍵証明書の公開鍵またはその一部、証明書の識別番号、付与対象の識別情報（機器ＩＤ）等）の一致。
（３）ＲＳＵ認証済み路側機のダイジェスト確認とＭＡＣ検証結果をもって、フレームを承認する。
（４）ＲＵＳ認証の有効時間を設定し、一定期間毎に再認証を行う。再認証処理の期間は先のＲＳＵ認証の結果を持ってＭＡＣ検証結果は正当とする。

また、認証２は、次のようにまとめられてもよい。
（１）ＭＡＣ検証を随時行う。
（２）ＲＳＵから送信されるフレームとＲＳＵ認証済みＲＳＵの公開鍵証明書のダイジェストが一致する場合、ＭＡＣ検証結果に付加して通知する。
（３）ＲＳＵ認証によって承認された路側機のダイジェスト情報を保持する。ＲＵＳ認証は、定期的に更新する。

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

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

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

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

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

（実施例３）
次に、本発明の実施例３を説明する。実施例３は、データを分割する状況下において、セキュリティ処理を簡易にすることを目的とする。これまでは、データを分割してからＨＡＳＨリストを生成していた。前述のごとく、ＨＡＳＨリストのサイズは、分割されたデータの数に依存する。つまり、当該サイズは、可変値であり、固定値ではない。そのため、ＨＡＳＨリストのサイズが大きくなることによって、ひとつのパケット信号に格納できなくなった場合に、さらにデータを分割し、ＨＡＳＨリストが再度作成される。このような処理を簡易にするために、実施例３に係る基地局装置は、データを分割する前にＨＡＳＨリストを生成し、ＨＡＳＨリストが付加されたデータを分割する。データの数は入力時に認識されるので、ＨＡＳＨリストのサイズは、その時点で固定される。その結果、分割処理においてＨＡＳＨリストのサイズは、固定値と見なされるので、処理が簡易になる。実施例３に係る通信システム５００は、図１と同様のタイプであり、基地局装置２０は、図２０と同様のタイプであり、端末装置１０は、図２１と同様のタイプである。以下では、差異を中心に説明する。

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

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

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

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

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

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

（実施例４）
これまでの実施例３に係る基地局装置２０は、ＨＡＳＨリストと先頭のデータとを同一のパケット信号に格納しているが、これらを別のパケット信号に含めてもよい。つまり、セキュリティ処理部２５は、複数種類のデータが含まれていないパケット信号にＨＡＳＨリストを含める。そのため、データが含まれたパケット信号と、ＨＡＳＨリストが含まれたパケット信号とが別に生成される。図３６（ａ）−（ｆ）は、各レイヤにおける別の処理の概要を示す。これらは、図３５（ａ）−（ｆ）と同様に示されているので、差異のみを説明する。図３６（ｃ）は、セキュリティ処理がなされたデータを示す。ここで、ＨＡＳＨリストは、Ｄ１に連結されずに、別々に構成されている。

図３７（ａ）−（ｂ）は、本発明の実施例４に係る路車間通信パケット信号に含まれるセキュリティフレームのデータ構造の一例を示す。図３７（ａ）は、図３５（ｃ）における先頭のデータのフォーマットを示し、図３７（ｂ）は、図３５（ｃ）における２番目移行のデータのフォーマットを示す。ここで、図３７（ａ）のＭＡＣ方式ペイロードと、図３７（ｂ）の署名方式ペイロードとが、署名・ハッシュ演算の対象になる。

図３８は、本発明の実施例４に係る路車間通信パケット信号に含まれるセキュリティフレームのデータ構造の別の一例を示す。これは、図３５（ｅ）におけるデータのフォーマットを示す。ここで、ＭＡＣ方式ペイロードがＭＡＣの対象であり、Ｎｏｎｃｅ、ペイロード長、ＭＡＣ方式ペイロードが暗号化の対象である。

本発明の実施例によれば、データを分割する前にＨＡＳＨリストを生成するので、分割処理において、ＨＡＳＨリストを固定量のデータとして扱うことができる。また、ＨＡＳＨリストが固定量のデータとして扱われることによって、処理を簡易にできる。また、データが含まれたパケット信号とは別に、ＨＡＳＨリストが含まれたパケット信号を生成するので、ＨＡＳＨリストとは関係なく、データが含まれたパケット信号を生成できる。

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

本発明の一態様の概要は、次の通りである。本発明のある態様の通信装置は、複数の共通鍵が含まれた部分共通鍵テーブルを複数結合することによって形成されるべき共通鍵テーブルを管理する管理部と、管理部において管理されている共通鍵テーブルのうち、いずれかの共通鍵を使用することによって、データに対するセキュリティ処理を実行する処理部と、処理部においてセキュリティ処理がなされたデータを送信あるいは受信する通信部とを備える。管理部は、共通鍵テーブルに新たな部分共通鍵テーブルを追加することによって、共通鍵テーブルを更新する。

この態様によると、共通鍵テーブルをまとめて更新するのではなく、部分共通鍵テーブルを追加するように更新するので、部分共通鍵テーブルの個別性が高められ、一部の部分共通鍵テーブルが漏洩した場合であっても、共通鍵テーブルの全体が漏洩する可能性を低減できる。

管理部において管理される共通鍵テーブルを形成するために結合可能な部分共通テーブル数が定められており、管理部は、結合可能な部分共通鍵テーブル数に達するまで、共通鍵テーブルの更新のために、新たな部分共通鍵テーブルを追加し、結合可能な部分共通鍵テーブル数に達してから、共通鍵テーブルの更新のために、共通鍵テーブルに既に含まれた部分共通鍵テーブルを新たな部分共通鍵テーブルによって置き換えてもよい。この場合、共通鍵テーブルのサイズを超えるまでは、部分共通鍵テーブルを追加し、共通鍵テーブルのサイズに達すると、部分共通鍵テーブルを置き換えるので、共通鍵テーブルのサイズを制限できる。

本発明の別の態様もまた、通信装置である。この装置は、共通鍵暗号方式によるセキュリティ処理がなされたデータを受信する受信部と、共通鍵暗号方式における共通鍵を管理する管理部と、管理部において管理されている共通鍵のうち、受信部において受信したデータに対して使用された共通鍵によって、セキュリティ処理の受信処理を実行する処理部とを備える。管理部は、受信部において受信したデータに対して使用された共通鍵を未管理である場合、その旨を通知する。

この態様によると、共通鍵を記憶していない場合、その旨を運転者に通知するので、共通鍵の更新を運転者に促すことができる。

管理部は、受信部において受信したデータに対して使用された共通鍵を未管理である場合、共通鍵の更新を要求してもよい。この場合、共通鍵を記憶していない場合、共通鍵の更新を要求するので、新たな共通鍵を使用可能にできる。

管理部は、複数の共通鍵が含まれた部分共通鍵テーブルを複数結合することによって形成されるべき共通鍵テーブルを管理しており、共通鍵テーブルに新たな部分共通鍵テーブルを追加することによって、共通鍵テーブルを更新してもよい。

本発明のさらに別の態様は、端末装置である。この装置は、発信元固有の公開鍵証明書と公開鍵証明書に含まれる公開鍵で検証可能な署名と共通鍵暗号方式によるメッセージ認証子を付加した第１のパケット信号と、発信元固有の公開鍵証明書を特定する情報と共通鍵暗号方式によるメッセージ認証子を付加した第２のパケット信号と、を受信して、検証を行う端末装置であって、無線装置から報知される複数のパケット信号を受信する受信部と、第１のパケット信号に含まれる署名を検証するための第１検証部と、第１のパケット信号または第２のパケット信号に含まれるメッセージ認証子を検証するための第２検証部と、第１検証部で検証された第１のパケット信号に含まれる公開鍵証明書のダイジェストを保持するダイジェスト保持部と、を備える。第１検証部は、第１のパケット信号を受信すると受信したパケット信号に含まれる公開鍵証明書と署名の検証とを行い、検証が成功すると該公開鍵証明書のダイジェストをダイジェスト保持部に保持させ、第２検証部は、第１のパケット信号または第２のパケット信号を受信すると受信したパケット信号に含まれるメッセージ認証子の検証を行い、受信したパケット信号に含まれる公開鍵証明書のダイジェストがダイジェスト保持部に保持され、かつ、検証に成功したとき、該パケット信号は正当であると通知する。

本発明のさらに別の態様もまた、端末装置である。この装置は、発信元固有の公開鍵証明書と公開鍵証明書に含まれる公開鍵で検証可能な署名と共通鍵暗号方式によるメッセージ認証子を付加した第１のパケット信号と、発信元固有の公開鍵証明書のダイジェストと共通鍵暗号方式によるメッセージ認証子を付加した第２のパケット信号と、を受信して、検証を行う端末装置であって、無線装置から報知される複数のパケット信号を受信する受信部と、第１のパケット信号に含まれる署名を検証するための第１検証部と、第１のパケット信号または第２のパケット信号に含まれるメッセージ認証子を検証するための第２検証部と、第１検証部で検証された第１のパケット信号に関する検証結果を保持する検証情報保持部と、を備える。第１検証部は、第１のパケット信号を受信すると受信したパケット信号に含まれる公開鍵証明書と署名の検証とを行い、少なくとも検証結果と該公開鍵証明書のダイジェストとを含む検証情報によって、検証情報保持部に保持される検証情報を更新し、第２検証部は、第１のパケット信号または第２のパケット信号を受信すると受信したパケット信号に含まれるメッセージ認証子の検証を行い、受信したパケット信号に含まれる公開鍵証明書のダイジェストに対応する検証情報が検証情報保持部に保持されるとき、メッセージ認証子の検証結果と共に検証情報保持部に保持される第１検証部における検証結果を添付して通知する。

本発明のさらに別の態様は、通信装置である。この装置は、複数種類のアプリケーションデータを受け取って、受け取ったアプリケーションデータの1つと発信元固有の公開鍵証明書と公開鍵証明書に含まれる公開鍵で検証可能な署名と共通鍵暗号方式によるメッセージ認証子を含む第１のメッセージと、受け取ったアプリケーションデータの1つと発信元固有の公開鍵証明書を特定する情報と共通鍵暗号方式によるメッセージ認証子を含む第２のメッセージと、を送信する通信装置であって、第１のメッセージおよび１つ以上の第２のメッセージを１つのグループとして送信し、第１のメッセージは、１つのグループに属する第１のメッセージおよび１つ以上の第２のメッセージにそれぞれ含まれるアプリケーションデータに対するハッシュあるいはメッセージ認証子の認証用リストを含み、署名は認証用リストに対する署名であり、第１のメッセージのメッセージ認証子は、当該メッセージに含まれる公開鍵証明書とは認証用リストと署名とアプリケーションデータに対するものであり、第２のメッセージのメッセージ認証子は、当該メッセージに含まれる公開鍵証明書の特定情報とアプリケーションデータに対するものである。

第１のメッセージに含まれる公開鍵証明書と認証用リストと署名とアプリケーションデータとメッセージ認証子を暗号化して、送信してもよい。

第２のメッセージの一部あるいは全てに対して、当該メッセージに含まれる公開鍵証明書の特定情報とアプリケーションデータとメッセージ認証子を暗号化して、送信してもよい。

第１のメッセージおよび第２のメッセージを、１つ以上のパケット信号に分割して、送信してもよい。

認証用リストを含むパケット信号には、アプリケーションデータを含まない。

本発明のさらに別の態様もまた、通信装置である。この装置は、複数種類のデータを入力する入力部と、入力部において入力した複数種類のデータのそれぞれに対して導出した各データの代表値が含まれたリストを生成する生成部と、生成部において生成したリストと、入力部において入力した複数種類のデータとを複数のパケット信号へ分割する分割部と、分割部において分割した複数のパケット信号を報知する報知部と、を備える。

分割部は、複数種類のデータが含まれていないパケット信号にリストを含めてもよい。

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

本発明によれば、共通鍵暗号化方式を用いた通信システムのセキュリティを効率的に向上させることができる。

Claims (2)

1. 発信元固有の公開鍵証明書と、前記公開鍵証明書に含まれない発信元固有の機器ＩＤと、前記公開鍵証明書に含まれる公開鍵で検証可能な署名と、共通鍵暗号方式によるメッセージ認証子とを付加した第１のパケット信号と、
   前記第１のパケット信号に含まれる機器ＩＤと同じ機器ＩＤと、共通鍵暗号方式によるメッセージ認証子とを付加した第２のパケット信号と、を受信して、検証を行う通信装置であって、
   無線装置から報知される複数のパケット信号を受信する受信部と、
   前記第１のパケット信号に含まれる署名を検証するための第１検証部と、
   前記第１のパケット信号または第２のパケット信号に含まれるメッセージ認証子を検証するための第２検証部と、
   前記第１検証部で検証された前記第１のパケット信号に含まれる機器ＩＤを保持する保持部と、を備え、
   前記第１検証部は、前記第１のパケット信号を受信すると受信した前記パケット信号に含まれる前記公開鍵証明書と署名の検証を行い、検証が成功すると当該機器ＩＤを前記保持部に保持させ、
   前記第２検証部は、前記第１のパケット信号または第２のパケット信号を受信すると受信したパケット信号に含まれるメッセージ認証子の検証を行い、受信したパケット信号に含まれる前記機器ＩＤが前記保持部に保持され、かつ、前記検証に成功したとき、該パケット信号は正当であると通知することを特徴とする通信装置。
2. 発信元固有の公開鍵証明書と、前記公開鍵証明書に含まれない発信元固有の機器ＩＤと、前記公開鍵証明書に含まれる公開鍵で検証可能な署名と、共通鍵暗号方式によるメッセージ認証子とを付加した第１のパケット信号と、
   前記第１のパケット信号に含まれる機器ＩＤと同じ機器ＩＤと、共通鍵暗号方式によるメッセージ認証子とを付加した第２のパケット信号と、を受信して、検証を行う通信装置であって、
   無線装置から報知される複数のパケット信号を受信する受信部と、
   前記第１のパケット信号に含まれる署名を検証するための第１検証部と、
   前記第１のパケット信号または第２のパケット信号に含まれるメッセージ認証子を検証するための第２検証部と、
   前記第１検証部で検証された前記第１のパケット信号に関する検証結果を保持する検証情報保持部と、を備え、
   前記第１検証部は、前記第１のパケット信号を受信すると受信した前記パケット信号に含まれる前記公開鍵証明書と署名の検証を行い、少なくとも検証結果と前記機器ＩＤとを含む検証情報によって、前記検証情報保持部に保持される検証情報を更新し、
   前記第２検証部は、前記第１のパケット信号または第２のパケット信号を受信すると受信したパケット信号に含まれるメッセージ認証子の検証を行い、受信したパケット信号に含まれる前記機器ＩＤに対応する検証情報が前記検証情報保持部に保持されるとき、メッセージ認証子の検証結果と共に前記検証情報保持部に保持される第１検証部における検証結果を添付して通知することを特徴とする通信装置。