JP5991560B2 - 無線装置 - Google Patents

Description

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

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

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

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

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

本発明のある態様の無線装置は、無線装置であって、他の無線装置から、公開鍵暗号方式を用いて生成された電子署名および共通鍵暗号方式を用いて生成されたメッセージ認証コードが付加されたデータを含むパケット信号を受信する受信部と、前記パケット信号から取り出されたデータ、および当該データに付加されたメッセージ認証コードの検証結果を出力するとともに、当該パケット信号を送信した無線装置から過去に受信したパケット信号に含まれるデータの電子署名の検証結果を出力する出力部と、を備える。

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

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

本発明の実施例に係る通信システムの構成を示す図である。 図２（ａ）−（ｄ）は、通信システムにおいて規定されるスーパーフレームのフォーマットを示す図である。 図３（ａ）−（ｂ）は、サブフレームの構成を示す図である。 図４（ａ）−（ｅ）は、通信システムにおいて規定される各レイヤのフレームのフォーマットを示す図である。 ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の一例を示す図である。 実施例に係る基地局装置の構成を示す図である。 実施例に係る車両に搭載された端末装置の構成を示す図である。 図８（ａ）−（ｄ）は、通信ユニットからアプリケーションユニットへの通知を示す図である。 図９（ａ）−（ｅ）は、通信ユニットからアプリケーションユニットへの別の通知を示す図である。 変形例１に係る、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造を示す図である。 図１１（ａ）−（ｅ）は、図１０のデータ構造例における、通信ユニットからアプリケーションユニットへの通知を示す図である。 図１２（ａ）−（ｂ）は、変形例２に係る、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造を示す図である。 図１３（ａ）−（ｆ）は、図１２のデータ構造例における、通信ユニットからアプリケーションユニットへの通知を示す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図５は、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造の一例を示す。このセキュリティフレームには、「バージョン」、「メッセージ情報」、「ｎｏｎｓｅ」、「ペイロードデータ長」、「ペイロード」および「ＭＡＣ」が配置される。「ぺイロード」には、「公開鍵証明書」、「被署名データ長」、「被署名データ」および「署名」が配置される。「被署名データ」には、「メッセージＩＤ」および「アプリケーションデータ」が配置される。セキュリティヘッダは「メッセージＩＤ」より前に配置された「バージョン」〜「被署名データ長」であり、セキュリティフッタは「アプリケーションデータ」より後ろに配置された「署名」および「ＭＡＣ」である。

「バージョン」にはフレームのデータ構造のバージョンが設定される。「メッセージ情報」にはこのフレームの受信処理において必要な情報が設定される。例えば、セキュリティフレームにおけるデータ保護形態を示すメッセージ形式、および共通鍵暗号方式に基づく処理にて使用される鍵（以下、通信鍵という）を基地局装置２０と端末装置１０間で共有するための鍵またはその鍵を特定するための識別子が設定される。

なおメッセージ形式には、平文データ形式、認証付きデータ形式および認証付き暗号化データ形式がある。認証付きデータ形式では、通信鍵を用いて「ペイロード」に対するＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）が生成され、生成されたＭＡＣが「ＭＡＣ」に設定される。認証付き暗号化データ形式では、それに加えて通信鍵を用いて「ペイロード」および「ＭＡＣ」が暗号化される。

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

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

「メッセージＩＤ」にはメッセージＩＤが設定される。メッセージＩＤは、同一の基地局装置２０から送信されるＲＳＵパケットをセキュリティレイヤで区別するために用いる識別番号である。メッセージＩＤは送信毎に１インクリメントされ、サイクリックに変化する数値（Ｎの剰余系、Ｎは自然数）である。

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

「被署名データ長」には、被署名データのバイト数が設定される。このバイト数により、受信時に署名の対象とされる範囲を特定できる。「アプリケーションデータ」には、基地局装置２０が端末装置１０に対して報知するデータが設定される。「署名」には「被署名データ長」に対する署名が設定される。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成される。「ＭＡＣ」は、「ペイロード」に対するＭＡＣが設定される。

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

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

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

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

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

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

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

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

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

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

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

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

署名部２５１は、自身が保持する秘密鍵を用いて署名対象に対する署名を生成する。図５に示すデータ構造では、「被署名データ」に対する署名を生成する。共通鍵暗号部２５２は、端末装置１０と共有している通信鍵を用いて暗号対象に対するＭＡＣの生成および暗号化をする。図５に示すデータ構造では、「ペイロード」に対するＭＡＣの生成と、「ペイロード」および「ＭＡＣ」の暗号化をする。

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

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

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

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

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

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

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

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

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

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

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

検証部１５１は、受信した全てのＲＳＵパケットの署名を検証する処理能力を有していない。そこでセキュリティ処理部１５は、受信したＲＳＵパケットから特定のＲＳＵパケットを選択して署名検証する。即ち、署名検証処理が間引かれる。

