本発明の実施例の基礎となった知見は次の通りである。路車間通信は車車間通信より公共性が強いため、路車間通信ではなりすましやデータ改ざんを防ぐ要請がより大きくなる。それと共に、発信元の正当性の確認ができることが望ましいとされる。そこで、路側機(基地局装置)から車載器(端末装置)に、公開鍵証明書および電子署名付きのデータを格納したパケット信号を報知するシステムが検討されている。
しかしながら、すべてのパケット信号に公開鍵証明書および電子署名を付加するとデータに対するオーバーヘッドが、共通鍵暗号方式におけるメッセージ認証コードのオーバーヘッドに比べて大きくなる。この対策として特定の基地局装置から送信される一連のデータ群を含む複数のパケット信号に対して、公開鍵証明書および電子署名を1つ付加してオーバーヘッドを減らす方法が考えられる。しかしながら、1つの署名の対象となるデータが複数のパケット信号に跨ると、通信区間におけるパケット信号の欠落が発生した場合に特定の基地局装置から送信されるデータ群がまとめて失われることになる。
以下に示す実施例はこうした状況に鑑みてなされたものであり、その目的は、セキュリティを向上させつつ、パケット信号の欠落に対して耐性のある送信方式と、その受信方式を提供することにある。
本発明の実施例を具体的に説明する前に概要を述べる。本発明の実施例は、ITS(Intelligent Transport Systems)などの通信システムに関する。当該通信システムでは、交差点や路側などに設置された基地局装置から、車両に搭載された端末装置に情報を提供するために実行される路車間通信、および車両に搭載された端末装置から他の車両に搭載された端末装置に情報を提供するために実行される車車間通信が用いられる。
ITSでは、IEEE802.11などの無線LAN規格に類した無線通信を用いることが検討されている。そのような無線通信では、CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)と呼ばれるアクセス制御機能が使用されている。そのため当該無線通信では、基地局装置および複数の端末装置によって同一の無線チャネルが共有される。このようなCSMA/CAでは、キャリアセンスによって他のパケット信号が送信されていないことを確認した後に、パケット信号がブロードキャストにより送信される(以下、パケット信号のブロードキャストによる送信を「報知」という)。
車車間通信として端末装置は、それが搭載されている車両の速度や位置などを示す車両情報を格納したパケット信号を報知する。そのパケット信号を受信した端末装置は、そのパケット信号に格納された情報をもとに車両の接近などを認識する。また路車間通信として基地局装置は、交差点情報および渋滞情報などが格納されたパケット信号を報知する。
交差点情報には、基地局装置が設置された交差点の位置情報、交差点の路線情報、交差点の撮影画像、交差点内の車両や歩行者の位置情報など、交差点の状況に関する情報が含まれる。端末装置は、この交差点情報をモニタに表示する。また端末装置は、この交差点情報をもとに交差点の状況を認識し、出会い頭・右折・左折による、車両、自転車、歩行者との衝突防止を目的とした視覚情報または音声メッセージをユーザに通知してもよい。渋滞情報には、基地局装置が設置された走路の混雑状況、道路工事、事故に関する情報が含まれる。端末装置は、この渋滞情報をもとに進行方向の渋滞をユーザに伝達する。また、その渋滞を迂回するための迂回路を提示してもよい。
図1は、本発明の実施例に係る通信システム500の構成を示す。これは、一つの交差点を上方から見た場合に相当する。通信システム500は、基地局装置20、第1車両100aに搭載された端末装置10a、第2車両100bに搭載された端末装置10bを含む。エリア202は基地局装置20の電波圏内を示し、エリア204は基地局装置20の電波圏外を示す。図面の上側が「北」に対応し、第1車両100aは「南」から「北」に進んでおり、第2車両100bは「東」から「西」に進んでいる。基地局装置20は外部ネットワーク200を介して外部の装置と通信が可能である。
図2(a)−(d)は、通信システム500において規定されるスーパーフレームのフォーマットを示す。図2(a)は、スーパーフレームの構成を示す。スーパーフレームは、第1サブフレームから第Nサブフレームと示されるN個のサブフレームによって形成されている。例えば、スーパーフレームの長さが100msecであり、Nが8である場合、12.5msecの長さのサブフレームが規定される。なおNは、8以外であってもよい。
図2(b)は、第1基地局装置20aによって生成されるスーパーフレームの構成を示す。第1基地局装置20aは、基地局装置20のうちの任意の一つに相当する。第1基地局装置20aは、第1サブフレームの先頭部分に路車送信期間を設定する。路車送信期間とは、基地局装置がパケット信号を報知する期間である。第1基地局装置20aがパケット信号を報知する場合、第1基地局装置20aは必ず、第1サブフレームの先頭期間である路車送信期間に報知する。
一方、第1基地局装置20aの電波到達距離内に配置される他の基地局装置20、および当該電波到達距離内に存在する端末装置10は、その路車送信期間にパケット信号を報知しない。第1サブフレームの路車送信期間に後続する車車送信期間において端末装置10がパケット信号を報知可能に規定される。第1基地局装置20aは、路車送信期間を除く期間に車車送信期間を設定する。即ち、第1サブフレームの後半、および第2サブフレームから第Nサブフレームに車車送信期間を設定する。
図2(c)は、第2基地局装置20bによって生成されるスーパーフレームの構成を示す。第2基地局装置20bは、第1基地局装置20aと異なる基地局装置20である。第2基地局装置20bは、第2サブフレームおよび第3のサブフレームのそれぞれの先頭部分に路車送信期間を設定する。また第2基地局装置20bは、第2サブフレームおよび第3のサブフレームのそれぞれの路車送信期間の後段、第1サブフレーム、および第4サブフレームから第Nサブフレームに車車送信期間を設定する。第2基地局装置20bのように、2つ以上のサブフレームに対して路車送信期間を設定することにより、スーパーフレーム毎に送信できるデータ量を増やすことができる。
図2(d)は、第3基地局装置20cによって生成されるスーパーフレームの構成を示す。第3基地局装置20cは、第1基地局装置20aおよび第2基地局装置20bと異なる基地局装置20である。第3基地局装置20cは、第Nサブフレームの先頭部分に路車送信期間を設定する。また第3基地局装置20cは、第Nサブフレームにおける路車送信期間の後段、および第1サブフレームから第N−1サブフレームに車車送信期間を設定する。
複数の基地局装置20は、互いに異なったサブフレームを選択し、選択したサブフレームの先頭部分に路車送信期間を設定する。このように各基地局装置20は、自身がパケット信号を報知するために1つのサブフレームの路車送信期間を独占することにより、各基地局装置固有の報知期間をスーパーフレーム内に設けている。
スーパーフレーム内に設定可能なサブフレームの数は有限(本実施例では8)である。そこで複数の基地局装置20のそれぞれの電波到達距離を考慮してスーパーフレームを選択すれば、基地局装置20の設置台数を制限することはない。またスーパーフレーム内の全てのサブフレームに対して路車送信期間が設定されなくてもよい。なお、電波到達距離外の基地局装置20は、電波到達距離内で規定されたスーパーフレームと同一のスーパーフレームに路車送信期間を設定してもよいし、異なるスーパーフレームに路車送信期間を設定してもよい。
図3(a)−(b)は、路車送信期間を含むサブフレームの構成を示す。図3(a)に示すようにサブフレームは、路車送信期間、車車送信期間の順に構成される。路車送信期間では基地局装置20がパケット信号を報知し、車車送信期間では端末装置10がパケット信号を報知可能である。図3(b)は、路車送信期間におけるパケット信号の配置を示す。図示のごとく路車送信期間(以下、RSU(Road Side Unit)期間という)において、基地局装置20からの複数のパケット信号(以下適宜、RSUパケットという)が並べられている。ここで前後のRSUパケットは、SIFS(Short Interframe Space)だけ離れている。
図4(c)は、LLCレイヤのフレームフォーマットを示す。このフレームは、図4(b)のMSDUに格納される。図示のごとくLLCレイヤのフレームには、LLCヘッダ、LSDU(LLC Layer Service Data Unit)が順に配置される。図4(d)は、車車間・路車間共用通信制御情報レイヤのフレームフォーマットを示す。このフレームは、図4(c)のLSDUに格納される。図示のごとく車車間・路車間共用通信制御情報レイヤのフレームには、IRヘッダ、APDU(Application Protocol Data Unit)が順に配置される。
図4(e)は、セキュリティレイヤのフレームフォーマットを示す。このフレームは、図4(d)のAPDUに格納される。図示のごとくセキュリティレイヤのフレームには、セキュリティヘッダ(Security Header)、アプリケーションデータ(Application Data)、セキュリティフッタ(Security Footer)が順に配置される。以下、MACレイヤのフレームをMACフレームといい、セキュリティレイヤのフレームをセキュリティフレームという。
図5(a)−(b)は、RSUパケットに含まれるセキュリティフレームのデータ構造を示す。署名の対象となるセキュリティフレームの集まりをメッセージとする。図5(a)はメッセージの先頭に送信するセキュリティフレーム、図5(b)はメッセージの先頭以外で送信するセキュリティフレームのデータ構造を示す。
図5(a)に示すメッセージの先頭のセキュリティフレームでは、「バージョン」、「メッセージ情報」、「nonse」、「ペイロードデータ長」、「ペイロード」および「MAC」が配置される。「ペイロード」には、「署名付きデータ長」、「署名付きデータ」および「被ダイジェストデータ」が配置される。「署名付きデータ」には、「公開鍵証明書」、「ダイジェスト」および「署名」が配置される。「被ダイジェストデータ」には、「アプリデータ長」、「メッセージID」、「フレームID」、「フレーム数」および「アプリケーションデータ」が配置される。なお、セキュリティヘッダは「アプリケーションデータ」より前に配置された「バージョン」−「フレーム数」であり、セキュリティフッタは「アプリケーションデータ」より後ろに配置された「MAC」である。
図5(b)に示すメッセージの先頭以外のセキュリティフレームでは、図5(a)に示すメッセージの先頭のセキュリティフレームにおける「署名付きデータ長」および「署名付きデータ」を、「公開鍵証明書情報」に置換した構成になっている。このように、先頭以外のセキュリティフレームにおける公開鍵証明書および署名を省略することにより、メッセージ全体のオーバーヘッドを抑制できる。
「バージョン」にはフレームのデータ構造のバージョンが設定される。「メッセージ情報」にはこのフレームの受信処理において必要な情報が設定される。例えば、セキュリティフレームにおけるデータ保護形態を示すメッセージ形式、および共通鍵暗号方式に基づく処理にて使用される鍵(以下、通信鍵という)を基地局装置20と端末装置10間で共有するための鍵またはその鍵を特定するための識別子が設定される。なおメッセージ形式には、平文データ形式、認証付きデータ形式および認証付き暗号化データ形式がある。認証付きデータ形式では、通信鍵を用いて「ペイロード」に対するMAC(Message Authentication Code)が生成され、生成されたMACが「MAC」に設定される。認証付き暗号化データ形式では、それに加えて通信鍵を用いて「ペイロード」および「MAC」が暗号化される。
当該通信鍵には、事前共有された共通鍵暗号方式の共通鍵、または事前共有された鍵で暗号化された乱数値が使用される。当該通信鍵は「メッセージ情報」に設定される情報によって、基地局装置20と端末装置10間で対応が取られる。共通鍵暗号には例えば、AES(Advanced Encryption Standard)を用いることができる。本実施例では、認証付き暗号化データ形式においてCCMモードにより、MAC生成および暗号化が行われる。
「nonse」には、通信鍵を用いた暗号化またはMAC生成において暗号結果を攪乱するために用いられる通信毎にユニークな値またはその一部が設定される。このユニークな値は乱数であってもよいし、送信時刻であってもよい。さらに、乱数または送信時刻に発信元の機器IDが追加されてもよい。「nonse」に送信時刻のみが設定された場合、通信毎に使用されるユニークな値として、当該送信時刻と基地局装置20の固有値を利用する。例えば、基地局装置20の固有値として公開鍵証明書に含まれるシリアル番号または機器IDを利用できる。なお「nonse」に乱数が設定された場合、当該乱数と基地局装置20の固有値を、通信毎にユニークな値として利用する。「ペイロードデータ長」には、「ペイロード」のバイト数が設定される。このバイト数により、受信時に暗号化およびMAC生成の対象とされる範囲を特定できる。
「署名付きデータ長」には、「署名付きデータ」のバイト数が設定される。即ち、「公開鍵証明書」、「ダイジェスト」および「署名」の総バイト数が設定される。これにより、「ダイジェスト」のバイト数、および「被ダイジェストデータ」の先頭である「アプリデータ長」の配置位置を知ることができる。
「公開鍵証明書」には、基地局装置20に固有の公開鍵に対する公開鍵証明書が設定される。公開鍵証明書は、公開鍵とその公開鍵の所有主体を結びつける証明書である。公開鍵証明書には、証明書本体、署名者の証明書本体に対する署名などが含まれる。証明書本体には、署名者の識別情報、公開鍵証明書のシリアル番号、有効期限、公開鍵(鍵生成アルゴリズム、サイズなどを含む)などが含まれる。本実施例では署名者は認証局(CA:Certificate Authority)とする。署名は例えば、RSA、DSA(Digital Signature Algorithm)、ECDSA(Elliptic Curve−DSA)などの公開鍵暗号方式により生成される。本実施例ではECDSAを採用する。
「ダイジェスト」には、同一メッセージ内の「被ダイジェストデータ」に対するダイジェストが設定される。例えば、ハッシュ関数によって求められたハッシュ値が設定される。セキュリティフレームによるオーバーヘッドの影響を低減するため、本実施例ではメッセージ内の全てのセキュリティフレームに含められる「被ダイジェストデータ」を、「フレームID」順に配置したデータ列に対するハッシュ値が求められる。「署名」には、「ダイジェスト」に対する署名が設定される。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。
「アプリデータ長」には、「メッセージID」、「フレームID」、「フレーム数」および「アプリケーションデータ #1」の総データ長が設定される。これにより、ダイジェストの対象となるデータ長を特定できる。「メッセージID」にはメッセージIDが設定される。メッセージIDは、同一基地局装置20から送信されるRSUパケットをセキュリティレイヤで区別するために用いる識別番号である。メッセージIDは送信毎に1インクリメントされ、サイクリックに変化する数値(Nの剰余系、Nは自然数)である。
「フレームID」にはメッセージ内の送信順序が設定される。この送信順序は「ダイジェスト」を求めるときのデータの並び順を示す。「フレーム数」には、メッセージを構成するセキュリティフレームの数が設定される。「アプリケーションデータ」には、基地局装置20が端末装置10に対して報知するデータが設定される。「MAC」には、「ペイロード」に対するMACが設定される。
「公開鍵証明書情報」は、メッセージの先頭以外のセキュリティフレームに配置される。「公開鍵証明書情報」には、メッセージの先頭のセキュリティフレームの「公開鍵証明書」に設定されている基地局装置20固有の公開鍵証明書のシリアル番号またはダイジェストなどが設定される。本実施例はシリアル番号が設定される。これにより、発信元の基地局装置20を特定できる。
なお認証付きデータ形式では、「署名」に署名が設定された後、MACが生成され、生成されたMACが「MAC」に設定される。また認証付き暗号化データ形式では、「MAC」にMACが設定された後、さらに「ペイロード」および「MAC」が暗号化される。
図6は、本実施例に係る基地局装置20の構成を示す。基地局装置20は、アンテナ21、RF部22、変復調部23、MACフレーム処理部24、分割結合部25、セキュリティ処理部26、アプリ管理部27、ネットワーク通信部28、データ生成部29、記憶部210および制御部211を備える。
MACフレーム処理部24、分割結合部25、セキュリティ処理部26、アプリ管理部27、ネットワーク通信部28、データ生成部29、記憶部210および制御部211の構成は、ハードウエア的には任意のプロセッサ、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。従って、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
RF部22は受信処理として、端末装置10および他の基地局装置20からのパケット信号をアンテナ21にて受信する。RF部22は、受信した無線周波数のパケット信号に対して周波数変換を実行し、ベースバンドのパケット信号を生成する。RF部22は、ベースバンドのパケット信号を変復調部23に出力する。一般的にベースバンドのパケット信号は、同相成分と直交成分によって形成されるため、二つの信号線が示されるべきであるが、図を簡略化するため図6では一つの信号線だけを示している。RF部22は受信系の構成要素として、図示しないLNA(Low Noise Amplifier)、ミキサ、AGC、A/D変換部などを含む。
RF部22は送信処理として、生成したパケット信号を基地局装置20から送信する。RF部22は、変復調部23から入力されるベースバンドのパケット信号に対して周波数変換を実行し、無線周波数のパケット信号を生成する。RF部22は、自身に割り当てられたRSU期間において、無線周波数のパケット信号をアンテナ21から送信する。RF部22は送信系の構成要素として、図示しないPA(Power Amplifier)、ミキサ、D/A変換部などを含む。
変復調部23は受信処理として、RF部22からのベースバンドのパケット信号に対して復調を実行する。変復調部23は、復調して得たデジタルデータをMACフレーム処理部24に出力する。また変復調部23は送信処理として、MACフレーム処理部24からのMACフレームに対して変調を実行する。変復調部23は、変調した結果をベースバンドのパケット信号としてRF部22に出力する。
本実施例に係る通信システム500では、OFDM(Orthogonal Frequency Division Multiplexing)変調方式を採用する。この場合、変復調部23は受信処理としてFFT(Fast Fourier Transform)を実行し、送信処理としてIFFT(Inverse Fast Fourier Transform)を実行する。
MACフレーム処理部24は受信処理として、変復調部23から渡されるデジタルデータからMACフレームを取り出し、取り出したMACフレームから、APDUを取り出し、分割結合部25に出力する。またMACフレーム処理部24は送信処理として、分割結合部25からのAPDUに対して、MACヘッダ、LLCヘッダおよびIR情報ヘッダを付加し、MACフレームを生成する。MACフレーム処理部24は、生成したMACフレームを変復調部23に出力する。またMACフレーム処理部24は、他の基地局装置20または端末装置10のパケット信号と衝突しないよう、パケット信号の送受信タイミングを制御する。
分割結合部25は受信処理として、MACフレーム処理部24から渡されるAPDUを結合してセキュリティフレームを組み立て、セキュリティ処理部26に出力する。また分割結合部205は送信処理として、セキュリティ処理部26から渡されるセキュリティフレームを、パケット信号として送信できるサイズのAPDUに分割する。このとき、分割結合部25は受信処理における結合で必要な結合ヘッダを、分割したセキュリティフレームの先頭に付加する。
セキュリティ処理部26は、セキュリティフレームを生成または解釈する。本実施例では、基地局装置20からのパケット送信に注目するため、以下、セキュリティフレームを生成する処理に注目する。セキュリティ処理部26は、アプリ管理部27から受け取ったアプリケーションデータ、認証局から受け取った秘密鍵、公開鍵証明書などをもとに、分割結合部25に出力すべきセキュリティフレームを生成する。
セキュリティ処理部26は、署名部261および共通鍵暗号部262を含む。本実施例では署名部261は公開鍵証明書を内部に記憶している。公開鍵証明書は、図示しない認証局が発行する秘密鍵と、この秘密鍵と対をなす公開鍵を含む。この秘密鍵および公開鍵証明書を基地局装置20ごとにユニークにすることにより、共通鍵暗号方式に比べてセキュリティを高めることができる。
署名部261は、自身が保持する秘密鍵を用いて署名対象に対する署名を生成する。図5(a)に示すデータ構造では、「公開鍵証明書」および「ダイジェスト」に対する署名を生成する。共通鍵暗号部262は、端末装置10と共有している通信鍵を用いて暗号対象に対するMACの生成および暗号化をする。図5(a)−(b)に示すデータ構造では、「ペイロード」に対するMACの生成と、「ペイロード」および「MAC」の暗号化をする。
アプリ管理部27は受信処理として、セキュリティ処理部26からの検証結果とアプリケーションデータを受け取り、必要に応じてネットワーク通信部28に出力する。またアプリ管理部27は送信処理として、ネットワーク通信部28またはデータ生成部29からのアプリケーションデータを、スーパーフレーム周毎に取りまとめる。送信可能なデータ数のアプリケーションデータを選択した後、アプリ管理部27は選択したアプリケーションデータを送信順に並べて、セキュリティ処理部26に出力する。
ネットワーク通信部28は外部ネットワーク200に接続される。ネットワーク通信部28は、外部ネットワーク200から工事や渋滞などに関する道路情報を受けつける。またネットワーク通信部28は、アプリ管理部27による処理結果を外部ネットワーク200へ出力する。または当該処理結果を記憶部210に一時蓄積し、定期的に外部ネットワーク200へ出力する。
データ生成部29は、道路情報などを含むアプリケーションデータを生成する。データ生成部29はアプリケーションデータの内容によってデータ形式を指定する。データ生成部29は、生成したアプリケーションデータ、そのデータ長およびそのデータ形式をアプリ管理部27に出力する。記憶部210は種々の情報を記憶する。制御部211は基地局装置20全体の処理を制御する。
図7(a)−(d)は、実施例に係る基地局装置20の送信処理において、ネットワーク通信部28またはデータ生成部29から、MACフレーム処理部24に至るデータの流れを示す図である。図7(a)−(d)に示す例では図5(a)−(b)および図4(d)のデータ構造を前提とする。図中、APP1−APP3は、アプリケーションデータを、SH1−SH3はセキュリティヘッダを、SF1−SF3はセキュリティフッタを、EH1−EH7は結合ヘッダをそれぞれ示している。添え字の数値は送信順序を示している。図7(c)のSH1、APP1、SF1によって構成されるセキュリティフレームは図5(a)のデータ構造にしたがい、図7(c)のSH2、APP2、SF2によって構成されるセキュリティフレームおよびSH3、APP3、SF3によって構成されるセキュリティフレームは図5(b)のデータ構造にしたがう。また、図7(d)のEH1−EH7で始まるデータ列が、図4(d)のAPDUに格納される。
図7(a)は、ネットワーク通信部28またはデータ生成部29からアプリ管理部27への出力を示す。アプリケーションデータがAPP1、APP3、APP2の順に、アプリ管理部27に入力される。
図7(b)は、アプリ管理部27からセキュリティ処理部26への出力を示す。アプリケーションデータAPP1−APP3は送信順に並べ替えられて、セキュリティ処理部26へ出力される。
図7(c)は、セキュリティ処理部26から分割結合部25への出力を示す。セキュリティ処理部26はアプリケーションデータAPP1−APP3のそれぞれに対して、セキュリティヘッダSH1−SH3およびセキュリティフッタSF1−SF3をそれぞれ付加し、分割結合部25へ出力する。図5(a)−(b)のデータ構造では、先頭のセキュリティフレームに対するセキュリティヘッダSH1は、先頭以外のセキュリティヘッダSH2、SH3に比べてサイズが大きい。
図7(d)は、分割結合部25からMACフレーム処理部24への出力を示す。分割結合部25は分割処理として、サイズの大きい先頭のセキュリティフレームを5つに分割し、サイズの小さい先頭以外のセキュリティフレームを分割しない。分割結合部25は、分割処理後のセキュリティフレームのそれぞれを、APDUとしてMACフレーム処理部24へ出力する。MACフレーム処理部24へのAPDUの出力に先立ち、分割結合部25は、APDUのそれぞれの先頭に結合ヘッダEH1−EH7を付加する。
図8は、実施例に係る、車両100に搭載された端末装置10の構成を示す。端末装置10は、アンテナ11、通信ユニット12およびアプリケーションユニット13を備える。通信ユニット12は、アプリケーションユニット13から受け取ったアプリケーションデータを車車間通信によってアンテナ11を介して報知する。また通信ユニット12はアンテナ11を介して、他の端末装置10からのパケット信号を車車間通信により受信し、基地局装置20からのパケット信号(RSUパケット)を路車間通信により受信する。通信ユニット12は、受信したパケット信号から取り出したアプリケーションデータをアプリケーションユニット13に提供する。また通信ユニット12は、セキュリティフレームに含まれる署名検証およびMAC検証の結果をまとめた検証結果を報告する。
まずアプリケーションユニット13の構成要素について説明する。アプリケーションユニット13は、受信処理部131、通知部132、データ生成部133、記憶部134および制御部135を備える。
受信処理部131は、通信ユニット12から受け取ったアプリケーションデータと、データ生成部133から受け取った自車の車両情報に基づき、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また受信処理部131は、受け取ったデータが画像情報であれば通知部132に表示させる。
通知部132は、図示しないモニタ、ランプ、スピーカなどのユーザへの通知手段を含む。通知部132は、受信処理部131からの指示に従って、図示しない他の車両の接近などを当該通知手段を介して運転者に通知する。また渋滞情報、交差点などの画像情報などをモニタに表示する。
データ生成部133は、図示しないGPS受信機、ジャイロスコープ、車速センサなどから供給される情報にもとづき、端末装置10が搭載された車両100の現在位置、進行方向、移動速度などを特定する。なお現在位置は、緯度・経度によって示される。これらの情報の特定方法は一般的な公知の技術により実現可能であるため、ここでは説明を省略する。
データ生成部133は、特定した情報をもとに他の端末装置10や基地局装置20に報知すべきデータを生成し、通信ユニット12に出力する。またデータ生成部133は、特定した情報を受信処理部131に自車の車両情報として出力する。記憶部134は、アプリケーションユニット13で使用する種々の情報を記憶する。制御部135は、アプリケーションユニット13全体の処理を制御する。
次に通信ユニット12の構成要素について説明する。通信ユニット12は、RF部121、変復調部122、MACフレーム処理部123、分割結合部124、セキュリティ処理部125、記憶部126および制御部127を備える。
RF部121、変復調部122、MACフレーム処理部123および分割結合部124は、図6のRF部22、変復調部23、MACフレーム処理部24および分割結合部25の構成および動作と基本的に共通する。以下、これらの構成要素については、相違点を中心に説明する。記憶部126は、通信ユニット12で使用する種々の情報を記憶する。制御部127は、通信ユニット12全体の処理を制御する。
セキュリティ処理部125は、セキュリティフレームを生成または解釈する。本実施例では、基地局装置20からのパケット受信に注目するため、そのパケット信号に格納されたセキュリティフレームを解釈する処理に注目する。セキュリティ処理部125は、検証部1251および共通鍵暗号部1252を含む。
共通鍵暗号部1252は、通信鍵を用いた受信処理を行う。即ち、通信鍵を用いて暗号化データの復号およびMAC検証を行う。図5(a)−(b)に示すデータ構造では、通信鍵を用いて暗号化された「ペイロード」および「MAC」の復号と、「ペイロード」に対するMAC検証を行う。MAC検証とは、「ペイロード」に対するMACを生成し、そのMACの値と、「MAC」に設定されている値とが一致するか否か確認する処理である。一致すれば、検証成功と判断される。
検証部1251は「公開鍵証明書」および「署名」を検証する。公開鍵証明書を検証するため、本実施例では検証部1251は、図示しない認証局が発行する公開鍵証明書を検証するための認証鍵を内部に記憶している。この認証鍵は、認証局において公開鍵証明書の署名を生成するのに用いた秘密鍵と対をなす公開鍵である。
図8のMACフレーム処理部123、セキュリティ処理部125、受信処理部131、通知部132、データ生成部133、記憶部126、記憶部134、制御部127および制御部135の構成は、ハードウエア的には任意のプロセッサ、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。従って、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
図9(a)−(d)は、実施例に係る端末装置10での受信処理において、MACフレーム処理部123から、アプリケーションユニット13に至るデータの流れを示す図である。図9(a)−(d)に示す例では図5(a)−(b)のデータ構造を前提とし、図7(d)のAPDUを含むRSUパケットを受信した場合の例である。図9(a)−(d)は、スーパーフレームにおける全てのパケット信号を受信できた場合の例である。図9(a)−(d)中、APP1−APP3、SH1−SH3、SF1−SF3およびEH1−EH7は、図7(a)−(d)と同じである。
図9(a)は、MACフレーム処理部123から分割結合部124への出力を示す。7つのAPDUが出力される。図9(a)では、スーパーフレームにおける全てのRSUパケットが受信できた状態を示している。
図9(b)は、分割結合部124からセキュリティ処理部125への出力を示す。分割結合部124は、先頭から5つのAPDUの結合ヘッダEH1−EH5を取り除き、結合ヘッダEH1−EH5を取り除いた各APDUを結合する。この結合は、結合ヘッダの情報に基づいて行われる。これにより先頭のセキュリティフレームSH1、APP1、SF1が復元される。後続のAPDUも同様に分割結合部124は、結合ヘッダEH6、EH7をそれぞれ取り除き、2番目のセキュリティフレームSH2、APP2、SF2と3番目のセキュリティフレームSH3、APP3、SF3をそれぞれ復元する。分割結合部124は、復元した3つのセキュリティフレームをセキュリティ処理部125に出力する。
図9(c)は、セキュリティ処理部125からアプリケーションユニット13へのアプリケーションデータの出力を示す。セキュリティ処理部125は、セキュリティフレームからアプリケーションデータAPP1−APP3を抽出し、それらを入力順にアプリケーションユニット13へ出力する。
図9(d)は、セキュリティ処理部125からアプリケーションユニット13への検証結果の出力を示す。図9(c)に示すアプリケーションデータAPP1−APP3のそれぞれに対して、セキュリティ処理部125は、検証成功を示す情報をアプリケーションユニット13へ伝達する。
図10(a)−(d)は、実施例に係る端末装置10での受信処理において、MACフレーム処理部123から、アプリケーションユニット13に至るデータの別の流れを示す図である。図10(a)−(d)に示す例でも図5(a)−(b)のデータ構造を前提とし、図7(d)のAPDUを含むRSUパケットを受信した場合の例である。図10(a)−(d)はスーパーフレームにおいて、パケット信号が無線通信区間において欠落した場合の例である。図10(a)−(d)のそれぞれは、図9(a)−(d)のそれぞれと同じ機能ブロック間のデータの流れを示している。図10(a)−(d)中、破線で示されるデータは欠落していることを示している。
図10(a)に示すように、破線で示される3番目のAPDUを含むパケット信号が無線通信区間で欠落し、当該APDUが存在しない。欠落したAPDUはアプリケーションデータAPP1の一部であるAPP1(3/5)を含んでいる。
分割結合部124は、図10(a)に示すデータを受けてセキュリティフレームを構成する。分割結合部124は、欠落のあるアプリケーションデータAPP1を含むセキュリティフレームを構成せずに、図10(b)に示すデータを出力する。図10(b)に示すデータでは、先頭のセキュリティフレームが欠落している。
セキュリティ処理部125は、図10(b)に示すデータを受けて、そのセキュリティフレームの分解および解釈を行う。セキュリティ処理部125は、後続のセキュリティフレームに含まれるアプリケーションデータAPP2、APP3を抽出することができる。セキュリティ処理部125は、図10(c)に示すデータを出力する。
図5(a)−(b)に示すデータ構造では先頭のセキュリティフレームが欠落すると、セキュリティ処理部125は後続のセキュリティフレームの署名検証ができなくなる。全てのセキュリティフレームに対する検証失敗を通知するため、セキュリティ処理部125は、図10(d)に示す検証結果をアプリケーションユニット13に出力する。なお、アプリケーションデータAPP1は欠落によりアプリケーションユニット13に出力されず、その署名検証結果も出力されない。
このように図5(a)−(b)に示すデータ構造では、先頭のセキュリティフレームを構成するパケット信号が欠落すると、後続のセキュリティフレームの検証が不可能になる。先頭のセキュリティフレームは後続のセキュリティフレームと異なり公開鍵証明書および署名を含む。先頭のセキュリティフレームはそれらによるオーバーヘッドが大きく、後続のセキュリティフレームよりパケット信号の欠落確率が高い。以下、セキュリティフレームのデータ構造を修正して、この問題点を改善する手法について説明する。
図11(a)−(b)は、RSUパケットに含まれるセキュリティフレームの、改善されたデータ構造を示す。以下、図5(a)−(b)に示すセキュリティフレームのデータ構造との違いを説明する。図11(a)はメッセージの先頭に送信するセキュリティフレーム、図11(a)はメッセージの先頭に送信するセキュリティフレーム、図11(b)はメッセージの先頭以外で送信するセキュリティフレームのデータ構造を示す。図11(a)では、図5(a)における「ダイジェスト」が「ダイジェストリスト」に変更され、「ダイジェストリスト」の前に「リスト数」が配置される。図11(b)は、図5(b)と同様のデータ構造である。
「リスト数」には「ダイジェストリスト」に設定されているダイジェストの数が設定される。この値は、メッセージを構成するセキュリティフレームの数と一致する。即ち、「フレーム数」と一致する。したがって図11(a)および図11(b)のデータ構造において「フレーム数」を削除することも可能であるが、図11(a)および図11(b)では「フレーム数」を配置している。
「ダイジェストリスト」には、同じメッセージに属する各セキュリティフレームの「被ダイジェストデータ」に対するハッシュ値をダイジェストとして、送信順(即ち、フレームID順)に並べたリストが設定される。
図11(a)に示すデータ構造のセキュリティフレームが分割されたAPDUが無線通信区間で欠落した場合でも、分割結合部124は先頭から可能な限りAPDUの結合を行い、セキュリティ処理部125に出力する。但し、欠落後のAPDUは破棄する。図11(b)に示すデータ構造のセキュリティフレームが分割されたAPDUが無線通信区間で欠落した場合には、分割結合部124はAPDUの結合を断念して余剰のAPDUを破棄する。
図11(a)に示すデータ構造のセキュリティフレームがセキュリティ処理部125に入力されると、共通鍵暗号部1252は、入力されたセキュリティフレームに対して、通信鍵を使用して復号およびMAC検証を行う。共通鍵暗号部1252は、復号したデータを検証部1251に出力する。また、MAC検証の結果をアプリケーションユニット13に報告する。
検証部1251は、「公開鍵証明書」に設定されている公開鍵証明書の有効性を確認する。また検証部1251は当該公開鍵証明書から公開鍵を抽出し、その公開鍵を使用して「署名」に設定されている署名を検証する。公開鍵証明書が有効であり、かつ署名の検証に成功したとき、署名検証全体を成功とする。公開鍵証明書が無効または署名の検証に失敗したとき、署名検証全体を失敗とする。署名検証が終了すると、検証部1251は署名検証結果、公開鍵証明書のシリアル番号、「リスト数」に設定されているリスト数、および「ダイジェストリスト」に設定されているダイジェストリストを、記憶部126に一時退避する。
続いて検証部1251は、「被ダイジェストデータ」のダイジェストを、ハッシュ関数を用いて演算する。検証部1251は、記憶部126に一時退避させたダイジェストリストの先頭のダイジェストと、演算したダイジェストを比較する。検証部1251は、記憶部126に一時退避させた署名検証結果が成功であり、かつダイジェストの比較結果が一致するとき、最終的な署名検証結果を成功とアプリケーションユニット13に報告する。記憶部126に一時退避させた署名検証結果が失敗である、またはダイジェストの比較結果が不一致のとき、最終的な署名検証結果を失敗と報告する。
図11(b)に示すデータ構造のセキュリティフレームがセキュリティ処理部125に入力されると、共通鍵暗号部1252は、入力されたセキュリティフレームに対して、通信鍵を使用して復号およびMAC検証を行う。共通鍵暗号部1252は、復号したデータを検証部1251に出力する。また、MAC検証の結果をアプリケーションユニット13に報告する。
検証部1251は、「公開鍵証明書情報」に設定されている公開鍵証明書のシリアル番号に基づいて、記憶部126に一時退避されたダイジェストリストを探索する。記憶部126に一時退避されたダイジェストリストが存在する場合、検証部1251は、「被ダイジェストデータ」に設定されているデータにハッシュ関数を適用して、当該データのハッシュ値を求める。このハッシュ値が当該データのダイジェストとなる。
続いて検証部1251は、記憶部126に一時退避させたダイジェストリストの「フレームID」番目のダイジェストと、求めたダイジェストを比較する。記憶部126に対応するダイジェストリストが存在し、その署名検証に成功し、かつダイジェストの比較結果が一致のとき、最終的な署名検証結果を成功とアプリケーションユニット13に報告する。記憶部126に対応するダイジェストリストが存在しない、ダイジェストリストが存在してもその署名検証に失敗、またはダイジェストの比較結果が不一致のとき、最終的な署名検証結果を失敗と報告する。
図11(a)に示すデータ構造のセキュリティフレームがセキュリティ処理部125に入力されたとき、共通鍵暗号部1252は、MAC検証に失敗しても、復号したデータを検証部1251に出力する。共通鍵暗号にはAES暗号などのブロック暗号が用いられるため、セキュリティフレームが認証付き暗号化データ形式の場合、共通鍵暗号部1252はブロック単位で復号またはMAC生成しつつ、処理が終了したブロックを順次、検証部1251に出力する。MAC検証の結果を待たずに復号後のデータを検証部1251に提供することになるため、MAC検証が失敗であっても検証部1251に復号後のデータが提供される。検証部1251は「署名付データ」からデータを抽出できる限り、署名検証を行う。セキュリティフレームが認証付きデータ形式の場合、共通鍵暗号部1252はブロック単位でMAC生成しつつ、処理が終了したブロックを順次、検証部1251に出力する。これにより認証付き暗号化データ形式と同様な結果が得られる。
図12(a)−(d)は、実施例に係る端末装置10での受信処理において、MACフレーム処理部123から、アプリケーションユニット13に至る改善されたデータの流れを示す図である。図12(a)−(d)に示す例では図11(a)−(b)のデータ構造を前提とし、図7(a)−(d)にしたがってAPDUに分割され、RSUパケットが報知されることを前提とする。図7(c)のSH1、APP1、SF1によって構成されるセキュリティフレームは図12(a)のデータ構造にしたがい、図7(c)のSH2、APP2、SF2によって構成されるセキュリティフレームおよびSH3、APP3、SF3によって構成されるセキュリティフレームは図12(b)のデータ構造にしたがう。また、図7(d)のEH1−EH7で始まるデータ列が、図4(d)のAPDUに格納される。図10(a)−(d)と同様に無線通信区間においてパケット信号が欠落した場合の例である。
図12(a)は、図10(a)と同じである。図12(b)に示すように、先頭の図11(a)に示すデータ構造のセキュリティフレームの一部が欠落している。分割結合部124は、この一部欠落しているセキュリティフレームも、セキュリティ処理部125に出力する。当該セキュリティフレームは、アプリケーションデータAPP1の一部およびセキュリティフッタSF1は欠落しているが、セキュリティヘッダSH1は欠落していない。セキュリティ処理部125はセキュリティヘッダSH1から「公開鍵証明書」、「リスト数」、「ダイジェストリスト」、「署名」を取得できる。したがって、アプリケーションデータAPP2、APP3に対する署名検証が可能である。
アプリケーションデータAPP2、APP3に対する署名検証が成功した場合、図12(d)に示すように検証部1251はアプリケーションデータAPP2、APP3の署名検証結果が成功とアプリケーションユニット13に報告する。なお、アプリケーションデータAPP1の一部欠落に伴い、アプリケーションデータAPP1の署名検証結果は報告されない。
図13(a)−(d)は、実施例に係る端末装置10での受信処理において、MACフレーム処理部123から、アプリケーションユニット13に至る改善されたデータの別の流れを示す図である。図13(a)−(d)に示す例でも図11(a)−(b)のデータ構造を前提とする。図13(a)−(d)は、図10(a)−(d)および図12(a)−(d)に示す欠落したパケット信号と異なるパケット信号が無線通信区間において欠落した場合の例である。
図13(a)に示すように、破線で示される6番目のAPDUを含むパケット信号が無線通信区間で欠落し、当該APDUが存在しない。欠落したAPDUはアプリケーションデータAPP2を含んでいる。図13(b)に示すように、先頭から2番目の図11(b)に示すデータ構造のセキュリティフレームが欠落する。アプリケーションデータAPP1、APP3の署名検証が成功した場合、図13(d)に示すように検証部1251はアプリケーションデータAPP1、APP3の署名検証結果が成功とアプリケーションユニット13に報告する。なおアプリケーションデータAPP2の欠落に伴い、アプリケーションデータAPP2の署名検証結果は報告されない。
なおパケット信号に欠落がないときのデータの流れは、図9(a)−(d)と同様である。アプリケーションユニット13の受信処理部131は、セキュリティ処理部125からアプリケーションデータ、署名検証結果、およびMAC検証結果を受け取る。受信処理部131は、署名検証結果およびMAC検証結果に基づき、アプリケーションデータを採用するか否か決定する。署名検証結果が成功し、MAC検証に成功したときアプリケーションデータを採用する。
最終的な署名検証結果として、自身のアプリケーションデータに対するダイジェストを含むダイジェストリストを含んだ図11(a)のデータ構造を持つセキュリティフレームの署名検証結果と、ダイジェストの比較結果の総合判断をセキュリティ処理部125が受信処理部131に出力するとしたが、図11(a)のデータ構造を持つセキュリティフレームの署名検証結果と、ダイジェストの比較結果と、MAC検証結果を個別にセキュリティ処理部125が受信処理部131に出力するようにしてもよい。検証部1251は、署名検証とダイジェストの比較を独立して処理できるようになり、署名が欠落してもダイジェストの比較結果を報告できるようになる。この場合、受信処理部131は署名検証結果が成功し、ダイジェストの比較結果が一致し、かつMAC検証が成功したとき、そのアプリケーションデータを採用する。また、受信処理部131は、同じ基地局装置20に対する過去の署名検証結果が成功し、ダイジェストの比較結果が一致し、かつMAC検証が成功したとき、そのアプリケーションデータを採用する。なお、信頼性の高いデータのみを採用したい場合は、後者の条件によるアプリケーションデータの採用を行わない。
なお、MAC検証結果の成功をアプリケーションデータの採用条件に含めているが、署名およびダイジェストリストの効果を考えると、MAC検証結果をアプリケーションデータの採用条件から外しても構わない。この場合、ダイジェストの比較結果が不一致の場合、アプリケーションデータは不当であると判断して採用しない。ダイジェストの比較結果が一致の場合、いずれかの図11(a)のデータ構造を持つセキュリティフレームの署名検証結果に基づきアプリケーションデータの採用、不採用を決定する。同様に、信頼性の高いデータのみを採用したい場合は、自身のアプリケーションデータに対するダイジェストを含むダイジェストリストを含んだ図11(a)のデータ構造を持つセキュリティフレームの署名検証結果が成功しないとアプリケーションデータの採用を行わない。
以上説明したように本実施例によれば、メッセージを構成する複数のフレームのうち、先頭フレームにのみ公開鍵証明書および電子署名を付加することにより、オーバーヘッドを低減できる。またアプリケーションデータ全体に対するダイジェストではなく、分割された個々のアプリケーションデータに対するダイジェストをリスト化して先頭フレームに付加する。これによりパケット信号の欠落に対する耐性を向上させることができる。即ち、先頭フレームのセキュリティヘッダが欠落しなければ、それ以外のデータが欠落しても、欠落していない残りのデータの署名検証が可能である。この点、アプリケーションデータ全体に対するダイジェストが1つ付加される場合、アプリケーションデータの一部が欠落すれば、残りのアプリケーションデータの署名検証も不可能となる。
このように本実施例によれば、オーバーヘッドが小さく、通信エラー耐性が高く、一定レベルのセキュリティが確保できる通信方式を実現できる。したがってセキュリティを効率的に確保できる。
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
上述の実施例では、公開鍵証明書、ダイジェストリストおよび署名を含むフレームをメッセージの先頭に配置した。この点、当該フレームを必ずしも先頭に配置することに限定されない。2番目以降に配置してもよい。
本発明の一態様の概要は、次の通りである。本発明のある態様の送信装置は、第1フレームと、少なくとも一つの第2フレームを一単位として送信する送信装置である。前記第1フレームは、電子署名の検証に使用する公開鍵証明書、ダイジェストリスト、当該ダイジェストリストに対する電子署名、アプリケーションデータを含む。前記第2フレームは、前記公開鍵証明書を特定するための情報、アプリケーションデータを含む。前記ダイジェストリストは、一単位を構成する前記第1フレームおよび前記第2フレームにそれぞれ含まれるアプリケーションデータごとに生成された複数のダイジェストを含む。
前記ダイジェストは、前記アプリケーションデータにハッシュ関数が適用されて生成されたハッシュ値であってもよい。前記第1フレームを前記一単位の先頭に送信し、同じ一単位を構成する少なくとも一つの前記第2フレームを当該第1フレームに続いて送信してもよい。
この態様によれば、複数のアプリケーションデータごとに生成された複数のダイジェストを含むダイジェストリストを第1フレームに付加することにより、第1フレームまたは第2フレームに含まれるアプリケーションデータのいずれかが欠落しても、残りのアプリケーションデータの署名検証が可能である。したがって通信エラー耐性が高い送信方式を提供できる。
本発明のある態様の受信装置は、上述の送信装置から送信された一単位を構成し、それぞれがアプリケーションデータを含む第1フレームおよび少なくとも一つの第2フレームを受信する。前記第1フレームは、電子署名の検証に使用する公開鍵証明書、同じ一単位を構成する前記第1フレームおよび前記第2フレームにそれぞれ含まれるアプリケーションデータごとに生成された複数のダイジェストを含むダイジェストリスト、当該ダイジェストリストに対する電子署名、アプリケーションデータを含む。前記第2フレームは、前記公開鍵証明書を特定するための情報、アプリケーションデータを含む。前記第1フレームの一部を欠損して受信し、当該第1フレームのダイジェストリストに欠損がなければ、前記第2フレームに含まれるアプリケーションデータのダイジェストを演算し、そのダイジェストと、前記第1フレームに含まれるダイジェストリスト内の対応するダイジェストとが一致する場合、前記アプリケーションデータを正当と判定する。
この態様によれば、第1フレームの一部が欠損しても第1フレームに含まれるダイジェストリストが欠損していなければ、第2フレームに含まれるアプリケーションの正当性を検証できる。
前記第1フレームの一部を欠損して受信し、当該第1フレームのダイジェストリストおよび電子署名に欠損がなければ、前記第1フレームに含まれる電子署名の検証に成功するとともに、前記第2フレームに含まれるアプリケーションデータのダイジェストを演算し、そのダイジェストと、前記第1フレームに含まれるダイジェストリスト内の対応するダイジェストとが一致する場合、前記アプリケーションデータを正当と判定してもよい。
この態様によれば、第1フレームの一部が欠損しても第1フレームに含まれるダイジェストリストおよび電子署名が欠損していなければ、第2フレームに含まれるアプリケーションの正当性を検証できる。