JP6187888B2 - 処理装置 - Google Patents

Description

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

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

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

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

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

本発明のある態様の無線装置は、第１フレームと、少なくとも一つの第２フレームを一単位として送信する無線装置であって、前記第１フレームは、電子署名の検証に使用する公開鍵証明書、ダイジェストリスト、当該ダイジェストリストに対する電子署名、アプリケーションデータを含む。前記第２フレームは、前記公開鍵証明書を特定するための情報、アプリケーションデータを含む。前記ダイジェストリストは、一単位を構成する前記第１フレームおよび前記第２フレームにそれぞれ含まれるアプリケーションデータごとに生成された複数のダイジェストを含む。

本発明の別の態様もまた、無線装置である。この装置は、無線装置であって、他の無線装置から送信された一単位を構成し、それぞれがアプリケーションデータを含む第１フレームおよび少なくとも一つの第２フレームを受信し、前記第１フレームは、電子署名の検証に使用する公開鍵証明書、同じ一単位を構成する前記第１フレームおよび前記第２フレームにそれぞれ含まれるアプリケーションデータごとに生成された複数のダイジェストを含むダイジェストリスト、当該ダイジェストリストに対する電子署名、アプリケーションデータを含む。前記第２フレームは、前記公開鍵証明書を特定するための情報、アプリケーションデータを含む。前記第１フレームの一部を欠損して受信し、当該第１フレームのダイジェストリストに欠損がなければ、前記第２フレームに含まれるアプリケーションデータのダイジェストを演算し、そのダイジェストと、前記第１フレームに含まれるダイジェストリスト内の対応するダイジェストとが一致する場合、前記アプリケーションデータを正当と判定する。

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

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

本発明の実施例に係る通信システムの構成を示す図である。 図２（ａ）−（ｄ）は、通信システムにおいて規定されるスーパーフレームのフォーマットを示す図である。 図３（ａ）−（ｂ）は、サブフレームの構成を示す図である。 図４（ａ）−（ｄ）は、通信システムにおいて規定される各レイヤのフレームのフォーマットを示す図である。 図５（ａ）−（ｂ）は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造を示す図である。 実施例に係る基地局装置の構成を示す図である。 図７（ａ）−（ｄ）は、実施例に係る基地局装置での送信処理におけるデータの流れを示す図である（図５（ａ）−（ｂ）のデータ構造を採用）。 実施例に係る車両に搭載された端末装置の構成を示す図である。 図９（ａ）−（ｄ）は、実施例に係る端末装置での受信処理におけるデータの流れを示す図である（図５（ａ）−（ｂ）のデータ構造を採用）。 図１０（ａ）−（ｃ）は、実施例に係る端末装置での受信処理におけるデータの別の流れを示す図である（図５（ａ）−（ｂ）のデータ構造を採用）。 図１１（ａ）−（ｂ）は、ＲＳＵパケットに含まれるセキュリティフレームの、改善されたデータ構造を示す図である。 図１２（ａ）−（ｄ）は、実施例に係る端末装置での受信処理における、改善されたデータの流れを示す図である（図１１（ａ）−（ｂ）のデータ構造を採用）。 図１３（ａ）−（ｄ）は、実施例に係る端末装置での受信処理における、改善されたデータの別の流れを示す図である（図１１（ａ）−（ｂ）のデータ構造を採用）。

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

しかしながら、すべてのパケット信号に公開鍵証明書および電子署名を付加するとデータに対するオーバーヘッドが、共通鍵暗号方式におけるメッセージ認証コードのオーバーヘッドに比べて大きくなる。この対策として特定の基地局装置から送信される一連のデータ群を含む複数のパケット信号に対して、公開鍵証明書および電子署名を１つ付加してオーバーヘッドを減らす方法が考えられる。しかしながら、１つの署名の対象となるデータが複数のパケット信号に跨ると、通信区間におけるパケット信号の欠落が発生した場合に特定の基地局装置から送信されるデータ群がまとめて失われることになる。

以下に示す実施例はこうした状況に鑑みてなされたものであり、その目的は、セキュリティを向上させつつ、パケット信号の欠落に対して耐性のある送信方式と、その受信方式を提供することにある。

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

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

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

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

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

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

図２（ｂ）は、第１基地局装置２０ａによって生成されるスーパーフレームの構成を示す。第１基地局装置２０ａは、基地局装置２０のうちの任意の一つに相当する。第１基地局装置２０ａは、第１サブフレームの先頭部分に路車送信期間を設定する。路車送信期間とは、基地局装置がパケット信号を報知する期間である。第１基地局装置２０ａがパケット信号を報知する場合、第１基地局装置２０ａは必ず、第１サブフレームの先頭期間である路車送信期間に報知する。

一方、第１基地局装置２０ａの電波到達距離内に配置される他の基地局装置２０、および当該電波到達距離内に存在する端末装置１０は、その路車送信期間にパケット信号を報知しない。第１サブフレームの路車送信期間に後続する車車送信期間において端末装置１０がパケット信号を報知可能に規定される。第１基地局装置２０ａは、路車送信期間を除く期間に車車送信期間を設定する。即ち、第１サブフレームの後半、および第２サブフレームから第Ｎサブフレームに車車送信期間を設定する。

図２（ｃ）は、第２基地局装置２０ｂによって生成されるスーパーフレームの構成を示す。第２基地局装置２０ｂは、第１基地局装置２０ａと異なる基地局装置２０である。第２基地局装置２０ｂは、第２サブフレームおよび第３のサブフレームのそれぞれの先頭部分に路車送信期間を設定する。また第２基地局装置２０ｂは、第２サブフレームおよび第３のサブフレームのそれぞれの路車送信期間の後段、第１サブフレーム、および第４サブフレームから第Ｎサブフレームに車車送信期間を設定する。第２基地局装置２０ｂのように、２つ以上のサブフレームに対して路車送信期間を設定することにより、スーパーフレーム毎に送信できるデータ量を増やすことができる。

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