署名検証されるＲＳＵパケットは、例えば次のように選択される。端末装置１０を搭載した車両１００が、基地局装置２０の電波圏外のエリア２０４から電波圏内のエリア２０２に進入したとき、その基地局装置２０から発信されるＲＳＵパケットを、セキュリティ処理部１５は優先的に選択する。その後、セキュリティ処理部１５は、複数の基地局装置２０から発信されたＲＳＵパケットを均等に選択する。なおセキュリティ処理部１５は、受信電波の強度、受信した端末装置１０とＲＳＵパケットを発信した基地局装置２０との距離などによって重み付けをして選択してもよい。署名検証するＲＳＵパケットの選択方法はこれらに限定されるものではなく、任意の方法を採用できる。

署名検証が間引かれた場合、通信ユニット１６からアプリケーションユニット１７に提供されるアプリケーションデータに対する検証結果（以下、Ｃｕｒｒｅｎｔ結果という）には次の２つの報告が含まれる。即ち、署名検証が間引かれた旨の報告、および報告前に終了している、同じ基地局装置２０が送信したＲＳＵパケットに含まれるセキュリティフレームに対する検証結果（以下、Ｐｒｅｖｉｏｕｓ報告という）が含まれる。

同じ基地局装置２０が送信したＲＳＵパケットに含まれるセキュリティフレームであるか否かは、セキュリティフレームに含まれる公開鍵証明書が一致するか否かにより確認される。具体的には、公開鍵証明書の発行元および証明書のシリアル番号が一致するか否かにより確認される。公開鍵証明書のダイジェスト（例えば、ハッシュ値）が一致するか否かにより確認されてもよい。

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

図８（ａ）−（ｄ）は、通信ユニット１６からアプリケーションユニット１７に、アプリケーションデータおよび検証結果を提供するタイミングとその関係を示す。図８（a）は、１台の基地局装置２０から受信したＲＳＵパケットから取り出したセキュリティフレームがセキュリティ処理部１５に入力されるタイミングを示している。右矢印横線は経過時間を示す。その線上に、スーパーフレーム周期（１００ｍｓｅｃ）ごとに目盛りが付してある。セキュリティ処理部１５に入力されるセキュリティフレームは四角で示し、その内部の＃ｉ（ｉ＝０〜Ｎ、Ｎは自然数）はメッセージＩＤを示す。

図８（a）の例では基地局装置２０は、スーパーフレームに２つのアプリケーションデータを含むＲＳＵパケットを送信している。端末装置１０では、同じ基地局装置２０から受信する各スーパーフレームの先頭のアプリケーションデータが、１００ｍｓｅｃ間隔でセキュリティ処理部１５に入力される。なお、太線で示されるメッセージＩＤ＝１およびメッセージＩＤ＝７のセキィリティフレームは、署名検証するセキュリティフレームである。他のメッセージＩＤのセキィリティフレームは、署名検証処理が間引かれるセキィリティフレームである。

また図８（ａ）中、”署名検証処理”と記述された矢印は、署名検証するセキュリティフレームに対する検証時間を示している。”ＭＡＣ検証”と記述される矢印は、署名検証を間引いたセキュリティフレームに対する検証時間を示している。ＭＡＣ検証は、共通鍵暗号を使用するためブロック単位の固定遅延での設計が可能であり、高速化が可能である。一方、署名検証は、ＭＡＣ検証より処理が複雑であるため処理時間が長くなる。

図８（ｂ）は、セキュリティ処理部１５においてセキュリティフレームから取り出されたアプリケーションデータをアプリケーションユニット１７に提供するタイミングを示す。署名検証するメッセージＩＤ＝１およびその直後のメッセージＩＤ＝２のセキュリティフレーム、並びに署名検証するメッセージＩＤ＝７およびその直後のメッセージＩＤ＝８のセキュリティフレームから取り出されるアプリケーションデータの提供タイミングは、署名検証の処理時間の影響を受ける。これらのセキュリティフレームから取り出されるアプリケーションデータの提供タイミングは、他のセキュリティフレームから取り出されるアプリケーションデータの提供タイミングより遅延する。

図８（ｃ）は、図８（ｂ）のアプリケーションデータとともに提供されるＣｕｒｒｅｎｔ結果である。通信ユニット１６は、メッセージＩＤ、署名検証結果、ＭＡＣ検証結果、図示しないＥＲＲＯＲをアプリケーションユニット１７に報告する。メッセージＩＤは、アプリケーションデータを取り出したセキュリティフレームのメッセージＩＤである。署名検証結果には、署名検証の成功（＝０）、間引（＝１）、失敗（＝３）のいずれかのステータスが設定される。ＭＡＣ検証結果には、署名検証の成功（＝０）、鍵共有違反（＝２）、失敗（＝３）のいずれかのステータスが設定される。

