本発明の実施例の基礎となった知見は次の通りである。路車間通信は車車間通信より公共性が強いため、路車間通信ではなりすましやデータ改ざんを防ぐ要請がより大きくなる。それと共に、発信元の正当性の確認ができることが望ましいとされる。そこで、路側機(基地局装置)から車載器(端末装置)に、公開鍵証明書および電子署名付きのデータを格納したパケット信号を報知するシステムが検討されている。
しかしながら、すべてのパケット信号に含まれる公開鍵証明書および電子署名の検証を実行するには高速な処理が必要となり、端末装置に高速のハードウエアを搭載する必要性が発生する。これらの検証処理には公開鍵暗号方式が用いられるため、演算量が多くなり回路規模が増大する要因となる。
以下に示す実施例はこうした状況に鑑みてなされたものであり、その目的は、セキュリティを向上させつつ、パケット信号を受信する際の処理負荷を軽減させる技術を提供することにある。
本発明の実施例を具体的に説明する前に概要を述べる。本発明の実施例は、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(a)−(d)は、通信システム500において規定される各レイヤのフレームのデータ構造を示す。図4(a)は、物理レイヤのフレームのデータ構造を示す。図示のごとく物理レイヤのフレームには、PLCPプリアンブル、PLCPヘッダ、PSDU(Physical Layer Service Data Unit)、テールが順に配置される。図4(b)は、MACレイヤのフレームフォーマットを示す。このフレームは、図4(a)のPSDUに格納される。図示のごとくMACレイヤのフレームには、MACヘッダ、MSDU(MAC Layer Service Data Unit)、FCS(Frame Check Sequence)が順に配置される。
図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は、RSUパケットに含まれるセキュリティフレームのデータ構造の一例を示す。このセキュリティフレームには、「バージョン」、「メッセージ情報」、「nonse」、「ペイロードデータ長」、「ペイロード」および「MAC」が配置される。「ぺイロード」には、「公開鍵証明書」、「被署名データ長」、「被署名データ」および「署名」が配置される。「被署名データ」には、「メッセージID」および「アプリケーションデータ」が配置される。セキュリティヘッダは「メッセージID」より前に配置された「バージョン」〜「被署名データ長」であり、セキュリティフッタは「アプリケーションデータ」より後ろに配置された「署名」および「MAC」である。
「バージョン」にはフレームのデータ構造のバージョンが設定される。「メッセージ情報」にはこのフレームの受信処理において必要な情報が設定される。例えば、セキュリティフレームにおけるデータ保護形態を示すメッセージ形式、および共通鍵暗号方式に基づく処理にて使用される鍵(以下、通信鍵という)を基地局装置20と端末装置10間で共有するための鍵またはその鍵を特定するための識別子が設定される。
なおメッセージ形式には、平文データ形式、認証付きデータ形式および認証付き暗号化データ形式がある。認証付きデータ形式では、通信鍵を用いて「ペイロード」に対するMAC(Message Authentication Code)が生成され、生成されたMACが「MAC」に設定される。認証付き暗号化データ形式では、それに加えて通信鍵を用いて「ペイロード」および「MAC」が暗号化される。
当該通信鍵には、事前共有された共通鍵暗号方式の共通鍵、または事前共有された鍵で暗号化された乱数値が使用される。当該通信鍵は「メッセージ情報」に設定される情報によって、基地局装置20と端末装置10間で対応が取られる。共通鍵暗号には例えば、AES(Advanced Encryption Standard)を用いることができる。本実施例では、認証付き暗号化データ形式においてCCMモードにより、MAC生成および暗号化が行われる。
「nonse」には、通信鍵を用いたMAC生成および暗号化において暗号結果を攪乱するために用いられる通信毎にユニークな値またはその一部が設定される。このユニークな値は乱数であってもよいし、送信時刻であってもよい。さらに、乱数または送信時刻に発信元の機器IDが追加されてもよい。「nonse」に送信時刻のみが設定された場合、MAC生成や暗号化には、当該送信時刻と基地局装置20の固有値を利用することで通信毎にユニーク値を生成できる。例えば、基地局装置20の固有値として公開鍵証明書に含まれるシリアル番号または機器IDを利用できる。なお「nonse」に乱数が設定された場合、当該乱数と基地局装置20の固有値を、通信毎にユニークな値として利用する。「ペイロードデータ長」には、「ペイロード」のバイト数が設定される。このバイト数により、受信時に暗号化およびMAC生成の対象とされる範囲を特定できる。
「メッセージID」にはメッセージIDが設定される。メッセージIDは、同一の基地局装置20から送信されるRSUパケットをセキュリティレイヤで区別するために用いる識別番号である。メッセージIDは送信毎に1インクリメントされ、サイクリックに変化する数値(Nの剰余系、Nは自然数)である。
「公開鍵証明書」には、基地局装置20に固有の公開鍵に対する公開鍵証明書が設定される。公開鍵証明書は、公開鍵とその公開鍵の所有主体を結びつける証明書である。公開鍵証明書には、証明書本体、署名者の証明書本体に対する署名などが含まれる。証明書本体には、署名者の識別情報、公開鍵証明書のシリアル番号、有効期限、公開鍵(鍵生成アルゴリズム、サイズなどを含む)などが含まれる。本実施例では署名者は認証局(CA:Certificate Authority)とする。署名は例えば、RSA、DSA(Digital Signature Algorithm)、ECDSA(Elliptic Curve−DSA)などの公開鍵暗号方式により生成される。本実施例ではECDSAを採用する。
「被署名データ長」には、被署名データのバイト数が設定される。このバイト数により、受信時に署名の対象とされる範囲を特定できる。「アプリケーションデータ」には、基地局装置20が端末装置10に対して報知するデータが設定される。「署名」には「被署名データ長」に対する署名が設定される。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成される。「MAC」は、「ペイロード」に対するMACが設定される。
なお認証付きデータ形式では、「電子署名」に署名が設定された後、MACが生成され、生成されたMACが「MAC」に設定される。また認証付き暗号化データ形式では、「MAC」にMACが設定された後、さらに「ペイロード」および「MAC」が暗号化される。
図6は、本実施例に係る基地局装置20の構成を示す。基地局装置20は、アンテナ21、RF部22、変復調部23、MACフレーム処理部24、セキュリティ処理部25、データ生成部26、ネットワーク通信部27、記憶部28および制御部29を備える。
MACフレーム処理部24、セキュリティ処理部25、データ生成部26、ネットワーク通信部27、記憶部28および制御部29の構成は、ハードウエア的には任意のプロセッサ、メモリ、その他の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は、自身に割り当てられた路車送信期間において、無線周波数のパケット信号をアンテナ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フレームからセキュリティフレームを取り出す。MACフレーム処理部24は、取り出したセキュリティフレームをセキュリティ処理部25に出力する。またMACフレーム処理部24は送信処理として、セキュリティ処理部25からのセキュリティフレームに対して、MACヘッダ、LLCヘッダおよびIR情報ヘッダを付加し、MACフレームを生成する。MACフレーム処理部24は、生成したMACフレームを変復調部23に出力する。またMACフレーム処理部24は、他の基地局装置20または端末装置10のパケット信号と衝突しないよう、パケット信号の送受信タイミングを制御する。
ネットワーク通信部27は外部ネットワーク200に接続される。ネットワーク通信部27は、外部ネットワーク200から工事や渋滞などに関する道路情報を受けつける。またネットワーク通信部27は、セキュリティ処理部25により処理された処理結果を外部ネットワーク200へ出力する。または当該処理結果を記憶部28に一時蓄積し、定期的に外部ネットワーク200へ出力する。
データ生成部26は、道路情報などを含むアプリケーションデータを生成する。データ生成部26はアプリケーションデータの内容によってデータ形式を指定する。データ生成部26は、生成したアプリケーションデータ、そのデータ長およびそのデータ形式をセキュリティ処理部25に出力する。記憶部28は種々の情報を記憶する。制御部29は基地局装置20全体の処理を制御する。
セキュリティ処理部25は、セキュリティフレームを生成または解釈する。本実施例では、基地局装置20からのパケット送信に注目するため、以下、セキュリティフレームを生成する処理に注目する。セキュリティ処理部25は、データ生成部26から受け取ったアプリケーションデータ、認証局から受け取った秘密鍵、公開鍵証明書などをもとに、MACフレーム処理部24に出力すべきセキュリティフレームを生成する。
セキュリティ処理部25は、署名部251および共通鍵暗号部252を含む。本実施例では署名部251は公開鍵証明書を内部に記憶している。公開鍵証明書は、図示しない認証局が発行する秘密鍵と、この秘密鍵と対をなす公開鍵を含む。この秘密鍵および公開鍵証明書を基地局装置20ごとにユニークにすることにより、共通鍵暗号方式に比べてセキュリティを高めることができる。
署名部251は、自身が保持する秘密鍵を用いて署名対象に対する署名を生成する。図5に示すデータ構造では、「被署名データ」に対する署名を生成する。共通鍵暗号部252は、端末装置10と共有している通信鍵を用いて暗号対象に対するMACの生成および暗号化をする。図5に示すデータ構造では、「ペイロード」に対するMACの生成と、「ペイロード」および「MAC」の暗号化をする。
図7は、実施例に係る、車両100に搭載された端末装置10の構成を示す。端末装置10は、アンテナ11、通信ユニット16およびアプリケーションユニット17を備える。通信ユニット16は、アプリケーションユニット17から受け取ったアプリケーションデータを車車間通信によって報知する。また通信ユニット16は、他の端末装置10からのパケット信号を車車間通信により受信し、基地局装置20からのパケット信号を路車間通信により受信する。通信ユニット16は、受信したパケット信号から取り出したアプリケーションデータをアプリケーションユニット17に提供する。また通信ユニット16は、セキュリティフレームに含まれる署名検証およびMAC検証の結果をまとめた検証結果を報告する。
まずアプリケーションユニット17の構成要素について説明する。アプリケーションユニット17は、受信処理部171、通知部172、データ生成部173、記憶部182および制御部192を備える。
受信処理部171は、通信ユニット16から受け取ったアプリケーションデータと、データ生成部173から受け取った自車の車両情報に基づき、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また受信処理部171は、受け取ったデータが画像情報であれば通知部172に表示させる。
通知部172は、図示しないモニタ、ランプ、スピーカなどのユーザへの通知手段を含む。通知部172は、受信処理部171からの指示に従って、図示しない他の車両の接近などを当該通知手段を介して運転者に通知する。また渋滞情報、交差点などの画像情報などをモニタに表示する。
データ生成部173は、図示しないGPS受信機、ジャイロスコープ、車速センサなどから供給される情報にもとづき、端末装置10が搭載された車両100の現在位置、進行方向、移動速度などを特定する。なお現在位置は、緯度・経度によって示される。これらの情報の特定方法は一般的な公知の技術により実現可能であるため、ここでは説明を省略する。
データ生成部173は、特定した情報をもとに他の端末装置10や基地局装置20に報知すべきデータを生成し、通信ユニット16に出力する。またデータ生成部173は、特定した情報を受信処理部161に自車の車両情報として出力する。記憶部182は、アプリケーションユニット17で使用する種々の情報を記憶する。制御部192は、アプリケーションユニット17全体の処理を制御する。
次に通信ユニット16の構成要素について説明する。通信ユニット16は、RF部12、変復調部13、MACフレーム処理部14、セキュリティ処理部15、記憶部181および制御部191を備える。
RF部12、変復調部13およびMACフレーム処理部14は、図6のRF部22、変復調部23およびMACフレーム処理部24の構成および動作と基本的に共通する。以下、これらの構成要素については、相違点を中心に説明する。記憶部181は、通信ユニット16で使用する種々の情報を記憶する。制御部191は、通信ユニット16全体の処理を制御する。
セキュリティ処理部15は、セキュリティフレームを生成または解釈する。本実施例では、基地局装置20からのパケット受信に注目するため、そのパケット信号に格納されたセキュリティフレームを解釈する処理に注目する。セキュリティ処理部15は、検証部151および共通鍵暗号部152を含む。
共通鍵暗号部152は、通信鍵を用いた受信処理を行う。即ち、通信鍵を用いて暗号化データの復号およびMAC検証を行う。図5に示すデータ構造では、通信鍵を用いて暗号化された「ペイロード」および「MAC」の復号と、「ペイロード」に対するMAC検証を行う。MAC検証とは、「ペイロード」に対するMACを生成し、そのMACの値と、「MAC」に設定されている値とが一致するか否か確認する処理である。一致すれば、検証成功と判断される。
検証部151は「公開鍵証明書」および「署名」を検証する。公開鍵証明書を検証するため、本実施例では検証部151は、図示しない認証局が発行する公開鍵証明書を検証するための認証鍵を内部に記憶している。この認証鍵は、認証局において公開鍵証明書の署名を生成するのに用いた秘密鍵と対をなす公開鍵である。
検証部151は、受信した全てのRSUパケットの署名を検証する処理能力を有していない。そこでセキュリティ処理部15は、受信したRSUパケットから特定のRSUパケットを選択して署名検証する。即ち、署名検証処理が間引かれる。
署名検証されるRSUパケットは、例えば次のように選択される。端末装置10を搭載した車両100が、基地局装置20の電波圏外のエリア204から電波圏内のエリア202に進入したとき、その基地局装置20から発信されるRSUパケットを、セキュリティ処理部15は優先的に選択する。その後、セキュリティ処理部15は、複数の基地局装置20から発信されたRSUパケットを均等に選択する。なおセキュリティ処理部15は、受信電波の強度、受信した端末装置10とRSUパケットを発信した基地局装置20との距離などによって重み付けをして選択してもよい。署名検証するRSUパケットの選択方法はこれらに限定されるものではなく、任意の方法を採用できる。
署名検証が間引かれた場合、通信ユニット16からアプリケーションユニット17に提供されるアプリケーションデータに対する検証結果(以下、Current結果という)には次の2つの報告が含まれる。即ち、署名検証が間引かれた旨の報告、および報告前に終了している、同じ基地局装置20が送信したRSUパケットに含まれるセキュリティフレームに対する検証結果(以下、Previous報告という)が含まれる。
同じ基地局装置20が送信したRSUパケットに含まれるセキュリティフレームであるか否かは、セキュリティフレームに含まれる公開鍵証明書が一致するか否かにより確認される。具体的には、公開鍵証明書の発行元および証明書のシリアル番号が一致するか否かにより確認される。公開鍵証明書のダイジェスト(例えば、ハッシュ値)が一致するか否かにより確認されてもよい。
図7のMACフレーム処理部14、セキュリティ処理部15、受信処理部171、通知部172、データ生成部173、記憶部181、記憶部182、制御部191および制御部192の構成は、ハードウエア的には任意のプロセッサ、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。従って、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
図8(a)−(d)は、通信ユニット16からアプリケーションユニット17に、アプリケーションデータおよび検証結果を提供するタイミングとその関係を示す。図8(a)は、1台の基地局装置20から受信したRSUパケットから取り出したセキュリティフレームがセキュリティ処理部15に入力されるタイミングを示している。右矢印横線は経過時間を示す。その線上に、スーパーフレーム周期(100msec)ごとに目盛りが付してある。セキュリティ処理部15に入力されるセキュリティフレームは四角で示し、その内部の#i(i=0〜N、Nは自然数)はメッセージIDを示す。
図8(a)の例では基地局装置20は、スーパーフレームに2つのアプリケーションデータを含むRSUパケットを送信している。端末装置10では、同じ基地局装置20から受信する各スーパーフレームの先頭のアプリケーションデータが、100msec間隔でセキュリティ処理部15に入力される。なお、太線で示されるメッセージID=1およびメッセージID=7のセキィリティフレームは、署名検証するセキュリティフレームである。他のメッセージIDのセキィリティフレームは、署名検証処理が間引かれるセキィリティフレームである。
また図8(a)中、”署名検証処理”と記述された矢印は、署名検証するセキュリティフレームに対する検証時間を示している。”MAC検証”と記述される矢印は、署名検証を間引いたセキュリティフレームに対する検証時間を示している。MAC検証は、共通鍵暗号を使用するためブロック単位の固定遅延での設計が可能であり、高速化が可能である。一方、署名検証は、MAC検証より処理が複雑であるため処理時間が長くなる。
図8(b)は、セキュリティ処理部15においてセキュリティフレームから取り出されたアプリケーションデータをアプリケーションユニット17に提供するタイミングを示す。署名検証するメッセージID=1およびその直後のメッセージID=2のセキュリティフレーム、並びに署名検証するメッセージID=7およびその直後のメッセージID=8のセキュリティフレームから取り出されるアプリケーションデータの提供タイミングは、署名検証の処理時間の影響を受ける。これらのセキュリティフレームから取り出されるアプリケーションデータの提供タイミングは、他のセキュリティフレームから取り出されるアプリケーションデータの提供タイミングより遅延する。
図8(c)は、図8(b)のアプリケーションデータとともに提供されるCurrent結果である。通信ユニット16は、メッセージID、署名検証結果、MAC検証結果、図示しないERRORをアプリケーションユニット17に報告する。メッセージIDは、アプリケーションデータを取り出したセキュリティフレームのメッセージIDである。署名検証結果には、署名検証の成功(=0)、間引(=1)、失敗(=3)のいずれかのステータスが設定される。MAC検証結果には、署名検証の成功(=0)、鍵共有違反(=2)、失敗(=3)のいずれかのステータスが設定される。
ERRORには、検証以外のエラーを含む総合的な結果が設定される。セキュリティ処理部15はERRORに、セキュリティフレームから取り出したアプリケーションデータが有効な場合は正常(=0)を、無効な場合は異常(=1)を設定する。従って、署名検証が失敗(=3)、またはMAC検証が鍵共有違反(=2)もしくは失敗(=3)の場合、ERRORに異常(=1)が設定される。
また、セキュリティフレームに署名またはMACが付加されていない場合、即ちメッセージ形式が平文データ形式の場合、署名検証結果およびMAC認証結果には共に、成功(=0)が設定される。なお図8(c)には、説明を簡単にするためセキュリティフレームから取り出したアプリケーションデータが無効となる状態の例は示されていない。署名検証するメッセージID=1およびメッセージID=7の署名結果は共に成功(=0)となっている。
図8(d)は、図8(b)のアプリケーションデータとともに提供されるPrevious結果を示す。通信ユニット16はPrevious結果として、Previous_フラグ、Previous_メッセージID、Previous_署名検証結果、図示しないERRORをアプリケーションユニット17に報告する。Previous_フラグには、Previous_署名検証結果に有効な検証結果が設定されているとき有効(=1)が、それが設定されていないとき無効(=0)が設定される。Previous_署名検証結果に有効な検証結果が設定されていないときは、Current結果の署名検証結果に、成功(=0)または失敗(=3)が設定されている。
Previous_メッセージIDには、Previous_署名検証結果により、署名検証結果が報告されるセキュリティフレームのメッセージIDが設定される。このPrevious_署名検証結果には、過去に署名検証処理が終了した署名検証結果が設定される。より具体的には、署名検証処理が終了した最後の署名検証結果が設定される。
Previous_署名検証結果には、成功(=0)、失敗(=3)のいずれかのステータスが設定される。図8(d)にて、署名検証処理が間引かれたメッセージID=2〜6のアプリケーションデータとともに提供されるPrevious_署名検証結果には、メッセージID=1の署名検証結果が設定される。同様に、メッセージID=8〜10のアプリケーションデータとともに提供されるPrevious_署名検証結果には、メッセージID=7の署名検証結果が設定される。
アプリケーションユニット17は、アプリケーションデータとともに提供されるCurrent結果とPrevious結果に従って、アプリケーションデータの採用を決定する。Current結果の署名検証結果が成功(=0)、またはPrevious_署名検証結果が成功(=0)のとき、そのアプリケーションデータを採用する。
図9(a)−(e)は、通信ユニット16からアプリケーションユニット17に、アプリケーションデータおよび別の検証結果を提供するタイミングとその関係を示す。図9(a)−(e)に示す例では、Current結果に含まれる署名検証結果に、署名検証が処理中であることを示す処理中(=2)が新たにステータスとして追加される。署名検証結果が処理中(=2)の場合、署名検証が完了していないため、間引(=1)と同じように扱われる。以下、図8(a)−(d)との差異について説明する。
前述したように署名検証はMAC検証より処理時間が長くかかる。図9(a)に示すように、MAC検証が終了した段階で通信ユニット16は、アプリケーションデータをアプリケーションユニット17に提供する。これにより、通信ユニット16はRSUパケットの受信間隔に従い、RSUパケットから取り出したデータをアプリケーションユニット17に提供できる。また、出力用の大きなバッファメモリを備える必要がない。
図9(b)と図8(b)を比較すると前者が後者より、メッセージID=1,2,7,8のセキュリティフレームから取り出されたアプリケーションデータが早く出力されている。メッセージID=1,7のセキュリティフレームから取り出されたアプリケーションデータは、署名検証処理が完了する前に出力される。従って図9(c)に示すように、メッセージID=1,7のCurrent結果の署名検証結果は処理中(=2)となる。
図9(d)では、メッセージID=1,2のセキィリティフレームに対するPrevious結果のPrevious_フラグが無効(=0)となっている。これは、検証中のメッセージID=1のセキュリティフレームより前に、同一の基地局装置20から受信したRSUパケットから取り出されたセキュリティフレームが存在しないことを示している。または、同一の基地局装置20から受信したRSUパケットから取り出されたセキュリティフレームが以前に存在しても、そのセキュリティフレームの署名検証処理が実行されなかったことを示している。例えば、基地局装置20の電波圏外のエリア204から電波圏内のエリア202に進入した初期の状態では、Previous_フラグに無効(=0)が設定されているPrevious結果が報告される。
一方、メッセージID=3〜6のセキィリティフレームに対するPrevious結果のPrevious_フラグは有効(=1)となっている。図9(a)−(b)に示すようにメッセージID=3〜6のセキィリティフレームのアプリケーションデータが出力される前に、メッセージID=1のセキュリティフレームに対する署名検証処理は終了する。メッセージID=3〜6のセキィリティフレームに対するPrevious_署名検証結果には、メッセージID=1のセキュリティフレームに対する署名検証結果が設定される。図9(d)では、成功(=0)が設定される。
アプリケーションユニット17は、図8(a)−(d)に示す例と同様に、Current結果の署名検証が成功(=0)、またはPrevious_署名検証結果が成功(=0)のとき、アプリケーションデータを採用する。
図9(e)は、図9(b)のアプリケーションデータとともに提供される発信元IDである。発信元IDは、セキュリティフレームに含まれる公開鍵証明書ごとに、セキュリティ処理部15にて割り当てられる識別番号である。セキュリティ処理部15はセキュリティフレームを受け取る。そのセキュリティフレームに含まれる公開鍵証明書に対する発信元IDが割り当てられていない場合、セキュリティ処理部15は発信元IDを割り当てる。既に割り当てられている場合、その値を使用する。
図9(e)では、メッセージID=1のセキュリティフレームを受け取ったとき、セキュリティ処理部15は、発信元ID=10を割り当て、以後、その値を継続して使用している。発信元IDには、乱数が割り当てられてもよいし、インクリメントされる値が順番割り当てられてもよい。但し、RSUパケットを隣接して受信した異なる発信元(即ち、公開鍵証明書)に対して、同じ発信元IDが重複して割り当てられないように、当該乱数またはインクリメントされる値は、サブフレームの数に対して十分に余裕のあるデータ長である必要がある。
この発信元IDとメッセージIDによって、アプリケーションユニット17は、署名検証が成功したセキュリティフレームから取り出したアプリケーションデータを特定する。アプリケーションユニット17は、Current結果の署名検証結果が処理中(=2)であるアプリケーションデータとそのCurrent結果、および発信元IDを一時保持する。そして、アプリケーションユニット17は、同じ発信元IDであり、Current結果のメッセージIDとPrevious結果のPrevious_メッセージIDが一致するPrevious_署名検証結果を待つ。その条件を満たすPrevious_署名検証結果を受け取り、そのPrevious報告のPrevious_ERRORが正常(=0)であれば、アプリケーションユニット17は、保持しているアプリケーションデータを読み出す。セキュリティ処理部15に入力されるセキュリティフレームがこのような処理にされた場合でも、図8と同様な結果を得ることができる。
図10は、変形例1に係る、RSUパケットに含まれるセキュリティフレームのデータ構造を示す。以下、図5のセキュリティフレームのデータ構造の違いを説明する。変形例1では署名検証処理を少しでも早く開始できるように、「署名」を「アプリケーションデータ」より前に移動させている。これに伴い、「被署名データ」は「メッセージID」および「アプリケーションデータ」から、「メッセージID」と「ダイジェスト」に変更される。「署名」と「MAC」の間に、「アプリデータ長」および「アプリケーションデータ」を配置する。
「ダイジェスト」には、「アプリデータ長」および「アプリケーションデータ」に対するダイジェストが設定される。ダイジェストとは、対象データを一方向関数で畳み込み、所定のデータ長に収めた値である。変形例1ではハッシュ関数によって求めたハッシュ値を設定する。「アプリデータ長」には、後続のアプリケーションデータのデータ長が設定される。
変形例1に係るセキュリティフレームの検証処理は次のように実行される。認証付き暗号化データ形式では、まず通信鍵を用いて「ペイロード」および「MAC」が復号される。次に、「ペイロード」に対するMAC認証、「被署名データ」に対する署名検証、および「アプリデータ長」および「アプリケーションデータ」に対するダイジェストの一致確認を行う。ダイジェストの一致確認では、「アプリデータ長」および「アプリケーションデータ」に対するハッシュ値が求められ、そのハッシュ値と、「ダイジェスト」に設定されている値とが一致するか否か確認される。一致していれば成功、不一致であれば失敗と判定される。認証付きデータ形式では、以上の検証処理において「ペイロード」および「MAC」の復号が省略される。その他の処理は、認証付き暗号化データ形式の場合と同様である。
図11(a)−(e)は、変形例1に係る、通信ユニット16からアプリケーションユニット17に、アプリケーションデータおよび検証結果を提供するタイミングとその関係を示す。図11(a)−(e)は、図10のデータ構造のセキュリティフレームを前提とする。また図9(a)−(e)と同様に、Current結果の署名検証結果に、処理中(=2)のステータスが含まれる例である。以下、図9(a)−(e)との相違点について説明する。
図11(c)のCurrent結果に新たに、ダイジェスト判定結果を含める。ダイジェスト判定結果はダイジェストの一致確認の結果を示し、成功(=0)または失敗(=1)が設定される。ダイジェスト判定結果が失敗(=1)の場合、ERRORに異常(=1)が設定される。
アプリケーションユニット17は、Current結果の署名検証結果が成功(=0)の場合、ダイジェスト判定結果が成功(=1)であれば、そのアプリケーションデータを採用する。Current結果の署名検証結果が間引(=1)または処理中(=2)の場合、Previous_署名検証結果が成功(=0)であれば、アプリケーションデータを採用する。
アプリケーションユニット17は、発信元IDとメッセージIDによって、署名検証が成功したセキュリティフレームから取り出したアプリケーションデータを特定する。アプリケーションユニット17は、Current結果の署名検証結果が処理中(=2)のアプリケーションデータとそのCurrent結果、および発信元IDを一時保持する。そして、アプリケーションユニット17は、同じ発信元IDであり、Current結果のメッセージIDとPrevious結果のPrevious_メッセージIDが一致するPrevious_署名検証結果を待つ。その条件を満たすPrevious_署名検証結果を受け取り、そのPrevious報告のPrevious_ERRORが正常(=0)であれば、アプリケーションユニット17は、保持しているアプリケーションデータを読み出す。
図12(a)−(b)は、変形例2に係る、RSUパケットに含まれるセキュリティフレームのデータ構造を示す。以下、図10のセキュリティフレームのデータ構造の違いを説明する。変形例2では、複数のセキュリティフレームに対して署名を1つ付加する。変形例2では署名の対象となるセキュリティフレームの集合をメッセージとする。
図12(a)はメッセージの先頭に送信するセキュリティフレームのデータ構造を示し、図12(b)はメッセージの先頭以外で送信するセキュリティフレームのデータ構造を示す。図12(a)のデータ構造では、図10の変形例1に係るデータ構造の「ダイジェスト」が「ダイジェストリスト」に変更される。変形例1に係るデータ構造の「メッセージID」の位置に「フレーム数」が配置される。また、「アプリデータ長」と「アプリケーションデータ」の間に、「メッセージID」および「フレームID」が配置される。図12(b)のデータ構造は、図12(a)のデータ構造から、署名検証に使用する「被署名データ長」、「被署名データ」および「署名」を除き、「公開鍵証明書」を「公開鍵証明書情報」に変更したデータ構造である。
「フレーム数」には、メッセージを構成するセキュリティフレームの数が設定される。このセキュリティフレームの数は、「ダイジェストリスト」に設定されているダイジェストの数と一致する。「ダイジェストリスト」には、同じメッセージが属するセキュリティフレームの「アプリデータ長」、「メッセージID」、「フレームID」および「アプリケーションデータ」に対するダイジェストが送信順に並べられたリストが設定される。
「アプリデータ長」には、「メッセージID」、「フレームID」および「アプリケーションデータ」の総データ長が設定される。「アプリデータ長」により、ダイジェストの対象となるデータ長を特定できる。「フレームID」には、メッセージ内の送信順序が設定される。「フレームID」に設定される値は、「ダイジェストリスト」に設定されているダイジェストの位置と一致する。
「公開鍵証明書情報」は、図12(b)に示す後続のセキュリティフレームのみに配置される。「公開鍵証明書情報」には、先頭のセキュリティフレームの「公開鍵証明書」に設定されている基地局装置20に固有の公開鍵証明書のシリアル番号、ダイジェストなどが設定される。変形例2では、シリアル番号が設定されているものとする。
セキュリティ処理部15は、「公開鍵証明書」または「公開鍵証明書情報」から取得する公開証明書のシリアル番号と、「メッセージID」に設定されているメッセージIDとが一致する場合、同じメッセージに属するセキュリティフレームであると判定する。
図13(a)−(f)は、変形例2に係る、通信ユニット16からアプリケーションユニット17に、アプリケーションデータおよび検証結果を提供するタイミングとその関係を示す。図13(a)−(f)は、図12(a)−(b)のデータ構造のセキュリティフレームを前提とする。以下、図11(a)−(e)との相違点について説明する。
図13(a)は、1台の基地局装置20から受信したRSUパケットから取り出したセキュリティフレームがセキュリティ処理部15に入力されるタイミングを示している。右矢印横線は経過時間を示す。その線上に、スーパーフレーム周期(100msec)ごとに目盛りが付してある。セキュリティ処理部15に入力されるセキュリティフレームは四角で示し、内部の%j(j=0〜M、Mは自然数)はフレームIDを示し、#i(i=0〜N、Nは自然数)はメッセージIDを示す。
図13(a)の例では基地局装置20はスーパーフレームに2つのアプリケーションデータを含むRSUパケットを送信している。それが1つのメッセージを構成している。ゆえに、%1は図12(a)のデータ構造のセキュリティフレーム、%2は図12(b)のデータ構造のセキュリティフレームである。
図13(c)はCurrent結果を示す。図13(c)ではCurrent結果に新たに、フレームIDを含める。発信元ID、メッセージID、フレームIDによりセキュリティフレームを特定できる。
図13(d)はPrevious結果を示す。図13(d)ではPrevious結果に新たに、Previous_ダイジェスト判定結果、Previous_MAC検証結果を含める。Previous_ダイジェスト判定結果には、メッセージを構成するいずれかのセキュリティフレームにおいて、ハッシュ値の一致が確認されたとき成功(=0)が設定される。メッセージを構成する全てのセキュリティフレームにおいて、ハッシュ値が不一致のとき失敗(=1)が設定される。
Previous_MAC検証結果には、メッセージを構成するいずれかのセキュリティフレームにおいて、MAC検証に成功したとき成功(=0)が設定される。メッセージを構成する全てのセキュリティフレームにおいて、MAC認証に失敗したとき失敗(=3)が設定される。鍵共有違反のとき(=2)が設定される。またCurrent結果と同様に、Previous結果に、図示しないPrevious_ERRORを含める。Previous_ERRORには、Previous_署名検証結果、Previous_ダイジェスト判定結果、Previous_MAC検証結果の全てが成功(=0)のとき、正常(=0)が設定される。それ以外のとき異常(=1)が設定される。
アプリケーションユニット17は、Current結果のERRORが正常(=0)でかつCurrent結果の署名検証結果が成功(=0)の場合、そのアプリケーションを採用する。またアプリケーションユニット17は、Previous結果のPrevious_ERRORが正常(=0)のとき、そのアプリケーションデータを採用する。
アプリケーションユニット17は、発信元IDとメッセージIDによって、署名検証が成功したセキュリティフレームから取り出したアプリケーションデータを特定する。アプリケーションユニット17は、Current結果の署名検証結果が処理中(=2)のアプリケーションデータとそのCurrent結果、および発信元IDを一時保持する。そして、アプリケーションユニット17は、同じ発信元IDであり、Current結果のメッセージIDとPrevious結果のPrevious_メッセージIDが一致するPrevious_署名検証結果を待つ。その条件を満たすPrevious_署名検証結果を受け取り、そのPrevious報告のPrevious_ERRORが正常(=0)であれば、アプリケーションユニット17は、保持しているアプリケーションデータを読み出す。また、Current結果の署名検証結果が成功(=0)である場合も、アプリケーションユニット17は、保持しているアプリケーションデータを読み出す。なお、Previous結果として、署名検証結果、ダイジェスト判定結果、MAC検証結果を個別に出力して提供するのではなく、単に検証の成功と失敗のみを提供するようにしてもよい。
以上説明したように本実施例によれば、RSUパケットに含まれるデータに付加された署名およびMACを検証することによりセキュリティを確保できる。その際、処理負荷が高い署名検証を間引くことにより伝搬遅延を抑制できる。署名検証が間引かれたアプリケーションデータについては、同じ基地局装置20から過去に受信されたRSUパケットに含まれるアプリケーションデータに付加された署名の検証結果で代用される。これにより、一定のセキュリティを確保しつつアプリケーションユニット17への伝搬遅延を抑制できる。よってセキュリティを効率的に確保できる。
また署名検証結果に処理中(=2)というステータスを設けることにより、署名検証を実行するアプリケーションデータを、その検証終了前にアプリケーションユニット17に出力できる。これにより、通信ユニット16からアプリケーションユニット17へのアプリケーションデータの伝搬遅延をさらに抑制できる。
また変形例1では、セキュリティフレームのデータ構造において「署名」を「アプリケーションデータ」より前に配置することにより、署名検証処理の開始タイミングを早めることができる。
また変形例2では、複数のセキュリティフレームを含むメッセージに署名を1つ付加することにより、署名検証処理を軽減できる。
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
実施例ではアプリケーションデータのアプリケーションユニット17での利用可能性の有無を問わず、セキュリティフレームから取得したアプリケーションデータをアプリケーションユニット17に提供した。この点、アプリケーションユニット17で明らかにアプリケーションデータを利用できないような結果が、Current結果に設定されている場合、通信ユニット16はデータ長0のアプリケーションデータ、Current結果、Previous結果、発信元IDを提供してもよい。即ち、アプリケーションデータを提供しなくてもよい。
本発明の一態様の概要は、次の通りである。本発明のある態様の無線装置は、無線装置であって、他の無線装置から、公開鍵暗号方式を用いて生成された電子署名および共通鍵暗号方式を用いて生成されたメッセージ認証コードが付加されたデータを含むパケット信号を受信する受信部と、前記パケット信号から取り出されたデータ、および当該データに付加されたメッセージ認証コードの検証結果を出力するとともに、当該パケット信号を送信した無線装置から過去に受信したパケット信号に含まれるデータの電子署名の検証結果を出力する出力部と、を備える。
この態様によれば、受信したパケット信号から取り出されたデータに付加された電子署名の検証結果を、過去に同一の無線装置から受信したパケット信号から取り出されたデータに付加された電子署名の検証結果で代用する。これによれば、電子署名の検証回数を減らすことができ、処理負荷を軽減し、データ出力遅延を抑制できる。
前記出力部は、受信されるパケット信号に含まれるデータに付加された電子署名の検証を間引き、その検証が間引かれたデータを出力する際、当該データに付加された電子署名の検証が間引かれたことを示す情報を出力してもよい。過去の電子署名の検証結果も出力する。電子署名の検証が間引かれないデータを出力する際、当該データに付加された電子署名の検証結果を出力する。
この態様によれば、電子署名の検証処理を間引くことにより、処理負荷を軽減し、データ出力遅延を抑制できる。
前記出力部は、前記パケット信号から取り出されたデータ、および当該データに付加されたメッセージ認証コードの検証結果を出力するとともに、当該パケット信号を送信した無線装置からこれまで受信した複数のパケット信号に含まれるデータの電子署名の検証結果のうち、最後に実行された電子署名の検証結果を出力する。
この態様によれば、検証処理が実行された電子署名の検証結果のうち、最も信頼性の高い検証結果を出力できる。
前記出力部は、前記パケット信号から取り出されたデータに付加された電子署名の検証終了前に、当該データを出力するとともに、当該電子署名の検証が処理中であることを示す情報を出力する。
この態様によれば、電子署名を検証中のデータを、その検証終了前に出力できる。したがって、電子署名の検証を実施するデータの出力遅延を抑制できる。
前記出力部は、前記パケット信号から取り出されたデータおよび検証結果を、当該データを使用するアプリケーション部に出力する。
この態様によれば、アプリケーション部は、検証結果を参照してデータを使用するか否か判定できる。