複数の基地局装置２０は、互いに異なったサブフレームを選択し、選択したサブフレームの先頭部分に路車送信期間を設定する。このように各基地局装置２０は、自身がパケット信号を報知するために１つのサブフレームの路車送信期間を独占することにより、各基地局装置固有の報知期間をスーパーフレーム内に設けている。

スーパーフレーム内に設定可能なサブフレームの数は有限（本実施例では８）である。そこで複数の基地局装置２０のそれぞれの電波到達距離を考慮してスーパーフレームを選択すれば、基地局装置２０の設置台数を制限することはない。またスーパーフレーム内の全てのサブフレームに対して路車送信期間が設定されなくてもよい。なお、電波到達距離外の基地局装置２０は、電波到達距離内で規定されたスーパーフレームと同一のスーパーフレームに路車送信期間を設定してもよいし、異なるスーパーフレームに路車送信期間を設定してもよい。

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

図４（ｃ）は、ＬＬＣレイヤのフレームフォーマットを示す。このフレームは、図４（ｂ）のＭＳＤＵに格納される。図示のごとくＬＬＣレイヤのフレームには、ＬＬＣヘッダ、ＬＳＤＵ（ＬＬＣ Ｌａｙｅｒ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）が順に配置される。図４（ｄ）は、車車間・路車間共用通信制御情報レイヤのフレームフォーマットを示す。このフレームは、図４（ｃ）のＬＳＤＵに格納される。図示のごとく車車間・路車間共用通信制御情報レイヤのフレームには、ＩＲヘッダ、ＡＰＤＵ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）が順に配置される。

図４（ｅ）は、セキュリティレイヤのフレームフォーマットを示す。このフレームは、図４（ｄ）のＡＰＤＵに格納される。図示のごとくセキュリティレイヤのフレームには、セキュリティヘッダ（Ｓｅｃｕｒｉｔｙ Ｈｅａｄｅｒ）、アプリケーションデータ（Ａｐｐｌｉｃａｔｉｏｎ Ｄａｔａ）、セキュリティフッタ（Ｓｅｃｕｒｉｔｙ Ｆｏｏｔｅｒ）が順に配置される。以下、ＭＡＣレイヤのフレームをＭＡＣフレームといい、セキュリティレイヤのフレームをセキュリティフレームという。

図５（ａ）−（ｂ）は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造を示す。署名の対象となるセキュリティフレームの集まりをメッセージとする。図５（ａ）はメッセージの先頭に送信するセキュリティフレーム、図５（ｂ）はメッセージの先頭以外で送信するセキュリティフレームのデータ構造を示す。

図５（ａ）に示すメッセージの先頭のセキュリティフレームでは、「バージョン」、「メッセージ情報」、「ｎｏｎｓｅ」、「ペイロードデータ長」、「ペイロード」および「ＭＡＣ」が配置される。「ペイロード」には、「署名付きデータ長」、「署名付きデータ」および「被ダイジェストデータ」が配置される。「署名付きデータ」には、「公開鍵証明書」、「ダイジェスト」および「署名」が配置される。「被ダイジェストデータ」には、「アプリデータ長」、「メッセージＩＤ」、「フレームＩＤ」、「フレーム数」および「アプリケーションデータ」が配置される。なお、セキュリティヘッダは「アプリケーションデータ」より前に配置された「バージョン」−「フレーム数」であり、セキュリティフッタは「アプリケーションデータ」より後ろに配置された「ＭＡＣ」である。

図５（ｂ）に示すメッセージの先頭以外のセキュリティフレームでは、図５（ａ）に示すメッセージの先頭のセキュリティフレームにおける「署名付きデータ長」および「署名付きデータ」を、「公開鍵証明書情報」に置換した構成になっている。このように、先頭以外のセキュリティフレームにおける公開鍵証明書および署名を省略することにより、メッセージ全体のオーバーヘッドを抑制できる。

「バージョン」にはフレームのデータ構造のバージョンが設定される。「メッセージ情報」にはこのフレームの受信処理において必要な情報が設定される。例えば、セキュリティフレームにおけるデータ保護形態を示すメッセージ形式、および共通鍵暗号方式に基づく処理にて使用される鍵（以下、通信鍵という）を基地局装置２０と端末装置１０間で共有するための鍵またはその鍵を特定するための識別子が設定される。なおメッセージ形式には、平文データ形式、認証付きデータ形式および認証付き暗号化データ形式がある。認証付きデータ形式では、通信鍵を用いて「ペイロード」に対するＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）が生成され、生成されたＭＡＣが「ＭＡＣ」に設定される。認証付き暗号化データ形式では、それに加えて通信鍵を用いて「ペイロード」および「ＭＡＣ」が暗号化される。

当該通信鍵には、事前共有された共通鍵暗号方式の共通鍵、または事前共有された鍵で暗号化された乱数値が使用される。当該通信鍵は「メッセージ情報」に設定される情報によって、基地局装置２０と端末装置１０間で対応が取られる。共通鍵暗号には例えば、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）を用いることができる。本実施例では、認証付き暗号化データ形式においてＣＣＭモードにより、ＭＡＣ生成および暗号化が行われる。

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

「署名付きデータ長」には、「署名付きデータ」のバイト数が設定される。即ち、「公開鍵証明書」、「ダイジェスト」および「署名」の総バイト数が設定される。これにより、「ダイジェスト」のバイト数、および「被ダイジェストデータ」の先頭である「アプリデータ長」の配置位置を知ることができる。

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

「ダイジェスト」には、同一メッセージ内の「被ダイジェストデータ」に対するダイジェストが設定される。例えば、ハッシュ関数によって求められたハッシュ値が設定される。セキュリティフレームによるオーバーヘッドの影響を低減するため、本実施例ではメッセージ内の全てのセキュリティフレームに含められる「被ダイジェストデータ」を、「フレームＩＤ」順に配置したデータ列に対するハッシュ値が求められる。「署名」には、「ダイジェスト」に対する署名が設定される。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。