ＥＲＲＯＲには、検証以外のエラーを含む総合的な結果が設定される。セキュリティ処理部１５はＥＲＲＯＲに、セキュリティフレームから取り出したアプリケーションデータが有効な場合は正常（＝０）を、無効な場合は異常（＝１）を設定する。従って、署名検証が失敗（＝３）、またはＭＡＣ検証が鍵共有違反（＝２）もしくは失敗（＝３）の場合、ＥＲＲＯＲに異常（＝１）が設定される。

また、セキュリティフレームに署名またはＭＡＣが付加されていない場合、即ちメッセージ形式が平文データ形式の場合、署名検証結果およびＭＡＣ認証結果には共に、成功（＝０）が設定される。なお図８（ｃ）には、説明を簡単にするためセキュリティフレームから取り出したアプリケーションデータが無効となる状態の例は示されていない。署名検証するメッセージＩＤ＝１およびメッセージＩＤ＝７の署名結果は共に成功（＝０）となっている。

図８（ｄ）は、図８（ｂ）のアプリケーションデータとともに提供されるＰｒｅｖｉｏｕｓ結果を示す。通信ユニット１６はＰｒｅｖｉｏｕｓ結果として、Ｐｒｅｖｉｏｕｓ＿フラグ、Ｐｒｅｖｉｏｕｓ＿メッセージＩＤ、Ｐｒｅｖｉｏｕｓ＿署名検証結果、図示しないＥＲＲＯＲをアプリケーションユニット１７に報告する。Ｐｒｅｖｉｏｕｓ＿フラグには、Ｐｒｅｖｉｏｕｓ＿署名検証結果に有効な検証結果が設定されているとき有効（＝１）が、それが設定されていないとき無効（＝０）が設定される。Ｐｒｅｖｉｏｕｓ＿署名検証結果に有効な検証結果が設定されていないときは、Ｃｕｒｒｅｎｔ結果の署名検証結果に、成功（＝０）または失敗（＝３）が設定されている。

Ｐｒｅｖｉｏｕｓ＿メッセージＩＤには、Ｐｒｅｖｉｏｕｓ＿署名検証結果により、署名検証結果が報告されるセキュリティフレームのメッセージＩＤが設定される。このＰｒｅｖｉｏｕｓ＿署名検証結果には、過去に署名検証処理が終了した署名検証結果が設定される。より具体的には、署名検証処理が終了した最後の署名検証結果が設定される。

Ｐｒｅｖｉｏｕｓ＿署名検証結果には、成功（＝０）、失敗（＝３）のいずれかのステータスが設定される。図８（ｄ）にて、署名検証処理が間引かれたメッセージＩＤ＝２〜６のアプリケーションデータとともに提供されるＰｒｅｖｉｏｕｓ＿署名検証結果には、メッセージＩＤ＝１の署名検証結果が設定される。同様に、メッセージＩＤ＝８〜１０のアプリケーションデータとともに提供されるＰｒｅｖｉｏｕｓ＿署名検証結果には、メッセージＩＤ＝７の署名検証結果が設定される。

アプリケーションユニット１７は、アプリケーションデータとともに提供されるＣｕｒｒｅｎｔ結果とＰｒｅｖｉｏｕｓ結果に従って、アプリケーションデータの採用を決定する。Ｃｕｒｒｅｎｔ結果の署名検証結果が成功（＝０）、またはＰｒｅｖｉｏｕｓ＿署名検証結果が成功（＝０）のとき、そのアプリケーションデータを採用する。

図９（ａ）−（ｅ）は、通信ユニット１６からアプリケーションユニット１７に、アプリケーションデータおよび別の検証結果を提供するタイミングとその関係を示す。図９（ａ）−（ｅ）に示す例では、Ｃｕｒｒｅｎｔ結果に含まれる署名検証結果に、署名検証が処理中であることを示す処理中（＝２）が新たにステータスとして追加される。署名検証結果が処理中（＝２）の場合、署名検証が完了していないため、間引（＝１）と同じように扱われる。以下、図８（ａ）−（ｄ）との差異について説明する。

前述したように署名検証はＭＡＣ検証より処理時間が長くかかる。図９（ａ）に示すように、ＭＡＣ検証が終了した段階で通信ユニット１６は、アプリケーションデータをアプリケーションユニット１７に提供する。これにより、通信ユニット１６はＲＳＵパケットの受信間隔に従い、ＲＳＵパケットから取り出したデータをアプリケーションユニット１７に提供できる。また、出力用の大きなバッファメモリを備える必要がない。