「アプリデータ長」には、「メッセージＩＤ」、「フレームＩＤ」、「フレーム数」および「アプリケーションデータ #1」の総データ長が設定される。これにより、ダイジェストの対象となるデータ長を特定できる。「メッセージＩＤ」にはメッセージＩＤが設定される。メッセージＩＤは、同一基地局装置２０から送信されるＲＳＵパケットをセキュリティレイヤで区別するために用いる識別番号である。メッセージＩＤは送信毎に１インクリメントされ、サイクリックに変化する数値（Ｎの剰余系、Ｎは自然数）である。

「フレームＩＤ」にはメッセージ内の送信順序が設定される。この送信順序は「ダイジェスト」を求めるときのデータの並び順を示す。「フレーム数」には、メッセージを構成するセキュリティフレームの数が設定される。「アプリケーションデータ」には、基地局装置２０が端末装置１０に対して報知するデータが設定される。「ＭＡＣ」には、「ペイロード」に対するＭＡＣが設定される。

「公開鍵証明書情報」は、メッセージの先頭以外のセキュリティフレームに配置される。「公開鍵証明書情報」には、メッセージの先頭のセキュリティフレームの「公開鍵証明書」に設定されている基地局装置２０固有の公開鍵証明書のシリアル番号またはダイジェストなどが設定される。本実施例はシリアル番号が設定される。これにより、発信元の基地局装置２０を特定できる。

なお認証付きデータ形式では、「署名」に署名が設定された後、ＭＡＣが生成され、生成されたＭＡＣが「ＭＡＣ」に設定される。また認証付き暗号化データ形式では、「ＭＡＣ」にＭＡＣが設定された後、さらに「ペイロード」および「ＭＡＣ」が暗号化される。

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

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

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

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

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

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

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

分割結合部２５は受信処理として、ＭＡＣフレーム処理部２４から渡されるＡＰＤＵを結合してセキュリティフレームを組み立て、セキュリティ処理部２６に出力する。また分割結合部２０５は送信処理として、セキュリティ処理部２６から渡されるセキュリティフレームを、パケット信号として送信できるサイズのＡＰＤＵに分割する。このとき、分割結合部２５は受信処理における結合で必要な結合ヘッダを、分割したセキュリティフレームの先頭に付加する。

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

セキュリティ処理部２６は、署名部２６１および共通鍵暗号部２６２を含む。本実施例では署名部２６１は公開鍵証明書を内部に記憶している。公開鍵証明書は、図示しない認証局が発行する秘密鍵と、この秘密鍵と対をなす公開鍵を含む。この秘密鍵および公開鍵証明書を基地局装置２０ごとにユニークにすることにより、共通鍵暗号方式に比べてセキュリティを高めることができる。

署名部２６１は、自身が保持する秘密鍵を用いて署名対象に対する署名を生成する。図５（ａ）に示すデータ構造では、「公開鍵証明書」および「ダイジェスト」に対する署名を生成する。共通鍵暗号部２６２は、端末装置１０と共有している通信鍵を用いて暗号対象に対するＭＡＣの生成および暗号化をする。図５（ａ）−（ｂ）に示すデータ構造では、「ペイロード」に対するＭＡＣの生成と、「ペイロード」および「ＭＡＣ」の暗号化をする。

アプリ管理部２７は受信処理として、セキュリティ処理部２６からの検証結果とアプリケーションデータを受け取り、必要に応じてネットワーク通信部２８に出力する。またアプリ管理部２７は送信処理として、ネットワーク通信部２８またはデータ生成部２９からのアプリケーションデータを、スーパーフレーム周毎に取りまとめる。送信可能なデータ数のアプリケーションデータを選択した後、アプリ管理部２７は選択したアプリケーションデータを送信順に並べて、セキュリティ処理部２６に出力する。

ネットワーク通信部２８は外部ネットワーク２００に接続される。ネットワーク通信部２８は、外部ネットワーク２００から工事や渋滞などに関する道路情報を受けつける。またネットワーク通信部２８は、アプリ管理部２７による処理結果を外部ネットワーク２００へ出力する。または当該処理結果を記憶部２１０に一時蓄積し、定期的に外部ネットワーク２００へ出力する。

データ生成部２９は、道路情報などを含むアプリケーションデータを生成する。データ生成部２９はアプリケーションデータの内容によってデータ形式を指定する。データ生成部２９は、生成したアプリケーションデータ、そのデータ長およびそのデータ形式をアプリ管理部２７に出力する。記憶部２１０は種々の情報を記憶する。制御部２１１は基地局装置２０全体の処理を制御する。

図７（ａ）−（ｄ）は、実施例に係る基地局装置２０の送信処理において、ネットワーク通信部２８またはデータ生成部２９から、ＭＡＣフレーム処理部２４に至るデータの流れを示す図である。図７（ａ）−（ｄ）に示す例では図５（ａ）−（ｂ）および図４（ｄ）のデータ構造を前提とする。図中、ＡＰＰ１−ＡＰＰ３は、アプリケーションデータを、ＳＨ１−ＳＨ３はセキュリティヘッダを、ＳＦ１−ＳＦ３はセキュリティフッタを、ＥＨ１−ＥＨ７は結合ヘッダをそれぞれ示している。添え字の数値は送信順序を示している。図７（ｃ）のＳＨ１、ＡＰＰ１、ＳＦ１によって構成されるセキュリティフレームは図５（ａ）のデータ構造にしたがい、図７（ｃ）のＳＨ２、ＡＰＰ２、ＳＦ２によって構成されるセキュリティフレームおよびＳＨ３、ＡＰＰ３、ＳＦ３によって構成されるセキュリティフレームは図５（ｂ）のデータ構造にしたがう。また、図７（ｄ）のＥＨ１−ＥＨ７で始まるデータ列が、図４（ｄ）のＡＰＤＵに格納される。

図７（ａ）は、ネットワーク通信部２８またはデータ生成部２９からアプリ管理部２７への出力を示す。アプリケーションデータがＡＰＰ１、ＡＰＰ３、ＡＰＰ２の順に、アプリ管理部２７に入力される。

図７（ｂ）は、アプリ管理部２７からセキュリティ処理部２６への出力を示す。アプリケーションデータＡＰＰ１−ＡＰＰ３は送信順に並べ替えられて、セキュリティ処理部２６へ出力される。

図７（ｃ）は、セキュリティ処理部２６から分割結合部２５への出力を示す。セキュリティ処理部２６はアプリケーションデータＡＰＰ１−ＡＰＰ３のそれぞれに対して、セキュリティヘッダＳＨ１−ＳＨ３およびセキュリティフッタＳＦ１−ＳＦ３をそれぞれ付加し、分割結合部２５へ出力する。図５（ａ）−（ｂ）のデータ構造では、先頭のセキュリティフレームに対するセキュリティヘッダＳＨ１は、先頭以外のセキュリティヘッダＳＨ２、ＳＨ３に比べてサイズが大きい。

図７（ｄ）は、分割結合部２５からＭＡＣフレーム処理部２４への出力を示す。分割結合部２５は分割処理として、サイズの大きい先頭のセキュリティフレームを５つに分割し、サイズの小さい先頭以外のセキュリティフレームを分割しない。分割結合部２５は、分割処理後のセキュリティフレームのそれぞれを、ＡＰＤＵとしてＭＡＣフレーム処理部２４へ出力する。ＭＡＣフレーム処理部２４へのＡＰＤＵの出力に先立ち、分割結合部２５は、ＡＰＤＵのそれぞれの先頭に結合ヘッダＥＨ１−ＥＨ７を付加する。

図８は、実施例に係る、車両１００に搭載された端末装置１０の構成を示す。端末装置１０は、アンテナ１１、通信ユニット１２およびアプリケーションユニット１３を備える。通信ユニット１２は、アプリケーションユニット１３から受け取ったアプリケーションデータを車車間通信によってアンテナ１１を介して報知する。また通信ユニット１２はアンテナ１１を介して、他の端末装置１０からのパケット信号を車車間通信により受信し、基地局装置２０からのパケット信号（ＲＳＵパケット）を路車間通信により受信する。通信ユニット１２は、受信したパケット信号から取り出したアプリケーションデータをアプリケーションユニット１３に提供する。また通信ユニット１２は、セキュリティフレームに含まれる署名検証およびＭＡＣ検証の結果をまとめた検証結果を報告する。

まずアプリケーションユニット１３の構成要素について説明する。アプリケーションユニット１３は、受信処理部１３１、通知部１３２、データ生成部１３３、記憶部１３４および制御部１３５を備える。

受信処理部１３１は、通信ユニット１２から受け取ったアプリケーションデータと、データ生成部１３３から受け取った自車の車両情報に基づき、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また受信処理部１３１は、受け取ったデータが画像情報であれば通知部１３２に表示させる。

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

データ生成部１３３は、図示しないＧＰＳ受信機、ジャイロスコープ、車速センサなどから供給される情報にもとづき、端末装置１０が搭載された車両１００の現在位置、進行方向、移動速度などを特定する。なお現在位置は、緯度・経度によって示される。これらの情報の特定方法は一般的な公知の技術により実現可能であるため、ここでは説明を省略する。

データ生成部１３３は、特定した情報をもとに他の端末装置１０や基地局装置２０に報知すべきデータを生成し、通信ユニット１２に出力する。またデータ生成部１３３は、特定した情報を受信処理部１３１に自車の車両情報として出力する。記憶部１３４は、アプリケーションユニット１３で使用する種々の情報を記憶する。制御部１３５は、アプリケーションユニット１３全体の処理を制御する。

次に通信ユニット１２の構成要素について説明する。通信ユニット１２は、ＲＦ部１２１、変復調部１２２、ＭＡＣフレーム処理部１２３、分割結合部１２４、セキュリティ処理部１２５、記憶部１２６および制御部１２７を備える。

ＲＦ部１２１、変復調部１２２、ＭＡＣフレーム処理部１２３および分割結合部１２４は、図６のＲＦ部２２、変復調部２３、ＭＡＣフレーム処理部２４および分割結合部２５の構成および動作と基本的に共通する。以下、これらの構成要素については、相違点を中心に説明する。記憶部１２６は、通信ユニット１２で使用する種々の情報を記憶する。制御部１２７は、通信ユニット１２全体の処理を制御する。

セキュリティ処理部１２５は、セキュリティフレームを生成または解釈する。本実施例では、基地局装置２０からのパケット受信に注目するため、そのパケット信号に格納されたセキュリティフレームを解釈する処理に注目する。セキュリティ処理部１２５は、検証部１２５１および共通鍵暗号部１２５２を含む。

共通鍵暗号部１２５２は、通信鍵を用いた受信処理を行う。即ち、通信鍵を用いて暗号化データの復号およびＭＡＣ検証を行う。図５（ａ）−（ｂ）に示すデータ構造では、通信鍵を用いて暗号化された「ペイロード」および「ＭＡＣ」の復号と、「ペイロード」に対するＭＡＣ検証を行う。ＭＡＣ検証とは、「ペイロード」に対するＭＡＣを生成し、そのＭＡＣの値と、「ＭＡＣ」に設定されている値とが一致するか否か確認する処理である。一致すれば、検証成功と判断される。

検証部１２５１は「公開鍵証明書」および「署名」を検証する。公開鍵証明書を検証するため、本実施例では検証部１２５１は、図示しない認証局が発行する公開鍵証明書を検証するための認証鍵を内部に記憶している。この認証鍵は、認証局において公開鍵証明書の署名を生成するのに用いた秘密鍵と対をなす公開鍵である。

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