図９（ｂ）と図８（ｂ）を比較すると前者が後者より、メッセージＩＤ＝１，２，７，８のセキュリティフレームから取り出されたアプリケーションデータが早く出力されている。メッセージＩＤ＝１，７のセキュリティフレームから取り出されたアプリケーションデータは、署名検証処理が完了する前に出力される。従って図９（ｃ）に示すように、メッセージＩＤ＝１，７のＣｕｒｒｅｎｔ結果の署名検証結果は処理中（＝２）となる。

図９（ｄ）では、メッセージＩＤ＝１，２のセキィリティフレームに対するＰｒｅｖｉｏｕｓ結果のＰｒｅｖｉｏｕｓ＿フラグが無効（＝０）となっている。これは、検証中のメッセージＩＤ＝１のセキュリティフレームより前に、同一の基地局装置２０から受信したＲＳＵパケットから取り出されたセキュリティフレームが存在しないことを示している。または、同一の基地局装置２０から受信したＲＳＵパケットから取り出されたセキュリティフレームが以前に存在しても、そのセキュリティフレームの署名検証処理が実行されなかったことを示している。例えば、基地局装置２０の電波圏外のエリア２０４から電波圏内のエリア２０２に進入した初期の状態では、Ｐｒｅｖｉｏｕｓ＿フラグに無効（＝０）が設定されているＰｒｅｖｉｏｕｓ結果が報告される。

一方、メッセージＩＤ＝３〜６のセキィリティフレームに対するＰｒｅｖｉｏｕｓ結果のＰｒｅｖｉｏｕｓ＿フラグは有効（＝１）となっている。図９（ａ）−（ｂ）に示すようにメッセージＩＤ＝３〜６のセキィリティフレームのアプリケーションデータが出力される前に、メッセージＩＤ＝１のセキュリティフレームに対する署名検証処理は終了する。メッセージＩＤ＝３〜６のセキィリティフレームに対するＰｒｅｖｉｏｕｓ＿署名検証結果には、メッセージＩＤ＝１のセキュリティフレームに対する署名検証結果が設定される。図９（ｄ）では、成功（＝０）が設定される。

アプリケーションユニット１７は、図８（ａ）−（ｄ）に示す例と同様に、Ｃｕｒｒｅｎｔ結果の署名検証が成功（＝０）、またはＰｒｅｖｉｏｕｓ＿署名検証結果が成功（＝０）のとき、アプリケーションデータを採用する。

図９（ｅ）は、図９（ｂ）のアプリケーションデータとともに提供される発信元ＩＤである。発信元ＩＤは、セキュリティフレームに含まれる公開鍵証明書ごとに、セキュリティ処理部１５にて割り当てられる識別番号である。セキュリティ処理部１５はセキュリティフレームを受け取る。そのセキュリティフレームに含まれる公開鍵証明書に対する発信元ＩＤが割り当てられていない場合、セキュリティ処理部１５は発信元ＩＤを割り当てる。既に割り当てられている場合、その値を使用する。

図９（ｅ）では、メッセージＩＤ＝１のセキュリティフレームを受け取ったとき、セキュリティ処理部１５は、発信元ＩＤ＝１０を割り当て、以後、その値を継続して使用している。発信元ＩＤには、乱数が割り当てられてもよいし、インクリメントされる値が順番割り当てられてもよい。但し、ＲＳＵパケットを隣接して受信した異なる発信元（即ち、公開鍵証明書）に対して、同じ発信元ＩＤが重複して割り当てられないように、当該乱数またはインクリメントされる値は、サブフレームの数に対して十分に余裕のあるデータ長である必要がある。

この発信元ＩＤとメッセージＩＤによって、アプリケーションユニット１７は、署名検証が成功したセキュリティフレームから取り出したアプリケーションデータを特定する。アプリケーションユニット１７は、Ｃｕｒｒｅｎｔ結果の署名検証結果が処理中（＝２）であるアプリケーションデータとそのＣｕｒｒｅｎｔ結果、および発信元ＩＤを一時保持する。そして、アプリケーションユニット１７は、同じ発信元ＩＤであり、Ｃｕｒｒｅｎｔ結果のメッセージＩＤとＰｒｅｖｉｏｕｓ結果のＰｒｅｖｉｏｕｓ＿メッセージＩＤが一致するＰｒｅｖｉｏｕｓ＿署名検証結果を待つ。その条件を満たすＰｒｅｖｉｏｕｓ＿署名検証結果を受け取り、そのＰｒｅｖｉｏｕｓ報告のＰｒｅｖｉｏｕｓ＿ＥＲＲＯＲが正常（＝０）であれば、アプリケーションユニット１７は、保持しているアプリケーションデータを読み出す。セキュリティ処理部１５に入力されるセキュリティフレームがこのような処理にされた場合でも、図８と同様な結果を得ることができる。