図９（ａ）−（ｄ）は、実施例に係る端末装置１０での受信処理において、ＭＡＣフレーム処理部１２３から、アプリケーションユニット１３に至るデータの流れを示す図である。図９（ａ）−（ｄ）に示す例では図５（ａ）−（ｂ）のデータ構造を前提とし、図７（ｄ）のＡＰＤＵを含むＲＳＵパケットを受信した場合の例である。図９（ａ）−（ｄ）は、スーパーフレームにおける全てのパケット信号を受信できた場合の例である。図９（ａ）−（ｄ）中、ＡＰＰ１−ＡＰＰ３、ＳＨ１−ＳＨ３、ＳＦ１−ＳＦ３およびＥＨ１−ＥＨ７は、図７（ａ）−（ｄ）と同じである。

図９（ａ）は、ＭＡＣフレーム処理部１２３から分割結合部１２４への出力を示す。７つのＡＰＤＵが出力される。図９（ａ）では、スーパーフレームにおける全てのＲＳＵパケットが受信できた状態を示している。

図９（ｂ）は、分割結合部１２４からセキュリティ処理部１２５への出力を示す。分割結合部１２４は、先頭から５つのＡＰＤＵの結合ヘッダＥＨ１−ＥＨ５を取り除き、結合ヘッダＥＨ１−ＥＨ５を取り除いた各ＡＰＤＵを結合する。この結合は、結合ヘッダの情報に基づいて行われる。これにより先頭のセキュリティフレームＳＨ１、ＡＰＰ１、ＳＦ１が復元される。後続のＡＰＤＵも同様に分割結合部１２４は、結合ヘッダＥＨ６、ＥＨ７をそれぞれ取り除き、２番目のセキュリティフレームＳＨ２、ＡＰＰ２、ＳＦ２と３番目のセキュリティフレームＳＨ３、ＡＰＰ３、ＳＦ３をそれぞれ復元する。分割結合部１２４は、復元した３つのセキュリティフレームをセキュリティ処理部１２５に出力する。

図９（ｃ）は、セキュリティ処理部１２５からアプリケーションユニット１３へのアプリケーションデータの出力を示す。セキュリティ処理部１２５は、セキュリティフレームからアプリケーションデータＡＰＰ１−ＡＰＰ３を抽出し、それらを入力順にアプリケーションユニット１３へ出力する。

図９（ｄ）は、セキュリティ処理部１２５からアプリケーションユニット１３への検証結果の出力を示す。図９（ｃ）に示すアプリケーションデータＡＰＰ１−ＡＰＰ３のそれぞれに対して、セキュリティ処理部１２５は、検証成功を示す情報をアプリケーションユニット１３へ伝達する。

図１０（ａ）−（ｄ）は、実施例に係る端末装置１０での受信処理において、ＭＡＣフレーム処理部１２３から、アプリケーションユニット１３に至るデータの別の流れを示す図である。図１０（ａ）−（ｄ）に示す例でも図５（ａ）−（ｂ）のデータ構造を前提とし、図７（ｄ）のＡＰＤＵを含むＲＳＵパケットを受信した場合の例である。図１０（ａ）−（ｄ）はスーパーフレームにおいて、パケット信号が無線通信区間において欠落した場合の例である。図１０（ａ）−（ｄ）のそれぞれは、図９（ａ）−（ｄ）のそれぞれと同じ機能ブロック間のデータの流れを示している。図１０（ａ）−（ｄ）中、破線で示されるデータは欠落していることを示している。

図１０（ａ）に示すように、破線で示される３番目のＡＰＤＵを含むパケット信号が無線通信区間で欠落し、当該ＡＰＤＵが存在しない。欠落したＡＰＤＵはアプリケーションデータＡＰＰ１の一部であるＡＰＰ１（３／５）を含んでいる。

分割結合部１２４は、図１０（ａ）に示すデータを受けてセキュリティフレームを構成する。分割結合部１２４は、欠落のあるアプリケーションデータＡＰＰ１を含むセキュリティフレームを構成せずに、図１０（ｂ）に示すデータを出力する。図１０（ｂ）に示すデータでは、先頭のセキュリティフレームが欠落している。

セキュリティ処理部１２５は、図１０（ｂ）に示すデータを受けて、そのセキュリティフレームの分解および解釈を行う。セキュリティ処理部１２５は、後続のセキュリティフレームに含まれるアプリケーションデータＡＰＰ２、ＡＰＰ３を抽出することができる。セキュリティ処理部１２５は、図１０（ｃ）に示すデータを出力する。

図５（ａ）−（ｂ）に示すデータ構造では先頭のセキュリティフレームが欠落すると、セキュリティ処理部１２５は後続のセキュリティフレームの署名検証ができなくなる。全てのセキュリティフレームに対する検証失敗を通知するため、セキュリティ処理部１２５は、図１０（ｄ）に示す検証結果をアプリケーションユニット１３に出力する。なお、アプリケーションデータＡＰＰ１は欠落によりアプリケーションユニット１３に出力されず、その署名検証結果も出力されない。

このように図５（ａ）−（ｂ）に示すデータ構造では、先頭のセキュリティフレームを構成するパケット信号が欠落すると、後続のセキュリティフレームの検証が不可能になる。先頭のセキュリティフレームは後続のセキュリティフレームと異なり公開鍵証明書および署名を含む。先頭のセキュリティフレームはそれらによるオーバーヘッドが大きく、後続のセキュリティフレームよりパケット信号の欠落確率が高い。以下、セキュリティフレームのデータ構造を修正して、この問題点を改善する手法について説明する。

図１１（ａ）−（ｂ）は、ＲＳＵパケットに含まれるセキュリティフレームの、改善されたデータ構造を示す。以下、図５（ａ）−（ｂ）に示すセキュリティフレームのデータ構造との違いを説明する。図１１（ａ）はメッセージの先頭に送信するセキュリティフレーム、図１１（ａ）はメッセージの先頭に送信するセキュリティフレーム、図１１（ｂ）はメッセージの先頭以外で送信するセキュリティフレームのデータ構造を示す。図１１（ａ）では、図５（ａ）における「ダイジェスト」が「ダイジェストリスト」に変更され、「ダイジェストリスト」の前に「リスト数」が配置される。図１１（ｂ）は、図５（ｂ）と同様のデータ構造である。

「リスト数」には「ダイジェストリスト」に設定されているダイジェストの数が設定される。この値は、メッセージを構成するセキュリティフレームの数と一致する。即ち、「フレーム数」と一致する。したがって図１１（ａ）および図１１（ｂ）のデータ構造において「フレーム数」を削除することも可能であるが、図１１（ａ）および図１１（ｂ）では「フレーム数」を配置している。

「ダイジェストリスト」には、同じメッセージに属する各セキュリティフレームの「被ダイジェストデータ」に対するハッシュ値をダイジェストとして、送信順（即ち、フレームＩＤ順）に並べたリストが設定される。

図１１（ａ）に示すデータ構造のセキュリティフレームが分割されたＡＰＤＵが無線通信区間で欠落した場合でも、分割結合部１２４は先頭から可能な限りＡＰＤＵの結合を行い、セキュリティ処理部１２５に出力する。但し、欠落後のＡＰＤＵは破棄する。図１１（ｂ）に示すデータ構造のセキュリティフレームが分割されたＡＰＤＵが無線通信区間で欠落した場合には、分割結合部１２４はＡＰＤＵの結合を断念して余剰のＡＰＤＵを破棄する。

図１１（ａ）に示すデータ構造のセキュリティフレームがセキュリティ処理部１２５に入力されると、共通鍵暗号部１２５２は、入力されたセキュリティフレームに対して、通信鍵を使用して復号およびＭＡＣ検証を行う。共通鍵暗号部１２５２は、復号したデータを検証部１２５１に出力する。また、ＭＡＣ検証の結果をアプリケーションユニット１３に報告する。

検証部１２５１は、「公開鍵証明書」に設定されている公開鍵証明書の有効性を確認する。また検証部１２５１は当該公開鍵証明書から公開鍵を抽出し、その公開鍵を使用して「署名」に設定されている署名を検証する。公開鍵証明書が有効であり、かつ署名の検証に成功したとき、署名検証全体を成功とする。公開鍵証明書が無効または署名の検証に失敗したとき、署名検証全体を失敗とする。署名検証が終了すると、検証部１２５１は署名検証結果、公開鍵証明書のシリアル番号、「リスト数」に設定されているリスト数、および「ダイジェストリスト」に設定されているダイジェストリストを、記憶部１２６に一時退避する。

続いて検証部１２５１は、「被ダイジェストデータ」のダイジェストを、ハッシュ関数を用いて演算する。検証部１２５１は、記憶部１２６に一時退避させたダイジェストリストの先頭のダイジェストと、演算したダイジェストを比較する。検証部１２５１は、記憶部１２６に一時退避させた署名検証結果が成功であり、かつダイジェストの比較結果が一致するとき、最終的な署名検証結果を成功とアプリケーションユニット１３に報告する。記憶部１２６に一時退避させた署名検証結果が失敗である、またはダイジェストの比較結果が不一致のとき、最終的な署名検証結果を失敗と報告する。

図１１（ｂ）に示すデータ構造のセキュリティフレームがセキュリティ処理部１２５に入力されると、共通鍵暗号部１２５２は、入力されたセキュリティフレームに対して、通信鍵を使用して復号およびＭＡＣ検証を行う。共通鍵暗号部１２５２は、復号したデータを検証部１２５１に出力する。また、ＭＡＣ検証の結果をアプリケーションユニット１３に報告する。

検証部１２５１は、「公開鍵証明書情報」に設定されている公開鍵証明書のシリアル番号に基づいて、記憶部１２６に一時退避されたダイジェストリストを探索する。記憶部１２６に一時退避されたダイジェストリストが存在する場合、検証部１２５１は、「被ダイジェストデータ」に設定されているデータにハッシュ関数を適用して、当該データのハッシュ値を求める。このハッシュ値が当該データのダイジェストとなる。

続いて検証部１２５１は、記憶部１２６に一時退避させたダイジェストリストの「フレームＩＤ」番目のダイジェストと、求めたダイジェストを比較する。記憶部１２６に対応するダイジェストリストが存在し、その署名検証に成功し、かつダイジェストの比較結果が一致のとき、最終的な署名検証結果を成功とアプリケーションユニット１３に報告する。記憶部１２６に対応するダイジェストリストが存在しない、ダイジェストリストが存在してもその署名検証に失敗、またはダイジェストの比較結果が不一致のとき、最終的な署名検証結果を失敗と報告する。

図１１（ａ）に示すデータ構造のセキュリティフレームがセキュリティ処理部１２５に入力されたとき、共通鍵暗号部１２５２は、ＭＡＣ検証に失敗しても、復号したデータを検証部１２５１に出力する。共通鍵暗号にはＡＥＳ暗号などのブロック暗号が用いられるため、セキュリティフレームが認証付き暗号化データ形式の場合、共通鍵暗号部１２５２はブロック単位で復号またはＭＡＣ生成しつつ、処理が終了したブロックを順次、検証部１２５１に出力する。ＭＡＣ検証の結果を待たずに復号後のデータを検証部１２５１に提供することになるため、ＭＡＣ検証が失敗であっても検証部１２５１に復号後のデータが提供される。検証部１２５１は「署名付データ」からデータを抽出できる限り、署名検証を行う。セキュリティフレームが認証付きデータ形式の場合、共通鍵暗号部１２５２はブロック単位でＭＡＣ生成しつつ、処理が終了したブロックを順次、検証部１２５１に出力する。これにより認証付き暗号化データ形式と同様な結果が得られる。