図１０は、変形例１に係る、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造を示す。以下、図５のセキュリティフレームのデータ構造の違いを説明する。変形例１では署名検証処理を少しでも早く開始できるように、「署名」を「アプリケーションデータ」より前に移動させている。これに伴い、「被署名データ」は「メッセージＩＤ」および「アプリケーションデータ」から、「メッセージＩＤ」と「ダイジェスト」に変更される。「署名」と「ＭＡＣ」の間に、「アプリデータ長」および「アプリケーションデータ」を配置する。

「ダイジェスト」には、「アプリデータ長」および「アプリケーションデータ」に対するダイジェストが設定される。ダイジェストとは、対象データを一方向関数で畳み込み、所定のデータ長に収めた値である。変形例１ではハッシュ関数によって求めたハッシュ値を設定する。「アプリデータ長」には、後続のアプリケーションデータのデータ長が設定される。

変形例１に係るセキュリティフレームの検証処理は次のように実行される。認証付き暗号化データ形式では、まず通信鍵を用いて「ペイロード」および「ＭＡＣ」が復号される。次に、「ペイロード」に対するＭＡＣ認証、「被署名データ」に対する署名検証、および「アプリデータ長」および「アプリケーションデータ」に対するダイジェストの一致確認を行う。ダイジェストの一致確認では、「アプリデータ長」および「アプリケーションデータ」に対するハッシュ値が求められ、そのハッシュ値と、「ダイジェスト」に設定されている値とが一致するか否か確認される。一致していれば成功、不一致であれば失敗と判定される。認証付きデータ形式では、以上の検証処理において「ペイロード」および「ＭＡＣ」の復号が省略される。その他の処理は、認証付き暗号化データ形式の場合と同様である。

図１１（ａ）−（ｅ）は、変形例１に係る、通信ユニット１６からアプリケーションユニット１７に、アプリケーションデータおよび検証結果を提供するタイミングとその関係を示す。図１１（ａ）−（ｅ）は、図１０のデータ構造のセキュリティフレームを前提とする。また図９（ａ）−（ｅ）と同様に、Ｃｕｒｒｅｎｔ結果の署名検証結果に、処理中（＝２）のステータスが含まれる例である。以下、図９（ａ）−（ｅ）との相違点について説明する。

図１１（ｃ）のＣｕｒｒｅｎｔ結果に新たに、ダイジェスト判定結果を含める。ダイジェスト判定結果はダイジェストの一致確認の結果を示し、成功（＝０）または失敗（＝１）が設定される。ダイジェスト判定結果が失敗（＝１）の場合、ＥＲＲＯＲに異常（＝１）が設定される。

アプリケーションユニット１７は、Ｃｕｒｒｅｎｔ結果の署名検証結果が成功（＝０）の場合、ダイジェスト判定結果が成功（＝１）であれば、そのアプリケーションデータを採用する。Ｃｕｒｒｅｎｔ結果の署名検証結果が間引（＝１）または処理中（＝２）の場合、Ｐｒｅｖｉｏｕｓ＿署名検証結果が成功（＝０）であれば、アプリケーションデータを採用する。

アプリケーションユニット１７は、発信元ＩＤとメッセージＩＤによって、署名検証が成功したセキュリティフレームから取り出したアプリケーションデータを特定する。アプリケーションユニット１７は、Ｃｕｒｒｅｎｔ結果の署名検証結果が処理中（＝２）のアプリケーションデータとそのＣｕｒｒｅｎｔ結果、および発信元ＩＤを一時保持する。そして、アプリケーションユニット１７は、同じ発信元ＩＤであり、Ｃｕｒｒｅｎｔ結果のメッセージＩＤとＰｒｅｖｉｏｕｓ結果のＰｒｅｖｉｏｕｓ＿メッセージＩＤが一致するＰｒｅｖｉｏｕｓ＿署名検証結果を待つ。その条件を満たすＰｒｅｖｉｏｕｓ＿署名検証結果を受け取り、そのＰｒｅｖｉｏｕｓ報告のＰｒｅｖｉｏｕｓ＿ＥＲＲＯＲが正常（＝０）であれば、アプリケーションユニット１７は、保持しているアプリケーションデータを読み出す。

図１２（ａ）−（ｂ）は、変形例２に係る、ＲＳＵパケットに含まれるセキュリティフレームのデータ構造を示す。以下、図１０のセキュリティフレームのデータ構造の違いを説明する。変形例２では、複数のセキュリティフレームに対して署名を１つ付加する。変形例２では署名の対象となるセキュリティフレームの集合をメッセージとする。