図１２（ａ）−（ｄ）は、実施例に係る端末装置１０での受信処理において、ＭＡＣフレーム処理部１２３から、アプリケーションユニット１３に至る改善されたデータの流れを示す図である。図１２（ａ）−（ｄ）に示す例では図１１（ａ）−（ｂ）のデータ構造を前提とし、図７（ａ）−（ｄ）にしたがってＡＰＤＵに分割され、ＲＳＵパケットが報知されることを前提とする。図７（ｃ）のＳＨ１、ＡＰＰ１、ＳＦ１によって構成されるセキュリティフレームは図１２（ａ）のデータ構造にしたがい、図７（ｃ）のＳＨ２、ＡＰＰ２、ＳＦ２によって構成されるセキュリティフレームおよびＳＨ３、ＡＰＰ３、ＳＦ３によって構成されるセキュリティフレームは図１２（ｂ）のデータ構造にしたがう。また、図７（ｄ）のＥＨ１−ＥＨ７で始まるデータ列が、図４（ｄ）のＡＰＤＵに格納される。図１０（ａ）−（ｄ）と同様に無線通信区間においてパケット信号が欠落した場合の例である。

図１２（ａ）は、図１０（ａ）と同じである。図１２（ｂ）に示すように、先頭の図１１（ａ）に示すデータ構造のセキュリティフレームの一部が欠落している。分割結合部１２４は、この一部欠落しているセキュリティフレームも、セキュリティ処理部１２５に出力する。当該セキュリティフレームは、アプリケーションデータＡＰＰ１の一部およびセキュリティフッタＳＦ１は欠落しているが、セキュリティヘッダＳＨ１は欠落していない。セキュリティ処理部１２５はセキュリティヘッダＳＨ１から「公開鍵証明書」、「リスト数」、「ダイジェストリスト」、「署名」を取得できる。したがって、アプリケーションデータＡＰＰ２、ＡＰＰ３に対する署名検証が可能である。

アプリケーションデータＡＰＰ２、ＡＰＰ３に対する署名検証が成功した場合、図１２（ｄ）に示すように検証部１２５１はアプリケーションデータＡＰＰ２、ＡＰＰ３の署名検証結果が成功とアプリケーションユニット１３に報告する。なお、アプリケーションデータＡＰＰ１の一部欠落に伴い、アプリケーションデータＡＰＰ１の署名検証結果は報告されない。

図１３（ａ）−（ｄ）は、実施例に係る端末装置１０での受信処理において、ＭＡＣフレーム処理部１２３から、アプリケーションユニット１３に至る改善されたデータの別の流れを示す図である。図１３（ａ）−（ｄ）に示す例でも図１１（ａ）−（ｂ）のデータ構造を前提とする。図１３（ａ）−（ｄ）は、図１０（ａ）−（ｄ）および図１２（ａ）−（ｄ）に示す欠落したパケット信号と異なるパケット信号が無線通信区間において欠落した場合の例である。

図１３（ａ）に示すように、破線で示される６番目のＡＰＤＵを含むパケット信号が無線通信区間で欠落し、当該ＡＰＤＵが存在しない。欠落したＡＰＤＵはアプリケーションデータＡＰＰ２を含んでいる。図１３（ｂ）に示すように、先頭から２番目の図１１（ｂ）に示すデータ構造のセキュリティフレームが欠落する。アプリケーションデータＡＰＰ１、ＡＰＰ３の署名検証が成功した場合、図１３（ｄ）に示すように検証部１２５１はアプリケーションデータＡＰＰ１、ＡＰＰ３の署名検証結果が成功とアプリケーションユニット１３に報告する。なおアプリケーションデータＡＰＰ２の欠落に伴い、アプリケーションデータＡＰＰ２の署名検証結果は報告されない。

なおパケット信号に欠落がないときのデータの流れは、図９（ａ）−（ｄ）と同様である。アプリケーションユニット１３の受信処理部１３１は、セキュリティ処理部１２５からアプリケーションデータ、署名検証結果、およびＭＡＣ検証結果を受け取る。受信処理部１３１は、署名検証結果およびＭＡＣ検証結果に基づき、アプリケーションデータを採用するか否か決定する。署名検証結果が成功し、ＭＡＣ検証に成功したときアプリケーションデータを採用する。

最終的な署名検証結果として、自身のアプリケーションデータに対するダイジェストを含むダイジェストリストを含んだ図１１（ａ）のデータ構造を持つセキュリティフレームの署名検証結果と、ダイジェストの比較結果の総合判断をセキュリティ処理部１２５が受信処理部１３１に出力するとしたが、図１１（ａ）のデータ構造を持つセキュリティフレームの署名検証結果と、ダイジェストの比較結果と、ＭＡＣ検証結果を個別にセキュリティ処理部１２５が受信処理部１３１に出力するようにしてもよい。検証部１２５１は、署名検証とダイジェストの比較を独立して処理できるようになり、署名が欠落してもダイジェストの比較結果を報告できるようになる。この場合、受信処理部１３１は署名検証結果が成功し、ダイジェストの比較結果が一致し、かつＭＡＣ検証が成功したとき、そのアプリケーションデータを採用する。また、受信処理部１３１は、同じ基地局装置２０に対する過去の署名検証結果が成功し、ダイジェストの比較結果が一致し、かつＭＡＣ検証が成功したとき、そのアプリケーションデータを採用する。なお、信頼性の高いデータのみを採用したい場合は、後者の条件によるアプリケーションデータの採用を行わない。

なお、ＭＡＣ検証結果の成功をアプリケーションデータの採用条件に含めているが、署名およびダイジェストリストの効果を考えると、ＭＡＣ検証結果をアプリケーションデータの採用条件から外しても構わない。この場合、ダイジェストの比較結果が不一致の場合、アプリケーションデータは不当であると判断して採用しない。ダイジェストの比較結果が一致の場合、いずれかの図１１（ａ）のデータ構造を持つセキュリティフレームの署名検証結果に基づきアプリケーションデータの採用、不採用を決定する。同様に、信頼性の高いデータのみを採用したい場合は、自身のアプリケーションデータに対するダイジェストを含むダイジェストリストを含んだ図１１（ａ）のデータ構造を持つセキュリティフレームの署名検証結果が成功しないとアプリケーションデータの採用を行わない。