図１２（ａ）はメッセージの先頭に送信するセキュリティフレームのデータ構造を示し、図１２（ｂ）はメッセージの先頭以外で送信するセキュリティフレームのデータ構造を示す。図１２（ａ）のデータ構造では、図１０の変形例１に係るデータ構造の「ダイジェスト」が「ダイジェストリスト」に変更される。変形例１に係るデータ構造の「メッセージＩＤ」の位置に「フレーム数」が配置される。また、「アプリデータ長」と「アプリケーションデータ」の間に、「メッセージＩＤ」および「フレームＩＤ」が配置される。図１２（ｂ）のデータ構造は、図１２（ａ）のデータ構造から、署名検証に使用する「被署名データ長」、「被署名データ」および「署名」を除き、「公開鍵証明書」を「公開鍵証明書情報」に変更したデータ構造である。

「フレーム数」には、メッセージを構成するセキュリティフレームの数が設定される。このセキュリティフレームの数は、「ダイジェストリスト」に設定されているダイジェストの数と一致する。「ダイジェストリスト」には、同じメッセージが属するセキュリティフレームの「アプリデータ長」、「メッセージＩＤ」、「フレームＩＤ」および「アプリケーションデータ」に対するダイジェストが送信順に並べられたリストが設定される。

「アプリデータ長」には、「メッセージＩＤ」、「フレームＩＤ」および「アプリケーションデータ」の総データ長が設定される。「アプリデータ長」により、ダイジェストの対象となるデータ長を特定できる。「フレームＩＤ」には、メッセージ内の送信順序が設定される。「フレームＩＤ」に設定される値は、「ダイジェストリスト」に設定されているダイジェストの位置と一致する。

「公開鍵証明書情報」は、図１２（ｂ）に示す後続のセキュリティフレームのみに配置される。「公開鍵証明書情報」には、先頭のセキュリティフレームの「公開鍵証明書」に設定されている基地局装置２０に固有の公開鍵証明書のシリアル番号、ダイジェストなどが設定される。変形例２では、シリアル番号が設定されているものとする。

セキュリティ処理部１５は、「公開鍵証明書」または「公開鍵証明書情報」から取得する公開証明書のシリアル番号と、「メッセージＩＤ」に設定されているメッセージＩＤとが一致する場合、同じメッセージに属するセキュリティフレームであると判定する。

図１３（ａ）−（ｆ）は、変形例２に係る、通信ユニット１６からアプリケーションユニット１７に、アプリケーションデータおよび検証結果を提供するタイミングとその関係を示す。図１３（ａ）−（ｆ）は、図１２（ａ）−（ｂ）のデータ構造のセキュリティフレームを前提とする。以下、図１１（ａ）−（ｅ）との相違点について説明する。

図１３（a）は、１台の基地局装置２０から受信したＲＳＵパケットから取り出したセキュリティフレームがセキュリティ処理部１５に入力されるタイミングを示している。右矢印横線は経過時間を示す。その線上に、スーパーフレーム周期（１００ｍｓｅｃ）ごとに目盛りが付してある。セキュリティ処理部１５に入力されるセキュリティフレームは四角で示し、内部の％ｊ（ｊ＝０〜Ｍ、Ｍは自然数）はフレームＩＤを示し、＃ｉ（ｉ＝０〜Ｎ、Ｎは自然数）はメッセージＩＤを示す。

図１３（ａ）の例では基地局装置２０はスーパーフレームに２つのアプリケーションデータを含むＲＳＵパケットを送信している。それが１つのメッセージを構成している。ゆえに、％１は図１２（ａ）のデータ構造のセキュリティフレーム、％２は図１２（ｂ）のデータ構造のセキュリティフレームである。

図１３（ｃ）はＣｕｒｒｅｎｔ結果を示す。図１３（ｃ）ではＣｕｒｒｅｎｔ結果に新たに、フレームＩＤを含める。発信元ＩＤ、メッセージＩＤ、フレームＩＤによりセキュリティフレームを特定できる。

図１３（ｄ）はＰｒｅｖｉｏｕｓ結果を示す。図１３（ｄ）ではＰｒｅｖｉｏｕｓ結果に新たに、Ｐｒｅｖｉｏｕｓ＿ダイジェスト判定結果、Ｐｒｅｖｉｏｕｓ＿ＭＡＣ検証結果を含める。Ｐｒｅｖｉｏｕｓ＿ダイジェスト判定結果には、メッセージを構成するいずれかのセキュリティフレームにおいて、ハッシュ値の一致が確認されたとき成功（＝０）が設定される。メッセージを構成する全てのセキュリティフレームにおいて、ハッシュ値が不一致のとき失敗（＝１）が設定される。

Ｐｒｅｖｉｏｕｓ＿ＭＡＣ検証結果には、メッセージを構成するいずれかのセキュリティフレームにおいて、ＭＡＣ検証に成功したとき成功（＝０）が設定される。メッセージを構成する全てのセキュリティフレームにおいて、ＭＡＣ認証に失敗したとき失敗（＝３）が設定される。鍵共有違反のとき（＝２）が設定される。またＣｕｒｒｅｎｔ結果と同様に、Ｐｒｅｖｉｏｕｓ結果に、図示しないＰｒｅｖｉｏｕｓ＿ＥＲＲＯＲを含める。Ｐｒｅｖｉｏｕｓ＿ＥＲＲＯＲには、Ｐｒｅｖｉｏｕｓ＿署名検証結果、Ｐｒｅｖｉｏｕｓ＿ダイジェスト判定結果、Ｐｒｅｖｉｏｕｓ＿ＭＡＣ検証結果の全てが成功（＝０）のとき、正常（＝０）が設定される。それ以外のとき異常（＝１）が設定される。

アプリケーションユニット１７は、Ｃｕｒｒｅｎｔ結果のＥＲＲＯＲが正常（＝０）でかつＣｕｒｒｅｎｔ結果の署名検証結果が成功（＝０）の場合、そのアプリケーションを採用する。またアプリケーションユニット１７は、Ｐｒｅｖｉｏｕｓ結果のＰｒｅｖｉｏｕｓ＿ＥＲＲＯＲが正常（＝０）のとき、そのアプリケーションデータを採用する。

アプリケーションユニット１７は、発信元ＩＤとメッセージＩＤによって、署名検証が成功したセキュリティフレームから取り出したアプリケーションデータを特定する。アプリケーションユニット１７は、Ｃｕｒｒｅｎｔ結果の署名検証結果が処理中（＝２）のアプリケーションデータとそのＣｕｒｒｅｎｔ結果、および発信元ＩＤを一時保持する。そして、アプリケーションユニット１７は、同じ発信元ＩＤであり、Ｃｕｒｒｅｎｔ結果のメッセージＩＤとＰｒｅｖｉｏｕｓ結果のＰｒｅｖｉｏｕｓ＿メッセージＩＤが一致するＰｒｅｖｉｏｕｓ＿署名検証結果を待つ。その条件を満たすＰｒｅｖｉｏｕｓ＿署名検証結果を受け取り、そのＰｒｅｖｉｏｕｓ報告のＰｒｅｖｉｏｕｓ＿ＥＲＲＯＲが正常（＝０）であれば、アプリケーションユニット１７は、保持しているアプリケーションデータを読み出す。また、Ｃｕｒｒｅｎｔ結果の署名検証結果が成功（＝０）である場合も、アプリケーションユニット１７は、保持しているアプリケーションデータを読み出す。なお、Ｐｒｅｖｉｏｕｓ結果として、署名検証結果、ダイジェスト判定結果、ＭＡＣ検証結果を個別に出力して提供するのではなく、単に検証の成功と失敗のみを提供するようにしてもよい。

以上説明したように本実施例によれば、ＲＳＵパケットに含まれるデータに付加された署名およびＭＡＣを検証することによりセキュリティを確保できる。その際、処理負荷が高い署名検証を間引くことにより伝搬遅延を抑制できる。署名検証が間引かれたアプリケーションデータについては、同じ基地局装置２０から過去に受信されたＲＳＵパケットに含まれるアプリケーションデータに付加された署名の検証結果で代用される。これにより、一定のセキュリティを確保しつつアプリケーションユニット１７への伝搬遅延を抑制できる。よってセキュリティを効率的に確保できる。

また署名検証結果に処理中（＝２）というステータスを設けることにより、署名検証を実行するアプリケーションデータを、その検証終了前にアプリケーションユニット１７に出力できる。これにより、通信ユニット１６からアプリケーションユニット１７へのアプリケーションデータの伝搬遅延をさらに抑制できる。

また変形例１では、セキュリティフレームのデータ構造において「署名」を「アプリケーションデータ」より前に配置することにより、署名検証処理の開始タイミングを早めることができる。

また変形例２では、複数のセキュリティフレームを含むメッセージに署名を１つ付加することにより、署名検証処理を軽減できる。

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

実施例ではアプリケーションデータのアプリケーションユニット１７での利用可能性の有無を問わず、セキュリティフレームから取得したアプリケーションデータをアプリケーションユニット１７に提供した。この点、アプリケーションユニット１７で明らかにアプリケーションデータを利用できないような結果が、Ｃｕｒｒｅｎｔ結果に設定されている場合、通信ユニット１６はデータ長０のアプリケーションデータ、Ｃｕｒｒｅｎｔ結果、Ｐｒｅｖｉｏｕｓ結果、発信元ＩＤを提供してもよい。即ち、アプリケーションデータを提供しなくてもよい。

本発明の一態様の概要は、次の通りである。本発明のある態様の無線装置は、無線装置であって、他の無線装置から、公開鍵暗号方式を用いて生成された電子署名および共通鍵暗号方式を用いて生成されたメッセージ認証コードが付加されたデータを含むパケット信号を受信する受信部と、前記パケット信号から取り出されたデータ、および当該データに付加されたメッセージ認証コードの検証結果を出力するとともに、当該パケット信号を送信した無線装置から過去に受信したパケット信号に含まれるデータの電子署名の検証結果を出力する出力部と、を備える。