以上説明したように本実施例によれば、メッセージを構成する複数のフレームのうち、先頭フレームにのみ公開鍵証明書および電子署名を付加することにより、オーバーヘッドを低減できる。またアプリケーションデータ全体に対するダイジェストではなく、分割された個々のアプリケーションデータに対するダイジェストをリスト化して先頭フレームに付加する。これによりパケット信号の欠落に対する耐性を向上させることができる。即ち、先頭フレームのセキュリティヘッダが欠落しなければ、それ以外のデータが欠落しても、欠落していない残りのデータの署名検証が可能である。この点、アプリケーションデータ全体に対するダイジェストが１つ付加される場合、アプリケーションデータの一部が欠落すれば、残りのアプリケーションデータの署名検証も不可能となる。

このように本実施例によれば、オーバーヘッドが小さく、通信エラー耐性が高く、一定レベルのセキュリティが確保できる通信方式を実現できる。したがってセキュリティを効率的に確保できる。

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

上述の実施例では、公開鍵証明書、ダイジェストリストおよび署名を含むフレームをメッセージの先頭に配置した。この点、当該フレームを必ずしも先頭に配置することに限定されない。２番目以降に配置してもよい。

本発明の一態様の概要は、次の通りである。本発明のある態様の送信装置は、第１フレームと、少なくとも一つの第２フレームを一単位として送信する送信装置である。前記第１フレームは、電子署名の検証に使用する公開鍵証明書、ダイジェストリスト、当該ダイジェストリストに対する電子署名、アプリケーションデータを含む。前記第２フレームは、前記公開鍵証明書を特定するための情報、アプリケーションデータを含む。前記ダイジェストリストは、一単位を構成する前記第１フレームおよび前記第２フレームにそれぞれ含まれるアプリケーションデータごとに生成された複数のダイジェストを含む。

前記ダイジェストは、前記アプリケーションデータにハッシュ関数が適用されて生成されたハッシュ値であってもよい。前記第１フレームを前記一単位の先頭に送信し、同じ一単位を構成する少なくとも一つの前記第２フレームを当該第１フレームに続いて送信してもよい。

この態様によれば、複数のアプリケーションデータごとに生成された複数のダイジェストを含むダイジェストリストを第１フレームに付加することにより、第１フレームまたは第２フレームに含まれるアプリケーションデータのいずれかが欠落しても、残りのアプリケーションデータの署名検証が可能である。したがって通信エラー耐性が高い送信方式を提供できる。

本発明のある態様の受信装置は、上述の送信装置から送信された一単位を構成し、それぞれがアプリケーションデータを含む第１フレームおよび少なくとも一つの第２フレームを受信する。前記第１フレームは、電子署名の検証に使用する公開鍵証明書、同じ一単位を構成する前記第１フレームおよび前記第２フレームにそれぞれ含まれるアプリケーションデータごとに生成された複数のダイジェストを含むダイジェストリスト、当該ダイジェストリストに対する電子署名、アプリケーションデータを含む。前記第２フレームは、前記公開鍵証明書を特定するための情報、アプリケーションデータを含む。前記第１フレームの一部を欠損して受信し、当該第１フレームのダイジェストリストに欠損がなければ、前記第２フレームに含まれるアプリケーションデータのダイジェストを演算し、そのダイジェストと、前記第１フレームに含まれるダイジェストリスト内の対応するダイジェストとが一致する場合、前記アプリケーションデータを正当と判定する。

この態様によれば、第１フレームの一部が欠損しても第１フレームに含まれるダイジェストリストが欠損していなければ、第２フレームに含まれるアプリケーションの正当性を検証できる。

前記第１フレームの一部を欠損して受信し、当該第１フレームのダイジェストリストおよび電子署名に欠損がなければ、前記第１フレームに含まれる電子署名の検証に成功するとともに、前記第２フレームに含まれるアプリケーションデータのダイジェストを演算し、そのダイジェストと、前記第１フレームに含まれるダイジェストリスト内の対応するダイジェストとが一致する場合、前記アプリケーションデータを正当と判定してもよい。

この態様によれば、第１フレームの一部が欠損しても第１フレームに含まれるダイジェストリストおよび電子署名が欠損していなければ、第２フレームに含まれるアプリケーションの正当性を検証できる。

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

Claims (3)

1. 路車間通信、及び車車間通信を用いる通信システム内における基地局装置に用いられる処理装置であって、第１フレームと、少なくとも一つの第２フレームを一単位として生成し、且つ、生成した第１フレーム及び第２フレームを当該基地局装置からそれぞれ送信可能なサイズに分割したデータユニットを出力する処理装置であって、
   前記第１フレームは、電子署名の検証に使用する公開鍵証明書、ダイジェストリスト、当該ダイジェストリストに対する電子署名、及びアプリケーションデータを含むペイロードと当該ペイロードに対するメッセージ認証コードを含み、
   前記第２フレームは、前記公開鍵証明書を特定するための情報、及びアプリケーションデータを含むペイロードと当該ペイロードに対するメッセージ認証コードを含み、
   前記ダイジェストリストは、一単位を構成する前記第１フレーム及び前記第２フレームにそれぞれ含まれるアプリケーションデータごとに生成された複数のダイジェストを含み、
   前記第１フレームに含まれる前記公開鍵証明書、前記ダイジェストリスト、及び前記電子署名は、前記第１フレームを分割したデータユニットの１つに含まれることを特徴とする処理装置。
2. 前記ダイジェストは、前記アプリケーションデータにハッシュ関数が適用されて生成されたハッシュ値であることを特徴とする請求項１に記載の処理装置。
3. 前記第１フレームを分割したデータユニットを、前記一単位の先頭に出力し、同じ一単位を構成する少なくとも一つの前記第２フレームを分割したデータユニットを、当該第１フレームを分割したデータユニットに続いて出力することを特徴とする請求項１または２に記載の処理装置。