この態様によれば、受信したパケット信号から取り出されたデータに付加された電子署名の検証結果を、過去に同一の無線装置から受信したパケット信号から取り出されたデータに付加された電子署名の検証結果で代用する。これによれば、電子署名の検証回数を減らすことができ、処理負荷を軽減し、データ出力遅延を抑制できる。

前記出力部は、受信されるパケット信号に含まれるデータに付加された電子署名の検証を間引き、その検証が間引かれたデータを出力する際、当該データに付加された電子署名の検証が間引かれたことを示す情報を出力してもよい。過去の電子署名の検証結果も出力する。電子署名の検証が間引かれないデータを出力する際、当該データに付加された電子署名の検証結果を出力する。

この態様によれば、電子署名の検証処理を間引くことにより、処理負荷を軽減し、データ出力遅延を抑制できる。

前記出力部は、前記パケット信号から取り出されたデータ、および当該データに付加されたメッセージ認証コードの検証結果を出力するとともに、当該パケット信号を送信した無線装置からこれまで受信した複数のパケット信号に含まれるデータの電子署名の検証結果のうち、最後に実行された電子署名の検証結果を出力する。

この態様によれば、検証処理が実行された電子署名の検証結果のうち、最も信頼性の高い検証結果を出力できる。

前記出力部は、前記パケット信号から取り出されたデータに付加された電子署名の検証終了前に、当該データを出力するとともに、当該電子署名の検証が処理中であることを示す情報を出力する。

この態様によれば、電子署名を検証中のデータを、その検証終了前に出力できる。したがって、電子署名の検証を実施するデータの出力遅延を抑制できる。

前記出力部は、前記パケット信号から取り出されたデータおよび検証結果を、当該データを使用するアプリケーション部に出力する。

この態様によれば、アプリケーション部は、検証結果を参照してデータを使用するか否か判定できる。

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

Claims (6)

1. 路車間通信、及び車車間通信を用いる通信システム内における無線装置であって、
   他の無線装置から、公開鍵暗号方式を用いて生成された電子署名および共通鍵暗号方式を用いて生成されたメッセージ認証コードが付加されたデータを含むパケット信号を受信する受信部と、
   前記受信部において受信されるパケット信号から取り出されたデータに付加された電子署名の検証とメッセージ認証コードの検証を実行するセキュリティ処理部と、
   前記セキュリティ処理部において受信順に検証されるメッセージ認証コードの検証が終了する度に、前記パケット信号から取り出されたデータ、当該データの発信元を識別するための発信元ＩＤ、および当該データに付加されたメッセージ認証コードの検証結果を出力するとともに、当該データに付加された電子署名の検証結果、または当該パケット信号を送信した無線装置が送信し、且つ、当該パケット信号の受信より前に受信したパケット信号に含まれるデータの電子署名の検証結果を出力する出力部と、
   を備え、
   前記出力部は、前記パケット信号から取り出されたデータ、当該データの発信元を識別するための発信元ＩＤ、および当該データに付加されたメッセージ認証コードの検証結果を出力する際、当該データに付加された電子署名の検証結果が存在しない場合、当該パケット信号を送信した無線装置が送信し、且つ、当該パケット信号より前に受信したパケット信号に含まれるデータの電子署名の検証結果を出力することを特徴とする無線装置。
2. 前記出力部は、前記セキュリティ処理部において受信されるパケット信号から取り出されたデータに付加された電子署名の検証が間引かれたデータを出力する際、当該データの電子署名の検証が間引かれたことを示す情報を出力することを特徴とする請求項１に記載の無線装置。
3. 前記出力部は、前記パケット信号から取り出されたデータ、および当該データに付加されたメッセージ認証コードの検証結果を出力するとともに、当該パケット信号を送信した無線装置からこれまで受信した複数のパケット信号に含まれるデータの電子署名の検証結果のうち、最後に実行された電子署名の検証結果を出力することを請求項１または２に記載の無線装置。
4. 前記出力部は、前記セキュリティ処理部において前記パケット信号から取り出されたデータに付加された電子署名の検証終了前に、当該データを出力するとともに、当該電子署名の検証が処理中であることを示す情報を出力することを特徴とする請求項１から３のいずれかに記載の無線装置。
5. 前記出力部は、前記パケット信号から取り出されたデータおよび検証結果を、当該データを使用するアプリケーション部に出力することを特徴とする請求項１から４のいずれかに記載の無線装置。
6. 前記セキュリティ処理部は、前記パケット信号から取り出された公開鍵証明書が異なるごとに、異なる発信元ＩＤを割り当てることを特徴とする請求項１から５のいずれかに記載の無線装置。

Images