特許第6799563号(P6799563)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ パナソニック株式会社の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6799563
(24)【登録日】2020年11月25日
(45)【発行日】2020年12月16日
(54)【発明の名称】受信装置、受信方法
(51)【国際特許分類】
   H04L 9/32 20060101AFI20201207BHJP
   G09C 1/00 20060101ALI20201207BHJP
   H04W 12/06 20090101ALI20201207BHJP
【FI】
   H04L9/00 675B
   H04L9/00 675A
   G09C1/00 640D
   H04W12/06
【請求項の数】2
【全頁数】41
(21)【出願番号】特願2018-88346(P2018-88346)
(22)【出願日】2018年5月1日
(62)【分割の表示】特願2014-60517(P2014-60517)の分割
【原出願日】2014年3月24日
(65)【公開番号】特開2018-148569(P2018-148569A)
(43)【公開日】2018年9月20日
【審査請求日】2018年5月1日
(31)【優先権主張番号】特願2013-74709(P2013-74709)
(32)【優先日】2013年3月29日
(33)【優先権主張国】JP
(73)【特許権者】
【識別番号】000005821
【氏名又は名称】パナソニック株式会社
(74)【代理人】
【識別番号】100123102
【弁理士】
【氏名又は名称】宗田 悟志
(72)【発明者】
【氏名】堀 吉宏
(72)【発明者】
【氏名】武村 浩司
(72)【発明者】
【氏名】中莖 俊朗
【審査官】 行田 悦資
(56)【参考文献】
【文献】 国際公開第2013/024587(WO,A1)
【文献】 特許第6335570(JP,B2)
【文献】 特開2009−010718(JP,A)
【文献】 特開2007−104733(JP,A)
【文献】 特開2006−129432(JP,A)
【文献】 特開平11−331070(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/32
G09C 1/00
H04W 12/06
(57)【特許請求の範囲】
【請求項1】
受信装置であって、
第1メッセージおよび第2メッセージを受信し、前記第1メッセージは、公開鍵証明書、代表値リスト、公開鍵暗号方式による署名、第1アプリケーションデータ、共通鍵暗号方式による第1メッセージ認証コードを含み、前記第2メッセージは、公開鍵証明書の識別情報、第2アプリケーションデータ、共通鍵暗号方式による第2メッセージ認証コードを含む、受信部と、
前記第1メッセージに対して、第1メッセージ認証コードの検証を行い、前記第2メッセージに対して、第2メッセージ認証コードの検証を行い、前記代表値リストに対して、前記署名の検証を行い、前記代表値リストは第1代表値と第2代表値を含み、前記第1アプリケーションデータを用いて生成した第1の値と前記第1代表値との一致確認を行い、前記第2アプリケーションデータを用いて生成した第2の値と前記第2代表値との一致確認を行う、検証部と、を備え、
前記検証部は、前記第1メッセージ認証コードの検証結果、前記第2メッセージ認証コードの検証結果、前記署名の検証結果、前記第1の値と前記第1代表値との一致確認結果、前記第2の値と前記第2代表値との一致確認結果をもとに、前記アプリケーションデータにより構成されるメッセージを承認するか否か判定し、
前記検証部は、前記署名の検証に成功すると、前記第1メッセージに含まれる公開鍵証明書の識別情報、及び前記代表値リストを保持部に格納し、
前記検証部は、前記保持部に保持される代表値リストであって、前記第2メッセージに含まれる公開鍵証明書の識別情報と紐づいた代表値リスト内の代表値と、前記第2メッセージに含まれる第2アプリケーションデータを少なくとも含むデータ列から演算された代表値とを比較する、受信装置。
【請求項2】
受信方法であって、
第1メッセージおよび第2メッセージを受信し、前記第1メッセージは、公開鍵証明書、代表値リスト、公開鍵暗号方式による署名、第1アプリケーションデータ、共通鍵暗号方式による第1メッセージ認証コードを含み、前記第2メッセージは、公開鍵証明書の識別情報、第2アプリケーションデータ、共通鍵暗号方式による第2メッセージ認証コードを含み、
前記第1メッセージに対して、第1メッセージ認証コードの検証を行い、前記第2メッセージに対して、第2メッセージ認証コードの検証を行い、前記代表値リストに対して、前記署名の検証を行い、前記代表値リストは第1代表値と第2代表値を含み、前記第1アプリケーションデータを用いて生成した第1の値と前記第1代表値との一致確認を行い、前記第2アプリケーションデータを用いて生成した第2の値と前記第2代表値との一致確認を行い、
前記第1メッセージ認証コードの検証結果、前記第2メッセージ認証コードの検証結果、前記署名の検証結果、前記第1の値と前記第1代表値との一致確認結果、前記第2の値と前記第2代表値との一致確認結果をもとに、前記アプリケーションデータにより構成されるメッセージを承認するか否か判定し、
前記署名の検証に成功すると、前記第1メッセージに含まれる公開鍵証明書の識別情報、及び前記代表値リストを保持部に格納し、
前記保持部に保持される代表値リストであって、前記第2メッセージに含まれる公開鍵証明書の識別情報と紐づいた代表値リスト内の代表値と、前記第2メッセージに含まれる第2アプリケーションデータを少なくとも含むデータ列から演算された代表値とを比較する、受信方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信技術に関し、セキュリティ処理がなされたパケット信号を受信または送信する受信装置、受信方法に関する。
【背景技術】
【0002】
自動車向け無線通信の形態は、路車間通信、車車間通信(車路車間通信を含む)に大別される。いずれの通信も、交差点での出会い頭の衝突やコーナー先の渋滞による追突防止などに活用できる。例えば、車車間通信においてGPS(Global Positioning System)などによって現在の位置情報をリアルタイムに検出し、その位置情報を車載機同士で交換しあうことによって、交差点での衝突防止を図ることができる。路車間通信では、交差点や路側に路側機が設置され、この路側機から車載機に上記のような運転支援情報が送信される。無線通信は有線通信に比較して通信の傍受や第三者のなりすましによる不正な介入が容易であるため、無線通信ではそれらへの対策が有線通信より重要となる。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開2007−104310号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ブロードキャストによる情報伝達において、電子署名によるメッセージ検証は、発信元の特定ができるが処理が重く、回路規模が増大する。回路規模の増大はコストアップ要因となる。また処理遅延によって適切なタイミングで情報を得ることができない場合が発生し、サービスに支障をきたす場合がある。MAC(Message Authentication Code)によるメッセージ検証は、処理は軽いが発信元の特定ができない。
【0005】
本発明はこうした状況に鑑みてなされたものであり、その目的は、軽負荷で発信元の特定ができるメッセージ検証技術を提供することにある。
【課題を解決するための手段】
【0006】
上記課題を解決するために、本発明のある態様の無線装置は、発信元固有の公開鍵証明書、代表値リスト、アプリケーションデータ、公開鍵証明書に含まれる公開鍵で検証可能な署名、共通鍵暗号方式によるメッセージ認証コードが付加された第1パケット信号、及び発信元固有の公開鍵証明書のダイジェスト、アプリケーションデータ、共通鍵暗号方式によるメッセージ認証コードが付加された第2パケット信号を、他の無線装置から受信する受信部と、第1パケット信号に含まれる公開鍵証明書の署名および第1パケット信号に含まれる代表値リストを少なくとも含むデータ列から生成された署名を検証するための第1検証部と、第1パケット信号または第2パケット信号に含まれるメッセージ認証コードを検証するための第2検証部と、第2パケット信号に含まれるアプリケーションデータを少なくとも含むデータ列から演算された代表値と、代表値リスト内に含まれている、第2パケット信号に含まれるアプリケーションデータを少なくとも含む予め演算されたデータ列の代表値とを比較する比較部と、第1検証部による署名の検証結果、第2検証部によるメッセージ認証コードの検証結果、比較部による比較結果をもとに、アプリケーションデータを構成するメッセージを承認するか否か判定する判定部と、を備える。
【0007】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【0008】
本発明によれば、軽負荷で発信元の特定ができるメッセージ検証を実現できる。
【図面の簡単な説明】
【0009】
図1】本発明の実施例に係る通信システムの構成を示す図である。
図2図2(a)−(d)は、通信システムにおいて規定されるスーパーフレームのフォーマットを示す図である。
図3図3(a)−(b)は、サブフレームの構成を示す図である。
図4図4(a)−(d)は、通信システムにおいて規定される各レイヤのフレームのフォーマットを示す図である。
図5図5(a)−(b)は、セキュリティメッセージのデータ構造の一例を示す図である。
図6】セキュリティメッセージのデータ構造の別の一例を示す図である。
図7】基地局装置の構成を示す図である。
図8】車両に搭載された端末装置の構成を示す図である。
図9】実施例に係る通信システムを用いた車車間通信における通常のメッセージ送受信手順を説明するための図である。
図10】メッセージ形式のデータ構造の一例を示す図である。
図11】検証部の構成例を示す図である。
図12】実施例に係る端末装置でのメッセージ検証処理の一例を示すフローチャートである。
図13図12のMAC検証のサブルーチンを示すフローチャートである。
図14図12の署名検証のサブルーチンを示すフローチャートである。
図15図12のハッシュ一致検証のサブルーチンを示すフローチャートである。
図16】実施例に係る端末装置でのメッセージ検証処理の別の例を示すフローチャートである。
図17図16のMAC検証のサブルーチンを示すフローチャートである。
図18図16の署名検証のサブルーチンを示すフローチャートである。
図19図16のハッシュ一致検証のサブルーチンを示すフローチャートである。
図20図20(a)−(b)は、セキュリティメッセージのデータ構造のさらに別の一例を示す図である。
図21図12の署名検証の別のサブルーチンを示すフローチャートである。
図22図22(a)−(b)は、実施例に係る基地局装置、端末装置において規定されるレイヤの構成例を示す図である。
図23図23(a)−(e)は、図22(a)−(b)の各レイヤにおける処理の概要を示す図である。
図24図24(a)−(b)は、実施例に係る基地局装置、端末装置において規定されるレイヤの別の構成例を示す図である。
図25図25(a)−(f)は、図24(a)−(b)の各レイヤにおける処理の概要を示す図である。
図26図26(a)−(f)は、図24(a)−(b)の各レイヤにおける別の処理の概要を示す図である。
図27】汎用サービスと特定サービスが併用される通信システムにおけるデータ構造の一例を示す図である。
図28図27の「鍵情報」のデータ構造の一例を示す図である。
図29】汎用サービスと特定サービスが混在した通信システムの一例を示す図である。
図30図30(a)−(d)は、路側機における送信処理の各レイヤにおける処理の概要を示す(その1)。
図31図31(a)−(c)は、路側機における受信処理の各レイヤにおける処理の概要を示す。
図32図32(a)−(c)は、汎用車載機における受信処理の各レイヤにおける処理の概要を示す。
図33図33(a)−(d)は、路側機における送信処理の各レイヤにおける処理の概要を示す(その2)。
図34図27のメッセージを路車間メッセージとして、図6のメッセージを車車間メッセージとして受信するときの、検証部における処理を示すフローチャートである。
図35図34の署名検証のサブルーチンを示すフローチャートである。
図36図34の署名検証対象の判定方法の一例を示すフローチャートである。
図37図34の署名検証対象の判定方法の別の例を示すフローチャートである。
【発明を実施するための形態】
【0010】
本発明を具体的に説明する前に、概要を述べる。本発明の実施例は、交差点や路側などに設置された基地局装置から車両に搭載された端末装置に、情報を提供するために実行される路車間通信、および車両に搭載された端末装置から他の車両に情報を提供するために実行される車車間通信を用いたITS(Intelligent Transport Systems)などの通信システムに関する。
【0011】
ITSでは、IEEE802.11などの規格に類した無線通信を用いることが検討されている。そのような無線通信では、CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)とよばれるアクセス制御機能が使用されている。そのため、当該無線LANでは、基地局装置および複数の端末装置によって同一の無線チャネルが共有される。このようなCSMA/CAでは、キャリアセンスによって他のパケット信号が送信されていないことを確認した後に、パケット信号がブロードキャストにより送信される(以下、パケット信号のブロードキャストによる送信を「報知」という)。
【0012】
車車間通信として、端末装置は、それが搭載されている車両の速度や位置などを示す車両情報を格納したパケット信号を報知する。そのパケット信号を受信した端末装置は、そのパケット信号に格納された情報をもとに車両の接近などを認識する。また、路車間通信として、基地局装置は、交差点情報および渋滞情報などが格納されたパケット信号を報知する。
【0013】
交差点情報には、交差点の位置情報、基地局装置が設置された交差点の路線情報、撮影画像、交差点内の車両や歩行者の位置情報など、交差点の状況に関する情報が含まれる。端末装置は、この交差点情報をモニタに表示する。また、この交差点情報をもとに交差点の状況を認識し、出会い頭・右折・左折による、車両、自転車、歩行者との衝突防止を目的とした視覚情報あるいは音声メッセージをユーザに通知してもよい。渋滞情報には、基地局装置が設置された走路の混雑状況、道路工事、事故に関する情報が含まれる。端末装置は、この渋滞情報をもとに進行方向の渋滞をユーザに伝達する。また、その渋滞を迂回するための迂回路を提示してもよい。
【0014】
図1は、本発明の実施例に係る通信システム500の構成を示す。これは、ひとつの交差点を上方から見た場合に相当する。通信システム500は、基地局装置20、第1車両100aに搭載された端末装置10a、第2車両100bに搭載された端末装置10bを含む。エリア202は基地局装置20の電波圏内を示し、エリア外204は基地局装置20の電波圏外を示す。図面の上側が「北」に対応し、第1車両100aは「南」から「北」に進んでおり、第2車両100bは「東」から「西」に進んでいる。基地局装置20は外部ネットワーク200を介して外部の装置と通信が可能である。
【0015】
図2(a)−(d)は、通信システム500において規定されるスーパーフレームのフォーマットを示す。図2(a)は、スーパーフレームの構成を示す。スーパーフレームは、第1サブフレームから第Nサブフレームと示されるN個のサブフレームによって形成されている。例えば、スーパーフレームの長さが100msecであり、Nが8である場合、12.5msecの長さのサブフレームが規定される。Nは、8以外であってもよい。
【0016】
図2(b)は、図示しない第1基地局装置20aによって生成されるスーパーフレームの構成を示す。第1基地局装置20aは、基地局装置20のうちの任意のひとつに相当する。第1基地局装置20aは、第1サブフレームの先頭部分に路車間送信期間を設定する。また、第1基地局装置20aは、第1サブフレームにおいて路車間送信期間に続いて車車間送信期間を設定する。車車間送信期間とは、端末装置10がパケット信号を報知可能な期間である。つまり、第1サブフレームの先頭期間である路車間送信期間において第1基地局装置20aはパケット信号を報知可能であり、第1サブフレームの路車間送信期間に後続する車車間送信期間において端末装置10がパケット信号を報知可能であるように規定される。さらに、第1基地局装置20aは、第2サブフレームから第Nサブフレームに車車間送信期間のみを設定する。
【0017】
図2(c)は、図示しない第2基地局装置20bによって生成されるスーパーフレームの構成を示す。第2基地局装置20bは、第1基地局装置20aとは異なった基地局装置20に相当する。第2基地局装置20bは、第2サブフレームの先頭部分に路車間送信期間を設定する。また、第2基地局装置20bは、第2サブフレームにおける路車間送信期間の後段、第1サブフレーム、第3サブフレームから第Nサブフレームに車車間送信期間を設定する。
【0018】
図2(d)は、図示しない第3基地局装置20cによって生成されるスーパーフレームの構成を示す。第3基地局装置20cは、第1基地局装置20aや第2基地局装置20bとは異なった基地局装置20に相当する。第3基地局装置20cは、第3サブフレームの先頭部分に路車間送信期間を設定する。また、第3基地局装置20cは、第3サブフレームにおける路車間送信期間の後段、第1サブフレーム、第2サブフレーム、第4サブフレームから第Nサブフレームに車車間送信期間を設定する。このように、複数の基地局装置20は、互いに異なったサブフレームを選択し、選択したサブフレームの先頭部分に路車間送信期間を設定する。
【0019】
図3(a)−(b)は、サブフレームの構成を示す。図3(a)に示すように、サブフレームは、路車間送信期間、車車間送信期間の順に構成される。路車間送信期間では基地局装置20が路車間通信によるパケット信号を報知し、車車間送信期間では端末装置10が車車間通信によるパケット信号を報知可能である。図3(b)は、路車間送信期間におけるパケット信号(以下、RSU(Road Side Unit)パケットという)の配置を示す。図示のごとく、路車間送信期間において、複数のRSUパケット信号が並べられている。ここで、前後のRSUパケット信号は、SIFS(Short Interframe Space)だけ離れている。
【0020】
図4(a)−(d)は、通信システム500において規定される各レイヤのフレームのフォーマットを示す。図4(a)は、物理レイヤのフレームフォーマットを示す。図3(a)の車車間送信期間にて送信されるパケット、あるいは図3(b)のRSUパケットに相当する。図示のごとく、フレームには、PLCPプリアンブル、PLCPヘッダ、PSDU(Physical Layer Service Data Unit)、テールが順に配置される。図4(b)は、MACレイヤのフレームフォーマットを示す。このフレームは、図4(a)のPSDUに格納される。図示のごとく、フレームには、MACヘッダ、MSDU(MAC Layer Service Data Unit)、FCS(Frame Check Sequence)が順に配置される。図4(c)は、LLCレイヤのフレームフォーマットを示す。このフレームは、図4(b)のMSDUに格納される。図示のごとく、フレームには、LLCヘッダ、LSDU(LLC Layer Service Data Unit)が順に配置される。
【0021】
図4(d)は、車車間・路車間共用通信制御情報レイヤのフレームフォーマットを示す。このフレームは、図4(c)のLSDUに格納される。図示のごとく、フレームには、IRヘッダ、APDU(Application Protocol Data Unit)が順に配置される。APDUには、後述するセキュリティメッセージあるいは、通信規約に基づいて送信可能なサイズに分割されたセキュリティメッセージの部分が配置される。
【0022】
図5(a)−(b)は、セキュリティメッセージのデータ構造の一例を示す。これは、基地局装置20から報知される路車間通信のパケット信号に含まれるセキュリティメッセージに相当する。セキュリティメッセージのデータサイズによって、1つのセキュリティメッセージを分割して、連続する複数の路車間通信のパケット信号に配置して送信する場合もあり得るが、以降では説明を簡単にするために路車間通信の1つのパケット信号、即ち、図3(b)に示されたRSUパケットに1つのセキュリティメッセージが配置されるものとする。図5(a)は、図3(b)に示された複数のRSUパケットのうちの、先頭のRSUパケットに配置されるセキュリティメッセージであり、図5(b)は、2番目以降のRSUパケットに配置されるセキュリティメッセージである。図5(a)のデータ構造では、「バージョン・メッセージタイプ」、「MAC方式ヘッダ」に続いて、「MAC方式ペイロード」が配置され、最後に「MAC方式フッタ」が配置される。また、「MAC方式ヘッダ」には、「鍵ID」、「Nonce」、「ペイロード長」が含まれ、「MAC方式ペイロード」には、「公開鍵証明書」、「後続パケットの認証用ハッシュリスト」、「アプリケーション」、「電子署名」が含まれる。「MAC方式フッタ」には、「MAC」が含まれる。「Nonce」には、「機器ID」と「乱数」が含まれる。
【0023】
「バージョン・メッセージタイプ」のバージョンには、フレームフォーマットのバージョンがセットされる。「バージョン・メッセージタイプ」のメッセージタイプには、データ認証方式を規定する認証タイプ(AT)と、「ペイロード」に対する保護の形式を指定するメッセージタイプ(MT)のふたつがセットされる。「鍵ID」には、鍵を識別するための識別情報がセットされる。「Nonce」には、暗号化処理(暗号化あるいはMAC生成)において結果を攪乱するために用いる通信毎にユニークな値がセットされる。ここでは「乱数」と「機器ID」がセットされる。「機器ID」には、パケット信号の発信元である端末装置10あるいは基地局装置20に対して割り当てられた機器IDをセットされる。ここで、機器IDは、端末装置10あるいは基地局装置20に対してユニークに付与された識別番号である。
【0024】
「乱数」には、パケット信号の送信時に送信元が発生させた乱数がセットされる。すなわち、パケット信号の発信毎にユニークな値がセットされる。ここでは、「乱数」としているが、乱数に代えてメッセージの生成日時あるいは発信日時を示す「日時情報」にしてもよい。この場合、日時情報はパケット信号の発信毎にユニークである必要があるため、スーパーフレームの周期よりも細かい分解能が要求される。但し、精度は要求されない。「ペイロード長」には、「ペイロード」のバイト数がセットされる。
【0025】
「公開鍵証明書」には、送信元の基地局装置20に固有の公開鍵に対する公開鍵証明書がセットされる。公開鍵証明書は公開鍵とその公開鍵の所有主体を結びつける証明書である。公開鍵証明書には、署名者の識別情報、公開鍵証明書の識別情報(機器IDであってもよい)、有効期限、公開鍵(鍵生成アルゴリズム、サイズなどを含む)、署名者の署名などが含まれる。本実施例では、署名者は認証局(CA:Certificate Authority)とする。当該署名は、例えば、RSA、DSA(Digital Signature Algorithm)、ECDSA(Elliptic Curve−DSA)などの公開鍵暗号方式により生成される。本実施例では、ECDSAを採用する。「後続パケットの認証用ハッシュリスト」には、後続のセキュリティメッセージ、より詳細には後続のセキュリティメッセージの「アプリケーション」に対するハッシュ値のリストがセットされる。「アプリケーション」には、路車間アプリケーションデータがセットされる。
【0026】
「電子署名」には、「後続パケットの認証用ハッシュリスト」、「アプリケーションデータ」に対する署名がセットされる。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。さらに、署名をセットした後、MAC値が導出されて「MAC」にセットされる。この例では、MACの演算対象は「MAC方式ヘッダ」の「Nonce」と「ペイロード長」と「MAC方式ペイロード」であり、暗号化の対象は「MAC方式ペイロード」と「MAC方式フッタ」である。
【0027】
図5(b)のデータ構造では、「バージョン・メッセージタイプ」、「MAC方式ヘッダ」に続いて、「MAC方式ペイロード」が配置され、最後に「MAC方式フッタ」が配置される。「MAC方式ヘッダ」と「MAC方式フッタ」の構造は、図5(a)と同一なので説明を省略する。また、「MAC方式ペイロード」には、「証明書ダイジェスト」、「アプリケーションデータ」が含まれる。「証明書ダイジェスト」は、送信元の基地局装置20に固有の公開鍵に対する公開鍵証明書のダイジェストがセットされる。ここではダイジェストとして公開鍵証明書のボディ、すなわち、公開鍵証明書の署名の対象部に対するハッシュ値、例えば、SHA−224、SHA−225によって求められた値、あるいはその一部を当てるとする。なお、公開鍵証明書に含まれる署名、署名の一部、公開鍵、証明書の識別情報(例えば、シリアル番号)、または/かつ機器IDをダイジェストとして代用してもよい。さらに、ダイジェストとして機器IDを代用とする場合、図示しない「送信元機器ID」にセットされている機器IDと同一の値であれば「ダイジェスト」を省略してもよい。すなわち「証明書ダイジェスト」には、署名検証に使用する発信元の基地局装置20に固有の公開鍵に紐付け可能な、公開鍵証明書に固有な値、或いは、発信元の基地局装置20に固有な値であれば、いかなる値がセットされてもよい。MAC値が導出されて「MAC」にセットされる。図5(a)と同様に、MACの演算対象は「MAC方式ヘッダ」の「Nonce」と「ペイロード長」と、「MAC方式ペイロード」である。暗号化の対象は「MAC方式ペイロード」と「MAC方式フッタ」である。
【0028】
図6は、セキュリティメッセージのデータ構造の別の一例を示す。これは、端末装置10から報知される車車間通信のパケット信号に含まれるセキュリティメッセージに相当する。車車間通信では、路車間通信と比較して大きなサイズのパケット信号が送信できないこと、報知されるパケット信号の総数が多いこと、情報の精度が路車間送信のパケット信号に含まれる情報より低いことなどから、公開鍵暗号方式が使用されない。その代わりに、共通鍵暗号方式によるMAC(メッセージ認証コード)を使用して、パケット信号に含まれる情報の完全性を認証する。このデータ構造では、「バージョン・メッセージタイプ」、「MAC方式ヘッダ」に続いて、「MAC方式ペイロード」が配置され、最後に「MAC方式フッタ」が配置される。「MAC方式ヘッダ」には、「鍵ID」、「Nonce」、「機器管理コード」が含まれる。なお図示しないが「MAC方式ヘッダ」には、「ペイロード長」がさらに含まれてもよい。「MAC方式ペイロード」には、「アプリケーション」が含まれる。「MAC方式フッタ」には、「MAC」が含まれる。「Nonce」には、「機器ID」と「乱数」が含まれる。
【0029】
「鍵ID」には、端末装置10と基地局装置20間、あるいは、ある端末装置10と他の端末装置10の間で事前に共有されている通信鍵を指定するための識別情報である鍵IDがセットされる。「機器管理コード」は、端末装置10の稼働状態を他の端末装置10および基地局装置20に通知するための状態コードがセットされる。「機器ID」には、パケット信号の発信元である端末装置10に対して割り当てられた機器IDがセットされる。ここで、機器IDは、端末装置10に対してユニークに付与された識別番号である。
【0030】
「乱数」には、パケット信号の送信時に送信元が発生させた乱数がセットされる。すなわち、パケット信号の発信毎にユニークな値がセットされる。ここでは、「乱数」としているが、乱数に変えてメッセージの生成日時あるいは発信日時を示す「日時情報」にしてもよい。この場合、日時情報はパケット信号の発信毎にユニークである必要があるため、スーパーフレームの周期よりも細かい分解能が要求される。但し、精度は要求されない。
【0031】
「アプリケーション」には、車車間アプリケーションデータがセットされる。MACの演算対象は、「MAC方式ヘッダ」の「Nonce」と「機器管理コード」と「MAC方式ペイロード」であり、暗号化の対象は、「MAC方式ペイロード」と「MAC方式フッタ」である。また以降では、MAC方式ペイロードを単にペイロードとよぶものとする。
【0032】
図7は、基地局装置20の構成を示す。基地局装置20は、アンテナ21、RF部22、変復調部23、MACフレーム処理部24、セキュリティ処理部25、データ生成部26、ネットワーク通信部27、記憶部28および制御部29を備える。
【0033】
MACフレーム処理部24、セキュリティ処理部25、データ生成部26、ネットワーク通信部27、記憶部28および制御部29の構成は、ハードウエア的には、任意のプロセッサ、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ハードウエアとソフトウエアの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【0034】
RF部22は、受信処理として、端末装置10および他の基地局装置20からのパケット信号をアンテナ21にて受信する。RF部22は、受信した無線周波数のパケット信号に対して周波数変換を実行し、ベースバンドのパケット信号を生成する。RF部22は、ベースバンドのパケット信号を変復調部23に出力する。一般的に、ベースバンドのパケット信号は、同相成分と直交成分によって形成されるため、ふたつの信号線が示されるべきであるが、図を簡略化するため、図7ではひとつの信号線だけを示している。RF部22は、受信系の構成要素として、図示しないLNA(Low Noise Amplifier)、ミキサ、AGC、A/D変換部などを含む。
【0035】
RF部22は、送信処理として、生成したパケット信号を基地局装置20から送信する。RF部22は、変復調部23から入力されるベースバンドのパケット信号に対して周波数変換を実行し、無線周波数のパケット信号を生成する。RF部22は、RSU期間において、無線周波数のパケット信号をアンテナ21から送信する。RF部22は、送信系の構成要素として、図示しないPA(Power Amplifier)、ミキサ、D/A変換部などを含む。
【0036】
変復調部23は、受信処理として、RF部22からのベースバンドのパケット信号に対して、復調を実行する。変復調部23は、復調した結果から、MACフレームをMACフレーム処理部24に出力する。また、変復調部23は、送信処理として、MACフレーム処理部24からのMACフレームに対して、変調を実行する。変復調部23は、変調した結果をベースバンドのパケット信号としてRF部22に出力する。
【0037】
本実施例に係る通信システム500では、OFDM(Orthogonal Frequency Division Multiplexing)変調方式を採用する。この場合、変復調部23は受信処理としてFFT(Fast Fourier Transform)を実行し、送信処理としてIFFT(Inverse Fast Fourier Transform)を実行する。
【0038】
MACフレーム処理部24は、受信処理として、変復調部23からのMACフレームから、セキュリティメッセージを取り出し、セキュリティ処理部25に出力する。また、MACフレーム処理部24は、送信処理として、セキュリティ処理部25からのセキュリティメッセージに対して、MACヘッダ、LLCヘッダおよびIR情報ヘッダを付加し、MACフレームを生成し、変復調部23に出力する。また、他の基地局装置20または端末装置10からのパケット信号が衝突しないようパケット信号の送受信タイミングを制御する。
【0039】
ネットワーク通信部27は、外部ネットワーク200に接続される。ネットワーク通信部27は、外部ネットワーク200から工事や渋滞等に関する道路情報を受けつける。また、ネットワーク通信部27は、セキュリティ処理部25による処理結果を外部ネットワーク200へ出力したり、記憶部28に蓄積して、定期的に外部ネットワーク200へ出力したりする。データ生成部26は、アプリケーションデータを生成する。たとえば、アプリケーションデータに道路情報をセットする。そして、アプリケーションデータの内容によって、データ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部25に出力する。記憶部28は、種々の情報を記憶する。制御部29は、基地局装置20全体の処理を制御する。
【0040】
セキュリティ処理部25は、セキュリティメッセージを生成または解釈する。セキュリティ処理部25は、送信処理として、データ生成部26からアプリケーションデータを受け取ると、MACフレーム処理部24に出力すべきセキュリティメッセージを、受け取ったアプリケーションデータ、記憶部28に記憶されているデータ、認証局から受け取った秘密鍵、公開鍵証明書、通信鍵(共通鍵)などを利用して生成する。
【0041】
例えば、図5(a)−(b)に示す「MAC方式ペイロード」の「アプリケーション」に、データ生成部26から受け取ったアプリケーションデータをセットし、そのデータ長を「MAC方式ヘッダ」の「ペイロード長」にセットする。また、図5(b)に示す「MAC方式ペイロード」の「アプリケーション」に対するハッシュ値を演算し、図5(a)に示す「MAC方式ペイロード」の「後続パケットの認証用ハッシュリスト」にセットする。また、「MAC方式ペイロード」の「後続パケットの認証用ハッシュリスト」と「アプリケーション」に対する署名を演算し、「MAC方式ペイロード」の「電子署名」にセットする。また、「MAC方式ヘッダ」の「鍵ID」に、使用する通信鍵の鍵IDをセットする。また、当該通信鍵を用いて生成されるMAC値を「MAC」にセットする。そして、その他のセキュリティヘッダを付加してセキュリティメッセージを生成する。その後、指定されたメッセージ形式が認証付き暗号化データの場合、「MAC方式ペイロード」および「MAC」を当該通信鍵を用いて暗号化することで、メッセージを秘匿する。なお、メッセージタイプが平文である場合、これらの処理は省略される。
【0042】
セキュリティ処理部25は、受信処理として、MACフレーム処理部24からのセキュリティメッセージを受けつける。セキュリティ処理部25は、セキュリティメッセージのうちのセキュリティヘッダの内容を確認する。例えば、受け付けたセキュリティメッセージが図6の車車間通信のメッセージ(以下、車車間メッセージとも呼ぶ)で、メッセージタイプが認証付きデータである場合、メッセージのMAC検証処理を実行する。メッセージタイプが認証付き暗号化データである場合、メッセージの復号処理を実行し、MAC検証処理を実行する。なお、メッセージタイプが平文である場合、これらの処理は省略される。受け付けたセキュリティメッセージが図5(a)−(b)の路車間通信のメッセージ(以下、路車間メッセージとも呼ぶ)で、メッセージタイプが認証付きデータである場合、MACおよび署名検証、ハッシュ一致確認処理を実行する。メッセージタイプが認証付き暗号化データである場合、メッセージの復号処理を実行し、MACおよび署名検証、ハッシュ一致確認処理を実行する。なお、メッセージタイプが平文である場合、これらの処理は省略される。上述のように、基地局装置20も車車間通信および路車間通信のパケット信号を受信し、パケット信号に含まれるメッセージを解釈する。また、セキュリティヘッダを確認することによって車車間メッセージなのか、路車間メッセージなのかを特定し、それに応じた受信処理を実行する。
【0043】
セキュリティ処理部25は、署名部1251、暗号部1252および記憶部1253を含む。ここでは、基地局装置20からのパケット送信に注目するため、送信処理として実行されるセキュリティメッセージを生成する処理に注目する。受信処理として行われるセキュリティメッセージを解釈する処理については、後述する端末装置10の受信処理と同じである。
【0044】
記憶部1253は、本実施例では図示しない認証局が発行する秘密鍵と、この秘密鍵と対をなす公開鍵を含む公開鍵証明書、公開鍵証明書のダイジェスト、機器ID、複数の通信鍵を内部に格納している。このうち秘密鍵と公開鍵証明書は、基地局装置20に固有である。署名部1251は、ハッシュ関数を用いて署名対象に対するハッシュ値を演算する。また、記憶部1253が格納する秘密鍵と、演算したハッシュ値を用いて署名対象に対する署名を生成する。暗号部1252は、記憶部1253に格納された通信鍵の1つを選択してMAC演算を実行し、MAC対象に対するMAC値を求める。暗号部1252は、MAC演算に用いた通信鍵を用いて暗号対象を暗号化する。
【0045】
MACは、AES(Advanced Encryption Standard)−CBC(Cipher Block Chaining)モードを利用したMACアルゴリズムを適用して生成される。なお、MACの生成には、Nonceやペイロード長も利用される。暗号化は、AES_CTR(CounTeR)モードを適用する。本実施例では、メッセージ形式が認証付き暗号化データの場合には、通信鍵を用いたAES−CCM(Counter with CBC−MAC)モードを適用するため、ペイロードに対するMACの付加およびペイロードとMACの暗号化を行う。なお、AES―CCMモードを適用せずに、ペイロードより暗号化を行った後、MACの付加を行ってもよいし、暗号化のみを行ってもよい。なお、ペイロードを対象としたMACの生成、およびペイロードとセキュリティフッタの暗号化には、通信鍵の他に、Nonceやペイロード長が利用される。CBC−MACおよびCCMモードのアルゴリズムによるものであり、Nonceの使用により、ペイロードと通信鍵が同じであっても、異なったMAC値、暗号化の結果が得られる。
【0046】
図8は、車両100に搭載された端末装置10の構成を示す。端末装置10は、アンテナ11、RF部12、変復調部13、MACフレーム処理部14、セキュリティ処理部15、受信処理部161、通知部162、データ生成部17、記憶部18および制御部19を備える。
【0047】
MACフレーム処理部14、セキュリティ処理部15、受信処理部161、通知部162、データ生成部17、記憶部18および制御部19の構成は、ハードウエア的には、任意のプロセッサ、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ハードウエアとソフトウエアの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【0048】
アンテナ11、RF部12、変復調部13およびMACフレーム処理部14は、図7のアンテナ21、RF部22、変復調部23およびMACフレーム処理部24の構成および動作と基本的に共通する。以下、これらの構成要素については、相違点を中心に説明する。アンテナ11、RF部12、変復調部13およびMACフレーム処理部14は、MACの付加や暗号化等のセキュリティ処理がなされたデータを格納したパケット信号を報知する。また、アンテナ11、RF部12、変復調部13およびMACフレーム処理部14は、共通鍵暗号方式によるセキュリティ処理がなされたデータを受信する。
【0049】
受信処理部161は、セキュリティ処理部15から受け取ったデータと、データ生成部17から受け取った自車の車両情報にもとづき、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また、データが画像情報であれば通知部162に表示するよう処理する。
【0050】
通知部162は、図示しないモニタ、ランプ、スピーカなどのユーザへの通知手段を含む。受信処理部161からの指示にしたがって、図示しない他の車両の接近などを当該通知手段を介して運転者に通知する。また、渋滞情報、交差点などの画像情報などをモニタに表示する。
【0051】
データ生成部17は、図示しないGPS受信機、ジャイロスコープ、車速センサなどから供給される情報にもとづき、端末装置10が搭載された車両100の現在位置、進行方向、移動速度などを特定する。なお、現在位置は、緯度・経度によって示される。これらの情報の特定方法は一般的な公知の技術により実現可能であるため、ここでは説明を省略する。データ生成部17は、特定した情報をもとに他の端末装置10や基地局装置20に報知すべきデータを生成し、生成したデータ(以下、アプリケーションデータという)をセキュリティ処理部15に出力する。そして、アプリケーションデータの内容によって、メッセージ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部15に出力する。また、特定した情報を受信処理部161に自車の車両情報として出力する。
【0052】
記憶部18は、種々の情報を記憶する。例えば、本実施例では基地局装置20から取得される道路情報、自己または他の端末装置10から取得される車両情報を保持する。制御部19は、端末装置10全体の処理を制御する。
【0053】
セキュリティ処理部15は、セキュリティメッセージを生成または解釈する。セキュリティ処理部15は、送信処理として、MACフレーム処理部14に出力すべきセキュリティメッセージを、記憶部18に記憶されたデータをもとに生成する。例えば、図6に示す「MAC方式ペイロード」の「アプリケーション」に、データ生成部17から受け取ったアプリケーションデータをセットする。また、「MAC方式ヘッダ」の「鍵ID」に、MAC生成に使用する通信鍵の鍵IDをセットし、「Nonce」の「機器ID」、「乱数」に自己の機器IDと、生成した乱数をセットする。また、鍵IDによって共通鍵テーブルより選択された通信鍵を用いて生成されるMAC値を「MAC方式フッタ」の「MAC」にセットする。通信鍵は、共通鍵テーブルから任意に選択される。
【0054】
セキュリティ処理部15は、その他の情報を付加してセキュリティメッセージを生成する。メッセージ形式が、認証付き暗号化データの場合、ペイロードおよびMACを当該通信鍵を用いて暗号化することで、メッセージを秘匿する。なお、メッセージタイプが平文である場合、これらの処理は省略される。このようにセキュリティ処理部15は、共通鍵テーブルに格納された共通鍵のうち、いずれかを使用することによって、データに対するセキュリティ処理を実行する。送信処理におけるセキュリティ処理とは、前述のごとく、MACを生成することや、暗号化することである。
【0055】
セキュリティ処理部15は、受信処理として、MACフレーム処理部14からのセキュリティメッセージを受け付ける。セキュリティ処理部15は、セキュリティメッセージのうちのセキュリティヘッダの内容を確認する。例えば、受け付けたセキュリティメッセージが図6の車車間メッセージで、メッセージタイプが認証付きデータである場合、メッセージの検証処理を実行する。メッセージ形式が認証付き暗号化データである場合、メッセージの復号処理および検証処理を実行する。なお、メッセージ形式が平文である場合、これらの処理は省略される。受け付けたセキュリティメッセージが図5(a)−(b)の路車間通信メッセージで、メッセージタイプが認証付きデータである場合、MACおよび署名検証、ハッシュ一致確認処理を実行する。メッセージタイプが認証付き暗号化データである場合、メッセージの復号処理を実行し、MACおよび署名検証、ハッシュ一致確認処理を実行する。なお、セキュリティヘッダを確認することによって車車間メッセージなのか、路車間メッセージなのかを特定し、それに応じた受信処理を実行する。
【0056】
メッセージタイプが認証付きデータまたは認証付き暗号化データである場合、セキュリティ処理部15は、図5(a)−(b)または図6に示すセキュリティメッセージを受け付けると、鍵IDにしたがって、共通鍵テーブルに格納された共通鍵のうち、セキュリティメッセージに対して使用された共通鍵を通信鍵として取り出す。
【0057】
セキュリティ処理部15は、取り出した通信鍵によって、セキュリティ処理の送信処理とは逆の受信処理を実行する。すなわち、メッセージタイプが認証付きデータの場合、「Nonce」、「ペイロード長」、「MAC方式ペイロード」に対するMAC値を生成し、「MAC」に格納されたMAC値と比較する。一致すればメッセージの完全性が確認される。また、メッセージタイプが認証付き暗号化データの場合、「MAC方式ペイロード」および「MAC方式フッタ」を復号し、復号後の「Nonce」、「ペイロード長」、「MAC方式ペイロード」に対するMAC値を生成し、「MAC」に格納されたMAC値と比較する。一致すればメッセージの完全性が確認される。
【0058】
また、図5(a)に示すセキュリティメッセージでは、「電子署名」の検証を行う。検証に成功すれば、メッセージの発信元の真正性が確認できる。図5(b)に示すセキュリティメッセージでは、「アプリケーション」に対するハッシュ値を演算し、同じグループの図5(a)に示すセキュリティメッセージの「後続パケットの認証用ハッシュリスト」に含まれる自身に対するハッシュ値と比較する。同じグループの図5(a)に示すセキュリティメッセージの署名検証に成功し、かつハッシュ値が一致すれば、メッセージの発信元の真正性が確認される。セキュリティ処理の受信処理とは、メッセージの検証処理やメッセージの復号処理である。
【0059】
セキュリティ処理部15は、検証部1151、復号部1152および記憶部1153を含む。記憶部1153は、本実施例では図示しない認証局が発行する認証用の公開鍵と、自身の機器ID、共通鍵テーブルを内部に格納している。復号部1152は、セキュリティメッセージの「鍵ID」により特定される通信鍵を記憶部1153から取得して、暗号対象を復号する。検証部1151は、ハッシュ関数を用いたハッシュ値の演算と、ハッシュ値および記憶部1153に格納されている認証用の公開鍵を用いて基地局装置20の公開鍵証明書の署名を検証する。また「電子署名」に格納された署名を、公開鍵証明書に含まれる公開鍵を用いて検証する。また、セキュリティメッセージの「鍵ID」により特定される通信鍵を用いて、MAC検証をする。なお、認証用の公開鍵は、認証局において公開鍵証明書の署名を生成するのに用いた秘密鍵と対をなす公開鍵である。なお、復号および検証は送信側の暗号アルゴリズムに対応する復号アルゴリズムにより実行される。また、メッセージ形式が平文である場合、復号および検証は実行されない。
【0060】
図9は、本実施例に係る通信システム500を用いた車車間通信におけるメッセージ送受信手順を説明するための図である。なお図9の送信側および受信側の端末装置10は、図8の構成を備えるものとする。送信側の端末装置10(図左)のセキュリティ処理部15は、共通鍵テーブルからひとつの通信鍵をランダムに選択する。図9における鍵テーブルが共通鍵テーブルに相当する。セキュリティ処理部15は、平文の送信データに対して当該通信鍵を用いてMACを生成し、MAC付きの送信データを暗号化する。セキュリティ処理部15は、暗号化送信データと、選択された通信鍵の鍵IDを格納したパケット信号を生成する。当該パケット信号は、MACフレーム処理部14および変復調部13を経て、RF部12からアンテナ11を介して外部に報知される。
【0061】
受信側の端末装置10(図右)のRF部12は、当該パケット信号をアンテナ11を介して受信する。当該パケット信号は、変復調部13およびMACフレーム処理部14を経て、セキュリティ処理部15に渡される。セキュリティ処理部15は、当該パケット信号に格納された鍵IDにより特定される通信鍵を共通鍵テーブルから読み出し、当該パケット信号に格納された暗号化送信データを、当該通信鍵で復号し、MAC検証する。MAC検証が成功したら、暗号化送信データは平文の送信データに復元される。このような共通鍵暗号に関わる送信処理および受信処理は、基地局装置20においてもなされる。以降では、路車間送信期間に基地局装置20から送信される図5(a)と図5(b)に従うセキュリティメッセージを路車間メッセージ、車車間送信期間に端末装置10から送信される図6に従うセキュリティメッセージを車車間メッセージと呼ぶものとする。また、図3(b)の先頭のRSUパケットには、図5(a)に従う路車間メッセージ(先頭の路車間メッセージと呼ぶ)が、後続のRSUパケットには、図5(b)に従う路車間メッセージ(後続の路車間メッセージと呼ぶ)が含まれる。
【0062】
このメッセージ送受信方法には以下に示す様々なメリットがある。まず、静的に通信鍵を使用するため、データ通信量を抑えられる。また、複数の通信鍵を保持しておくことにより、通信路中から通信鍵が漏洩するリスクを小さくできる。また、共通鍵テーブルが漏洩した場合、共通鍵テーブルに新しい鍵を追加することにより、セキュリティ低下を抑えることができる。
【0063】
図10は、「メッセージ形式」の詳細である。先頭の2ビットである認証タイプ(AT)は、1ビットの2つのフラグ情報MAC FlagとSIG Flagからなる。MAC Flagは、共通鍵暗号方式によるMAC認証に対応するか否かを示し、SIG Flagは、公開鍵暗号方式による署名認証に対応するか否かを示す。MAC認証のみに対応する場合、MAC Flag=1、SIG Flag=0となる。MAC認証と署名認証の両方に対応する場合、MAC Flag=1、SIG Flag=1となる。メッセージタイプ(MT)には、平文データ形式(=0)、認証付きデータ形式(=1)および認証付き暗号化データ形式(=2)がある。また、認証タイプ(AT)を利用して、車車間メッセージ(図6)と路車間メッセージ(図5(a)−(b))を特定できるようにすることもできる。例えば、車車間メッセージ(図6)ではAT=1、先頭の路車間メッセージ(図5(a))ではAT=3、後続の路車間メッセージ(図5(b))ではAT=2とすれば、セキュリティメッセージのデータ構造を特定することが可能である。
【0064】
図11は、検証部1151の構成例を示す。構成例に係る検証部1151は、ハッシュ比較部1151a、署名検証部1151b、ダイジェスト保持部1151c、MAC検証部1151d、判定部1151eを含む。
【0065】
署名検証部1151bは、先頭の路車間メッセージに含まれる公開鍵証明書の署名、およびハッシュリストを少なくとも含むデータ列から生成された署名を検証する。図5(a)のデータ構造では、当該データ列は、ハッシュリストとアプリケーションデータで構成される。公開鍵証明書の署名は、認証局が発行する認証用の公開鍵を用いて検証する。当該データ列に対する署名は、公開鍵証明書に含まれる公開鍵を用いて検証する。
【0066】
署名検証部1151bは、先頭の路車間メッセージに含まれるハッシュリストをダイジェスト保持部1151cに格納する。また署名検証部1151bは、先頭の路車間メッセージに含まれる公開鍵証明書のダイジェストを生成し、ダイジェスト保持部1151cに格納する。ハッシュ比較部1151aは、ダイジェスト保持部1151cに保持される公開鍵証明書のダイジェストと、受信した先頭の路車間メッセージに含まれる公開鍵証明書から生成した公開鍵証明書のダイジェストとが一致する場合、当該先頭の路車間メッセージに含まれる公開鍵証明書の署名検証成功と判定してもよい。
【0067】
MAC検証部1151dは、先頭の路車間メッセージ、後続の路車間メッセージ、および車車間メッセージに含まれるMACを検証する。MACは、鍵IDで特定される通信鍵を用いて検証する。
【0068】
ハッシュ比較部1151aは、後続の路車間メッセージに含まれるアプリケーションデータを少なくとも含むデータ列からハッシュ値を演算する。ハッシュ比較部1151aは、演算したハッシュ値と、ダイジェスト保持部1151cに保持されるハッシュリスト内のハッシュ値とを比較する。
【0069】
判定部1151eは、署名検証部1151bによる署名の検証結果、MAC検証部1151dによるMACの検証結果、ハッシュ比較部1151aによるハッシュの比較結果をもとに、セキュリティメッセージを承認するか否か判定する。車車間メッセージでは、MAC検証に成功したとき、先頭の路車間メッセージでは、MAC検証に成功し、かつ署名検証に成功したとき、後続の路車間メッセージでは、MAC検証に成功し、ハッシュ値が一致し、かつ先頭の路車間メッセージの署名検証に成功したとき、セキュリティメッセージを承認する。車車間メッセージでは、MAC検証に失敗したとき、先頭の路車間メッセージでは、MAC検証に失敗、または署名検証に失敗したとき、後続の路車間メッセージでは、MAC検証の失敗、先頭の路車間メッセージの署名検証の失敗およびハッシュ値の不一致がひとつでも発生したとき、メッセージを否認する。
【0070】
図12は、本実施例に係る、端末装置10でのメッセージ検証処理の一例を示すフローチャートである。受信部は、基地局装置20または他の端末装置10から報知されたパケット信号を受信する(S10)。なお受信部は、アンテナ11、RF部12、変復調部13、MACフレーム処理部14により実現される。
【0071】
受信したパケット信号のセキュリティメッセージ内の「メッセージタイプ」のフラグが参照され、メッセージが暗号化データである場合(S11のY)、復号部1152は、セキュリティメッセージの暗号化部分を復号する(S12)。図4図5(a)、及び図5(b)に示すデータ構造では「MAC方式ペイロード」および「MAC方式フッタ」が暗号化部分である。復号部1152は、セキュリティメッセージの「鍵ID」により特定される通信鍵を記憶部1153から取得して、「MAC方式ペイロード」及び「MAC方式フッタ」を復号する。メッセージが暗号化データでない場合(S11のN)、ステップS12はスキップされる。
【0072】
メッセージがMAC付きデータである場合(S13のY)、MAC検証部1151dはMAC検証を実行する(S14)。MAC検証の詳細は後述する。メッセージがMAC付きデータでない場合(S13のN)、ステップS14はスキップされる。
【0073】
メッセージが署名付きデータである場合(S15のY)、ステップS16に進み、署名付きデータでない場合(S15のN)、ステップS19に進む。本実施例では路車間メッセージでは署名を使用し、車車間メッセージでは署名を使用しないため、基地局装置20から報知されたパケット信号の場合はステップS16に進み、他の端末装置10から報知されたパケット信号の場合はステップS19に進む。
【0074】
ステップS16では、メッセージを構成する複数のパケットのうち、先頭のパケットであるか否か判定する(S16)。先頭のパケットである場合(S16のY)、署名検証部1151bは署名検証を実行する(S17)。署名検証の詳細は後述する。先頭以外のパケットである場合(S16のN)、ハッシュ比較部1151aはハッシュ一致検証を実行する(S18)。ハッシュ一致検証の詳細は後述する。
【0075】
判定部1151eは、実行された検証の全ての結果が成功の場合、受信したメッセージを正当なメッセージと判定する(S19)。車車間メッセージの場合、MAC検証が成功したら正当と判定する。路車間メッセージの場合、MAC検証、署名検証およびハッシュ一致検証が成功したら正当と判定する。いずれかが失敗したら正当でないと判定する。
【0076】
ステップS10〜ステップS19までの処理は、電源オンの間(S20のN)、繰り返し実行される。電源オフされると(S20のY)、全体の処理を終了する。
【0077】
図13は、図12のMAC検証のサブルーチンを示すフローチャートである。MAC検証部1151dは、セキュリティメッセージのMAC対象部分のMAC値を演算する(S142)。図5(a)に示す路車間メッセージの先頭パケットのセキュリティメッセージでは、「Nonce」、「ペイロード長」、「公開鍵証明書」、「後続パケットの認証用ハッシュリスト」、「アプリケーション」、「電子署名」がMAC対象部分である。図5(b)に示す路車間メッセージの後続パケットのセキュリティメッセージでは、「Nonce」、「ペイロード長」、「証明書ダイジェスト」、「アプリケーション」がMAC対象部分である。図6に示す車車間メッセージのパケットでは、「Nonce」、「機器管理コード」、「アプリケーション」がMAC対象部分である。
【0078】
MAC検証部1151dは、セキュリティメッセージの「MAC」に格納されたMAC値と、演算したMAC値を比較し(S143)、一致したときは(S143のY)、判定部1151eに検証成功を通知し(S144)、一致しないときは(S143のN)、判定部1151eに検証失敗を通知する(S145)。検証成功であれば、メッセージの完全性を確認できる。
【0079】
図14は、図12の署名検証のサブルーチンを示すフローチャートである。サブルーチンは、署名検証部1151bは、セキュリティメッセージの「公開鍵証明書」に格納された公開鍵証明書のダイジェストを演算する(S172)。本実施例では公開鍵証明書の署名対象部分のハッシュ値を演算する。署名検証部1151bは、演算した公開鍵証明書のダイジェスト及び「後続パケットの認証用ハッシュリスト」に格納されたハッシュリストをダイジェスト保持部1151cに退避させる(S173)。
【0080】
署名検証部1151bは、公開鍵証明書の署名を、予め保持する認証用の公開鍵を用いて検証する(S174)。この署名検証は、公開鍵証明書の検証に成功したときに、公開鍵証明書のダイジェスト、あるいは、識別番号などの代表値を記憶部1153に保持しておき、ダイジェスト保持部1151cに代表値が保持されているときには、代表値の一致判定で代替してもよい。ダイジェスト保持部1151cに保持される公開鍵証明書のダイジェストと、演算された公開鍵証明書の代表値が一致すれば、以前に受信した基地局装置20からのパケット信号に含まれるセキュリティメッセージと判定できる。なお、ダイジェスト保持部1151cに代表値が保持されていないときは、必ず署名の検証を行う。公開鍵証明書の署名検証が失敗した場合(S174のN)、判定部1151eに検証失敗を通知する(S178)。検証成功であれば、メッセージの発信元の真正性を確認できる。
【0081】
公開鍵証明書の署名検証が成功した場合(S174のY)、署名検証部1151bは、図5(a)に従う路車間メッセージの場合の電子署名の対象部分である「後続の路車間メッセージのための認証用ハッシュリスト」、「アプリケーション」を対象とするハッシュを演算する(S175)。署名検証部1151bは、ステップS174で署名の検証に成功した公開鍵証明書の公開鍵を用いて、セキュリティメッセージの「電子署名」に格納された電子署名と、演算したハッシュに基づく署名検証の確認を行う(S176)。署名検証が成功した場合(S176のY)、判定部1151eに検証成功を通知し(S177)、署名検証が失敗した場合(S176のN)、判定部1151eに検証失敗を通知する(S178)。検証成功であれば、先頭の路車間メッセージの発信元の真正性を確認できる。
【0082】
図15は、図12のハッシュ一致検証のサブルーチンを示すフローチャートである。ハッシュ比較部1151aは、ダイジェスト保持部1151cにハッシュリストが保持されているか否か確認する(S182)。複数の基地局装置20からパケット信号が報知されている場合、複数のハッシュリストがダイジェスト保持部1151cに保持されるが、公開鍵証明書のダイジェストを用いることにより、同一の基地局装置20により生成されたハッシュリストを特定できる。ステップS182において、同一の基地局装置20のハッシュリストが保持されていない場合(S182のN)、判定部1151eに検証失敗を通知する(S186)。同一の基地局装置20のハッシュリストが保持されている場合(S182のY)、ハッシュ比較部1151aは、セキュリティメッセージの「アプリケーション」のハッシュ値を演算する(S183)。
【0083】
ハッシュ比較部1151aは、ダイジェスト保持部1151cに保持されるハッシュリスト内のハッシュ値と、演算したハッシュ値を比較する(S184)。その際、パケットの番号が同じもの同士を比較する。ハッシュ値が一致したときは(S184のY)、判定部1151eに検証成功を通知し(S185)、一致しないときは(S184のN)、判定部1151eに検証失敗を通知する(S186)。検証成功であれば、後続の路車間メッセージの真正性を確認できる。
【0084】
図12から図15では、MAC検証、署名検証、ハッシュ一致検証を時系列順に処理する例を想定したが、以下、MAC検証、署名検証、ハッシュ一致検証を並行して処理する例を説明する。この例は、MAC検証用の専用ハードウェア、署名検証用の専用ハードウェア、ハッシュ一致検証用の専用ハードウェアを実装する場合や、複数のコアで複数の検証処理を別々に処理できる場合に適用できる。
【0085】
図16は、本実施例に係る、端末装置10でのメッセージ検証処理の別の例を示すフローチャートである。ステップS10〜ステップS12までの処理は、図12のフローチャートと同じである。
【0086】
受信したパケット信号のセキュリティメッセージが検証可能な状態になると、MAC検証部1151d、署名検証部1151b、ハッシュ比較部1151aは、それぞれ独立に検証処理を実行する(S14、S17、S18)。判定部1151eは、全ての検証結果が揃った時点で、受信したメッセージが正当なメッセージであるか否か判定する(S19)。ステップS10〜ステップS19までの処理は、電源オンの間(S20のN)、繰り返し実行される。電源オフされると(S20のY)、全体の処理を終了する。
【0087】
図17は、図16のMAC検証のサブルーチンを示すフローチャートである。MAC検証部1151dは、受信したパケット信号のセキュリティメッセージ内の「メッセージタイプ」のフラグを参照し、メッセージがMAC付きデータである場合(S141のY)、ステップS142に進む。MAC付きデータでない場合(S141のN)、判定部1151eに対象外であることを通知する(S146)。ステップS142以降の処理は、図13と同じである。
【0088】
図18は、図16の署名検証のサブルーチンを示すフローチャートである。署名検証部1151bは、受信したパケット信号のセキュリティメッセージ内の「メッセージタイプ」のフラグを参照し、メッセージが署名付きデータであり、かつ先頭の路車間メッセージである場合(S171のY)、ステップS172に進む。そうでない場合(S171のN)、判定部1151eに対象外であることを通知する(S179)。ステップS172以降の処理は、図14と同じである。
【0089】
図19は、図16のハッシュ一致検証のサブルーチンを示すフローチャートである。ハッシュ比較部1151aは、受信したパケット信号のセキュリティメッセージ内の「メッセージタイプ」のフラグを参照し、メッセージが署名付きデータであり、かつ後続の路車間メッセージである場合(S181のY)、ステップS182に進む。そうでない場合(S181のN)、判定部1151eに対象外であることを通知する(S187)。ステップS182以降の処理は、図15と同じである。なお、「電子署名」が「アプリケーション」の前に配置される場合、ステップS181において、メッセージが署名付きデータであれば、ステップS182に進む。
【0090】
以上説明したように、署名、MAC、ハッシュリストを併用したメッセージフォーマットを採用することにより、軽負荷で発信元の特定ができるメッセージ検証を実現できる。すなわち、署名検証により発信元を特定できる。署名検証が成功したら、同一の公開鍵証明書を含むメッセージのMAC検証成功およびハッシュ値一致によりメッセージを承認する。これにより、処理負荷を軽減できる。また署名検証を公開鍵証明書のダイジェストの一致で代替することにより、処理負荷をさらに軽減できる。署名検証コアと共通鍵コアを併用することで、発信元の特定と、リアルタイムでのメッセージ検証の両方を実現できる。
【0091】
基地局装置20から報知される路車間通信のパケット信号に含まれるセキュリティメッセージは次のように構成されてもよい。図20(a)−(b)は、セキュリティメッセージのデータ構造のさらに別の一例を示す。図5(a)−(b)の変形例である。図20(a)は、図3(b)に示された複数のRSUパケットのうちの、先頭のRSUパケットのセキュリティメッセージであり、図5(a)に相当する。図20(b)は、2番目以降のRSUパケットのセキュリティメッセージであり、図5(b)に相当する。
【0092】
図5(a)のデータ構造では「電子署名」が「アプリケーション」の後に配置されるが、図20(a)のデータ構造では「電子署名」が「アプリケーション」の前に配置される。図20(a)のデータ構造では、先頭のRSUパケットの「パケットの認証用ハッシュリスト」には、グループを構成するすべてのセキュリティメッセージの「アプリケーション」に対するハッシュ値を配置したリストがセットされる。電子署名の対象は「パケットの認証用ハッシュリスト」のみである。これによって処理を単一化できる。また、先頭のRSUパケットのアプリケーションデータの通信喪失による欠落によって、「パケットの認証用ハッシュリスト」に対する電子署名の検証ができなくなることを防止できる。また、早期に署名検証処理を始めることができる。図20(b)のデータ構造と図5(b)のデータ構造は同じである。図20(a)に従う路車間メッセージを先頭の路車間メッセージ、図20(b)に従う路車間メッセージを後続の路車間メッセージと呼ぶ。
【0093】
なお、図20(a)−(b)に従う路車間メッセージの場合でも、端末装置10は、図12のフローチャートにしたがいメッセージ検証処理を行う。但し、先頭の路車間メッセージの「アプリケーションデータ」に対するハッシュ値も「パケットの認証用ハッシュリスト」に配置されているため、先頭の路車間メッセージについても図12のステップS18のハッシュ一致検証が実行されるように変更される。すなわち、ステップS18は、ステップS15のYとステップS16の間で処理される。
【0094】
図21は、図20(a)−(b)に従う路車間メッセージの場合の署名検証のサブルーチンを示すフローチャートである。図14のフローチャートと図21のフローチャートは基本的に同じであるが、ステップS175のハッシュの演算処理が異なる。図21のフローチャートでは、署名検証部1151bは、図20(a)に従う路車間メッセージの場合の電子署名の対象部分である「後続パケットの認証用ハッシュリスト」のハッシュを演算する(S175a)。演算して求めたハッシュと、路車間メッセージに含まれる電子署名に基づいて「ハッシュリスト」の署名検証を確認する(S176a)。その他の処理は、図14のフローチャートと同じである。MAC検証およびハッシュ一致検証のサブルーチンは、図13図15と同じである。
【0095】
同様に、図20(a)−(b)に従う路車間メッセージの場合でも、端末装置10は、図16図19のフローチャートに従いメッセージ検証処理を行う。但し、署名検証の対象が、「後続パケットの認証用ハッシュリスト」と「アプリケーションデータ」から、「後続パケットの認証用ハッシュリスト」に変更されているため、図18のステップS175において「後続パケットの認証用ハッシュリスト」に対してのみのハッシュを演算するように変更し、ステップS176において「ハッシュリストとアプリケーションの署名検証成功」を確認するように変更する。また、先頭の路車間メッセージの「アプリケーションデータ」に対するハッシュ値も「パケットの認証用ハッシュリスト」に配置されているため、図19のステップS181において、署名付きデータかどうかの判断を行うように変更し、先頭の路車間メッセージのときにも、ステップS182に移行するように変更する。
【0096】
以下では、これまで説明した処理をレイヤとの関連で説明する。図22(a)は、基地局装置20において、図22(b)は端末装置10において規定されるレイヤの構成を示す。図22(a)の基地局装置20における送信処理のレイヤ構成を説明する。アプリケーションレイヤは、データ生成部26またはネットワーク通信部27に含まれる。具体的には、基地局装置20の記憶部28に事前に保持されている道路線形情報やセンサ設置情報、基地局装置20と併設された信号機の灯消情報、あるいは基地局装置20の周辺に設置されたセンサによって検知された車両や人の位置や移動などを示すセンサ情報など基地局装置20から発信されるアプリケーションデータに対応するアプリケーションレイヤはデータ生成部26に含まれる。工事情報、落下物情報、渋滞情報あるいは緊急車両などの交通管制センタからネットワークを介して供されるアプリケーションデータに対応するアプリケーションレイヤはネットワーク通信部27に含まれる。分割処理層、パケット管理層、セキュリティ層は、図7のセキュリティ処理部25に含まれ、無線送信層は、図7のRF部22、変復調部23、MACフレーム処理部24に含まれる。
【0097】
図22(b)の端末装置10における受信処理のレイヤ構成を説明する。アプリケーションレイヤは、図8の受信処理部161に含まれ、分割処理層、パケット管理層、セキュリティ層は、図8のセキュリティ処理部15に含まれ、無線受信層は、図8のRF部12、変復調部13、MACフレーム処理部14に含まれる。
【0098】
アプリケーションレイヤは、1種類あるいは複数種類のアプリケーションによって構成される。ここでは、3種類のアプリケーションAPP1、APP2およびAPP3によって構成され、それぞれがアプリケーションデータD1、D2およびD3を提供するものとする。分割処理層には、送信対象となるアプリケーションデータがアプリケーションレイヤより入力される。
【0099】
図23(a)−(e)は、基地局装置20における送信処理の各レイヤにおける処理の概要を示す。なお、横軸は時間を示す。図23(a)は、分割処理層に入力されるアプリケーションデータを示す。分割処理層は、複数のアプリケーションから入力されたアプリケーションデータを送信順序に並べ、それぞれのアプリケーションデータのサイズと下位の各層、特にセキュリティ層によって付加されるヘッダあるいはフッタといった付加データのサイズを考慮して、それを送信可能なサイズに分割する。図23(b)は、分割処理層によって分割されたデータの系列を示す。例えば、D1は、D1(i)とD1(ii)に分割される。分割されたデータのそれぞれには、ELヘッダが付加される。図22(a)に戻る。ELヘッダには、受信時に分割されたアプリケーションデータを再構成するための結合情報が含まれている。分割処理層は、分割したデータをパケット管理層に出力する。
【0100】
パケット管理層は、分割されたデータのうち、先頭に現在の日時を送信日時として付加する。送信日時はリプレイス攻撃対策として付加する。図23(c)は、パケット管理層によって、送信日時が付加されたデータの系列を示す。図22(a)に戻る。パケット管理層は、送信日時が付加されたデータをセキュリティ層に出力する。セキュリティ層は、送信日時が付加されたデータに対してセキュリティ処理を実行する。図23(d)は、セキュリティ処理がなされたデータを示す。例えば、MACヘッダ、公開鍵証明書、ハッシュリスト、署名、MAC、ダイジェストが、データに付加される。ハッシュリストは、データ単位に生成されるので、D1(i)、D1(ii)等のそれぞれに対して生成されたハッシュ値を含む。図22(a)に戻る。セキュリティ層は、セキュリティ処理がなされたデータをパケット管理層に出力し、パケット管理層は、これを無線送信層に出力する。無線送信層は、各データをパケット信号に格納し、パケット信号を報知する。図23(e)は、パケット信号を示す。ここで、SL1、SL2等は、前述の路車間送信期間を示し、P1、P2等は、パケット信号を示す。
【0101】
端末装置10の受信処理は、図23における処理を(e)から(b)に逆順で進み、ELヘッダを参照してアプリケーションデータD1、D2およびD3を再構成して、それぞれを対応するアプリケーションAPP1、APP2およびAPP3に出力する。
【0102】
次に、データを分割する状況下において、セキュリティ処理を簡易にする処理を説明する。これまでは、データを分割してからハッシュリストを生成していた。前述のごとく、ハッシュリストのサイズは、分割されたデータの数に依存する。つまり、当該サイズは、可変値であり、固定値ではない。そのため、ハッシュリストのサイズが大きくなることによって、ひとつのパケット信号に格納できなくなった場合に、さらにデータを分割し、ハッシュリストが再度作成される。このような処理を簡易にするために、データを分割する前にハッシュリストを生成し、ハッシュリストが付加されたデータを分割する。データの数は入力時に認識されるので、ハッシュリストのサイズは、その時点で固定される。その結果、分割処理においてハッシュリストのサイズは、固定値とみなされるので、処理が簡易になる。
【0103】
図7において、セキュリティ処理部25は、複数種類のアプリケーションデータを入力する。セキュリティ処理部25は、複数種類のアプリケーションデータのそれぞれに対して、公開鍵暗号方式を使用することによって導出した各データの代表値が含まれたリストを生成する。ここでは、アプリケーションデータ毎にハッシュ関数を適用することによって、ハッシュ値を生成する。さらに、セキュリティ処理部25は、複数のアプリケーションデータのそれぞれに対するハッシュ値をまとめることによってハッシュリストを生成する。この段階において、ハッシュリストは固定値となる。セキュリティ処理部25は、ハッシュリストと、複数種類のアプリケーションデータとを複数に分割する。その際、先頭のアプリケーションデータの前段にハッシュリストが付加される。また、分割はアプリケーションプログラム単位になされる。さらに、MACフレーム処理部24は、分割結果のそれぞれをパケット信号に格納することによって、複数のパケット信号を生成する。変復調部23、RF部22は、複数のパケット信号を報知する。
【0104】
図24(a)は、基地局装置20において、図24(b)は端末装置10において規定されるレイヤの構成を示す。図22(a)−(b)と同様に、ここでも、基地局装置20における送信処理のレイヤ構成を説明する。アプリケーションレイヤは、データ生成部26またはネットワーク通信部27に含まれる。分割管理層、上位セキュリティ層、パケット管理層、下位セキュリティ層は、図7のセキュリティ処理部25に含まれ、無線送信層は、図7のRF部22、変復調部23、MACフレーム処理部24に含まれる。図24(b)の端末装置10における受信処理のレイヤ構成を説明する。アプリケーションレイヤは、図8の受信処理部161に含まれ、分割処理層、上位セキュリティ層、パケット管理層、下位セキュリティ層は、図8のセキュリティ処理部15に含まれ、無線受信層は、図8のRF部12、変復調部13、MACフレーム処理部14に含まれる。
【0105】
図25(a)−(f)は、基地局装置20における送信処理の各レイヤにおける処理の概要を示す。図25(a)は、分割処理層に入力されるアプリケーションデータを示し、これは図23(a)と同一である。図24(a)に戻る。分割処理層は、入力したアプリケーションデータのうち、先頭に送信日時を付加する。図25(b)は、送信日時が付加されたアプリケーションデータの系列を示す。図24(a)に戻る。分割処理層は、送信日時が付加されたアプリケーションデータを上位セキュリティ層に出力する。
【0106】
上位セキュリティ層は、送信日時が付加されたアプリケーションデータに対してセキュリティ処理を実行する。図25(c)は、セキュリティ処理がなされたデータを示す。例えば、公開鍵証明書、ハッシュリスト、署名、ダイジェストが、アプリケーションデータに付加される。図24(a)に戻る。上位セキュリティ層は、セキュリティ処理がなされたアプリケーションデータを分割処理層に出力する。
【0107】
分割処理層は、セキュリティ処理がなされたアプリケーションデータのサイズに応じて、それを分割する。図25(d)は、分割処理層によって分割されたデータの系列を示す。図23(b)と同様に、D1は、D1(i)とD1(ii)に分割される。分割されたデータのそれぞれには、ELヘッダが付加される。図24(a)に戻る。分割処理層は、分割したデータをパケット管理層に出力し、パケット管理層は、これを下位セキュリティ層に出力する。
【0108】
下位セキュリティ層は、分割されたデータに対してセキュリティ処理を実行する。図25(e)は、セキュリティ処理がなされたデータを示す。例えば、MACヘッダ、MACがデータに付加される。図24(a)に戻る。下位セキュリティ層は、セキュリティ処理がなされたデータをパケット管理層に出力し、パケット管理層は、これを無線送信層に出力する。無線送信層は、各データをパケット信号に格納し、パケット信号を報知する。図25(f)は、パケット信号を示しており、これは、図23(e)と同一である。端末装置10の受信処理は、図25における処理を(f)から(b)に逆順で進み、ELヘッダを参照してアプリケーションデータD1、D2およびD3を再構成して、それぞれを対応するアプリケーションAPP1、APP2およびAPP3に出力する。
【0109】
これまで基地局装置20は、ハッシュリストと先頭のデータとを同一のパケット信号に格納しているが、これらを別のパケット信号に含めてもよい。つまり、セキュリティ処理部25は、複数種類のデータが含まれていないパケット信号にハッシュリストを含める。そのため、データが含まれたパケット信号と、ハッシュリストが含まれたパケット信号とが別に生成される。また、ここまで端末装置10を路車間メッセージの受信先として説明したが、ある基地局装置20が送信した路車間メッセージを別の基地局装置20が受信することもできる。この場合、上述した端末装置10の受信に関する内容は、基地局装置20にも適用されることは明らかである。
【0110】
図26(a)−(f)は、各レイヤにおける別の処理の概要を示す。これらは、図25(a)−(f)と同様に示されているので、差異のみを説明する。図26(c)は、セキュリティ処理がなされたデータを示す。ここで、ハッシュリストは、D1に連結されずに、別々に構成されている。
【0111】
これまで、基地局装置20および端末装置10から報知されるパケット信号は、原則的に、全ての基地局装置20および端末装置10が受信可能なことを前提とした。即ち、汎用サービスを前提とした。以下、特定の基地局装置20または特定の端末装置10に対してのみデータを提供する特定サービスについて説明する。特定サービスには、基地局装置20間(路側機間)でデータをやりとりする路路間サービス、基地局装置20から特定の端末装置10にデータを提供する路車間特定サービスがある。路車間特定サービスは、例えば有償契約を結んでいる車載機のみにデータを提供するサービスである。いずれも基地局装置20が送信する路車間メッセージによって情報伝達を行うサービスとする。
【0112】
図27は、汎用サービスと特定サービスが併用される通信システムにおけるデータ構造の一例を示す図である。コンテナとは、複数のサービスに対するデータをまとめたものである。コンテナは、複数のメッセージで構成される。図中、N(自然数)はコンテナを構成するセキュリティメッセージの数を、M(正の整数)はコンテナを識別するための識別番号である。メッセージ#1は、「ヘッダ」、「鍵情報」、「公開鍵証明書」、「ハッシュリスト」、「署名」、「フレームID、メッセージID、分割数」、「アプリケーション」、「MAC」が配置される。メッセージ#1のデータ構造は、図20(a)のセキュリティメッセージのデータ構造に、メッセージ#2、・・・・、メッセージ#Nのデータ構造は、図20(b)のセキュリティメッセージのデータ構造に基本的に対応している。
【0113】
「ハッシュリスト」には、コンテナを構成する複数のメッセージ♯1〜♯Nのそれぞれのダイジェストがセットされる。ダイジェストは、「フレームID、メッセージID、分割数」および「アプリケーション」に対するハッシュ値が使用される。「署名」には、「ハッシュリスト」を、公開鍵証明書に含まれる公開鍵と対をなす秘密鍵で暗号化して生成される電子署名がセットされる。フレームIDはコンテナの識別情報である。メッセージIDはメッセージの識別情報である。分割数はコンテナの分割数である。「MAC」には、「公開鍵証明書」、「ハッシュリスト」、「署名」、「フレームID、メッセージID、分割数」、「アプリケーション」に対するMAC値がセットされる。「公開鍵証明書」、「ハッシュリスト」、「署名」、「フレームID、メッセージID、分割数」、「アプリケーション」、「MAC」は暗号化される。
【0114】
メッセージ#2〜#Nは、「ヘッダ」、「鍵情報」、「署名者ID」、「フレームID、メッセージID、分割数」、「アプリケーション」、「MAC」が配置される。メッセージ#2〜♯Nのデータ構造は、図5(b)のセキュリティメッセージのデータ構造に基本的に対応している。
【0115】
「署名者ID」には、メッセージ♯1の「署名」を作成した署名者の識別情報がセットされる。図20(b)における「証明書ダイジェスト」に相当する。「MAC」には、「フレームID、メッセージID、分割数」、「アプリケーション」に対するMAC値がセットされる。「署名者ID」、「フレームID、メッセージID、分割数」、「アプリケーション」、「MAC」は暗号化される。
【0116】
図28は、図27の「鍵情報」のデータ構造の一例を示す図である。「鍵情報」には、「鍵ID」、「暗号化通信鍵」が含まれる。「鍵ID」には、「テーブルID」、「サービスID」、「個別ID」が含まれる。「暗号化通信鍵」には、送信元で発生させた乱数をマスタ鍵で暗号化した通信鍵がセットされる。「テーブルID」には、通信システム500を構成する基地局装置20および端末装置10間で予め共有される共通鍵テーブルの識別情報がセットされる。各共通鍵テーブルは少なくともひとつのマスタ鍵を格納する。「サービスID」には、メッセージ送信のサービス種別を特定するための識別情報がセットされる。「個別ID」には、マスタ鍵そのものを特定するための識別情報がセットされる。「鍵情報」は、送信元の基地局装置20が使用した通信鍵を受信先の端末装置10あるいは別の基地局装置20に通知するための情報であり、図20(a)−(b)における「鍵ID」に相当する。
【0117】
図27図28に示すようなハイブリッド形式のセキュリティメッセージを採用する通信システム500において、サービス種別ごとにコンテナを構成するとオーバヘッドが大きくなる。これに対して、複数のサービスに対するデータを同一コンテナで送信すると送信順序によっては、サービスに対応するデータを受信できない事態が発生する。以下、この問題を解決する手法を説明する。
【0118】
前提として、サービス種別ごとにマスタ鍵を設定するとともに、端末装置10および基地局装置20は対応するサービスのマスタ鍵を保持する。複数のサービスに対するデータを同一コンテナで送信する場合、先頭のメッセージは必ず汎用サービスのデータを配置する。汎用サービスのマスタ鍵は、全ての端末装置10および基地局装置20で共有されている。また、汎用サービスのマスタ鍵を使用して生成される先頭のメッセージの「アプリケーション」は空としてもよい。これらにより、セキュリティによるオーバヘッドの増加を抑えつつ、汎用サービスと特定サービスを混在させることができる。
【0119】
図29は、汎用サービスと特定サービスが混在した通信システムの一例を示す図である。図29の通信システムには、サービス事業者Aの路側機20A1、路側機20A2、サービス事業者Bの路側機20B1、路側機20B2、汎用車載機10A、特定車載機10Bが含まれる。サービス事業者Aの路側機20A1、路側機20A2の鍵テーブルには、路車間マスタ鍵Aと路路間マスタ鍵Aが格納されている。路車間マスタ鍵Aは、路車間汎用サービスの路車間通信で使用されるマスタ鍵であり、全ての車載機10(汎用車載機10A、特定車載機10B)の鍵テーブルに事前に格納されている。路路間マスタ鍵Aは、サービス事業者Aの路側機間通信で使用されるマスタ鍵である。
【0120】
サービス事業者Bの路側機20B1の鍵テーブルには、路車間マスタ鍵Bと路路間マスタ鍵Bが格納されている。サービス事業者Bの路側機20B2の鍵テーブルには、路車間マスタ鍵B、路車間マスタ鍵bと路路間マスタ鍵Bが格納されている。路車間マスタ鍵Bは、路車間汎用サービスの路車間通信で使用されるマスタ鍵であり、全ての車載機10(汎用車載機10A、特定車載機10B)の鍵テーブルに事前に格納されている。路車間マスタ鍵bは、路車間特定サービスの路車間通信で使用されるマスタ鍵であり、特定車載機10Bの鍵テーブルにのみ格納されている。路路間マスタ鍵Bは、サービス事業者Bの路側機間通信で使用されるマスタ鍵である。
【0121】
汎用車載機10Aの鍵テーブルには、路車間マスタ鍵Aと路車間マスタ鍵Bが格納されている。特定車載機10Bの鍵テーブルには、路車間マスタ鍵A、路車間マスタ鍵B、路車間マスタ鍵bが格納されている。特定車載機10Bのユーザは、サービス事業者Bと特定サービスを契約しており、特定車載機10Bはサービス事業者Bの路側機20B2から報知された特定サービスのパケット信号を受信して解読できる。汎用車載機10Aは、このパケット信号を解読できない。
【0122】
図30(a)−(d)は、路側機20A1における送信処理の各レイヤにおける処理の概要を示す(その1)。なお、路側機20A1における送信処理のレイヤ構成は図22(a)と基本的に同じである。図30(a)は、分割処理層に入力されるアプリケーションデータを示す。アプリケーションデータAPP3、アプリケーションデータAPP1、アプリケーションデータAPP2の順に入力される。アプリケーションデータAPP3は特定サービスのアプリケーションデータであり、アプリケーションデータAPP1、アプリケーションデータAPP2は汎用サービスのアプリケーションデータである。
【0123】
分割処理層は、汎用サービスのアプリケーションが先頭にくるよう並び替える。図30(a)では、アプリケーションデータAPP1、アプリケーションデータAPP2、アプリケーションデータAPP3の順に並び替える。図30(b)は、並び替えられたアプリケーションデータを示す。
【0124】
セキュリティ層は、並び替えられたアプリケーションデータに対してセキュリティ処理を実行する。具体的には各アプリケーションデータの前にセキュリティヘッダSHを付加し、その後にセキュリティフッタSFを付加する。アプリケーションデータAPP1、アプリケーションデータAPP2は路車間マスタ鍵Aを用いて署名生成、MAC生成、暗号化がなされ、アプリケーションデータAPP3は路路間マスタ鍵Aを用いて署名生成、MAC生成、暗号化がなされる。
【0125】
図30(c)は、セキュリティ処理がなされたアプリケーションデータを示す。分割処理層は、セキュリティ処理がなされたアプリケーションデータを、サイズに応じて分割する。図30(d)は、分割されたアプリケーションデータを示す。図30(d)では、アプリケーションデータAPP1を5つに分割している。分割処理層は、分割したデータのそれぞれにELヘッダを付加する。無線送信層は、各データをパケット信号に格納し、パケット信号を報知する。
【0126】
図31(a)−(c)は、路側機20A2における受信処理の各レイヤにおける処理の概要を示す。なお、路側機20A2における受信処理のレイヤ構成は図22(b)と基本的に同じである。図31(a)は、無線受信層で受信されたデータを示す。分割処理層は、分割されているデータを併合する。図31(b)は、併合されたアプリケーションデータを示す。分割処理層は、併合する際に各データに付加されたELヘッダを除去する。
【0127】
セキュリティ層は、各アプリケーションデータのセキュリティヘッダSHとセキュリティフッタSFに格納された情報を用いて、暗号化部分の復号、署名検証、ハッシュ一致検証、MAC検証を実行する。路側機20A2は、路車間マスタ鍵Aも路路間マスタ鍵Aも保持しているため、アプリケーションデータAPP1、アプリケーションデータAPP2、アプリケーションAAP3を全て解読できる。図31(c)は、解読されたアプリケーションデータを示す。
【0128】
図32(a)−(c)は、汎用車載機10Aにおける受信処理の各レイヤにおける処理の概要を示す。なお、汎用車載機10Aにおける受信処理のレイヤ構成は図22(b)と基本的に同じである。図32(a)は、無線受信層で受信されたデータを示す。分割処理層は、分割されているデータを併合する。図32(b)は、併合されたアプリケーションデータを示す。分割処理層は、併合する際に各データに付加されたELヘッダを除去する。
【0129】
セキュリティ層は、各アプリケーションデータのセキュリティヘッダSHとセキュリティフッタSFに格納された情報を用いて、暗号化部分の復号、署名検証、ハッシュ一致検証、MAC検証を実行する。汎用車載機10Aは、路車間マスタ鍵Aは保持しているが、路路間マスタ鍵Aは保持していない。したがって、アプリケーションデータAPP1、アプリケーションデータAPP2は解読できるが、アプリケーションAAP3は解読できない。アプリケーションAAP3は路路間マスタ鍵Aを用いて生成された通信鍵で暗号化されているため、路路間マスタ鍵Aを保持しない汎用車載機10Aは、アプリケーションAAP3を復号できない。
【0130】
ここで、図30(a)−(d)の処理でアプリケーションデータの並び替えが行われなかった場合について考えると、汎用車載機10Aが受信する順番は、アプリケーションAAP3、アプリケーションAAP1、アプリケーションAAP2となる。前述したように汎用車載機10Aは、アプリケーションAAP3を解読できない。アプリケーションAAP3のセキュリティヘッダSH3には、アプリケーションAAP1、アプリケーションAAP2からそれぞれ導出されたハッシュ値を含むハッシュリストがセットされている。このハッシュリストを復号できないため、アプリケーションAAP1、アプリケーションAAP2の復号はできても、ハッシュ一致検証ができない。従って、アプリケーションAAP1、アプリケーションAAP2の真正性が確認できない。
【0131】
このように特定サービスのアプリケーションデータが先頭メッセージに配置されると、特定サービスに対応していない機器では、そのアプリケーションデータだけでなく、同一コンテナ内の後続する全てのアプリケーションデータも検証できなくなる。これに対して、汎用サービスのアプリケーションデータを先頭メッセージに配置すると、同一コンテナ内の後続する全てのアプリケーションデータが検証不能になる事態を回避できる。同様の効果は、先頭のアプリケーションデータを空にし、汎用サービスで使用するマスタ鍵を用いてセキュリティ処理することでも実現できる。
【0132】
図33(a)−(d)は、路側機20A1における送信処理の各レイヤにおける処理の概要を示す(その2)。図33(a)−(b)は、図30(a)−(b)と同じである。セキュリティ層は、並び替えられたアプリケーションデータに対してセキュリティ処理を実行する。その際、先頭メッセージのアプリケーションを空に設定し、汎用サービスで使用されるマスタ鍵(この例では路車間マスタ鍵A)を使用してセキュリティヘッダSH1、セキュリティフッタSF1を生成し、空のアプリケーションの前後に付加する。
【0133】
図33(c)は、セキュリティ処理がなされたアプリケーションデータを示す。分割処理層は、セキュリティ処理がなされたアプリケーションデータを、サイズに応じて分割する。図33(d)は、分割されたアプリケーションデータを示す。図33(d)では、アプリケーションデータAPP1を4つに分割し、アプリケーションデータAPP3を2つに分割している。分割処理層は、分割したデータのそれぞれにELヘッダを付加する。無線送信層は、各データをパケット信号に格納し、パケット信号を報知する。
【0134】
これまで、基地局装置20および端末装置10から報知されるパケット信号を受信した別の基地局装置20および端末装置10は、パケット信号から取り出した路車間メッセージのコンテナの先頭路車間メッセージに対する署名検証を、原則的に、すべて実行することを前提としていた。しかしながら、スーパーフレーム期間に受信するパケット信号に含まれるコンテナ(路車間メッセージの署名検証およびハッシュリストの管理単位)の数が増加すると、処理負荷が大きい署名検証では、処理遅延の増加によってスーパーフレーム期間内に処理が終了しないようなケースが発生する。例えば図2において、スーパーフレームを構成するサブフレームの数を8、各サブフレームを一台の基地局装置20が占有し、それぞれの基地局装置20が2つのコンテナに帰属する路車間メッセージを送信すると、受信先では、最大16回の署名検証を行わなければならなくなる。1スーパーフレーム期間に2回の署名検証を行う処理能力しかない場合、すべてのコンテナの先頭メッセージに対する署名検証は実行できないこととなる。すべてのコンテナの先頭メッセージに対する署名検証が実行できる処理能力を持たせることも考えられるが、1スーパーフレーム期間に16回の署名検証を実行するためには、非常に高速なCPU或いは大規模な専用回路を必要とする。これにより、コストの上昇、署名検証処理の上限を一意に決められないなどの問題が発生する。
【0135】
このような問題を回避するために、同一基地局装置20からのパケット信号がスーパーフレーム周期で送信される特性から、署名検証を間引くことが考えられる。過去の同一基地局装置20からの路車間メッセージ(署名者IDが同じである路車間メッセージ)の署名検証結果と、ハッシュリストとハッシュ値の一致の確認と、MAC検証結果とによって、署名検証を間引いたコンテナ内の路車間メッセージの検証結果とする認証方式が考えられる。同一基地局装置20からの過去の署名検証結果によって、発信元の基地局装置20の真正性を、ハッシュリストとハッシュ値の一致の確認によってコンテナの構成の正当性確認を、MAC検証によってメッセージの真正性と改ざんの確認を行うこととなる。
【0136】
図34は、図27のメッセージを路車間メッセージとして、図6のメッセージを車車間メッセージとして受信するときの、図11の検証部1151における処理を示すフローチャートである。
【0137】
図11の検証部1151の署名検証部1151bは、1スーパーフレーム期間に2回の署名検証を行う能力を有し、最大2つの「署名検証リクエスト」を受け付ける。また、署名検証結果を公開鍵証明書に含まれる署名者ID(例えば、シリアル番号)と、メッセージのフレームIDとともにダイジェスト保持部1151cに退避する。この時、ダイジェスト保持部1151cに同じ署名者IDに対する署名検証結果が既に退避されているときは、その退避されている署名検証を書き換える。これによって、署名者IDによって識別される基地局装置20から送信されたメッセージに対する最も新しい署名検証結果を得ることができるようになる。
【0138】
ハッシュ比較部1151aは、路車間メッセージに含まれるアプリケーションデータを少なくとも含むデータ列からハッシュ値を演算する。ハッシュ比較部1151aは、「ハッシュ一致検証リクエスト」に対して演算したハッシュ値と、ダイジェスト保持部1151cに保持されるハッシュリスト内のハッシュ値とを比較し、その結果を報告する。
【0139】
MAC検証部1151dは、「MAC検証リクエスト」に対して先頭の路車間メッセージ、後続の路車間メッセージ、および車車間メッセージに対する共通鍵暗号に係わる処理をする。メッセージに含まれる鍵IDあるいは鍵情報から通信鍵を特定、抽出し、この通信鍵を用いてMACを求め、メッセージに含まれるMACと比較するMAC検証を実行し、結果を通知する。
【0140】
判定部1151eは、メッセージの解釈、署名検証部1151b、ハッシュ比較部1151a、MAC検証部1151dへのリクエスト、および、メッセージからアプリケーションデータを抽出し、アプリケーションデータと署名検証部1151b、ハッシュ比較部1151a、MAC検証部1151dからの検証結果をまとめて外部に通知する。署名検証結果は、署名者IDに基づいて、ダイジェスト保持部1151cより取得する。また、判定部1151eは、先頭の路車間メッセージに含まれる公開鍵証明書の署名者IDとフレームID、ハッシュリストを紐付けして、ダイジェスト保持部1151cに退避する。なお、検証結果が失敗である場合、アプリケーションデータの通知をしないようにしてもよい。
【0141】
以下、図34のフローチャートを具体的に説明する。判定部1151eは、受信したメッセージがMAC付きデータであるか否か判定する(S21)。MAC付きデータである場合(S21のY)、MAC検証部1151dに「MAC検証リクエスト」を発行する(S22)。MAC検証部1151dは、上記の図13に示したフローチャートに示したMAC検証処理を実行する。
【0142】
判定部1151eは、MAC検証部1151dからMAC検証結果を受けると、MAC検証が成功であったか失敗であったかを判定する(S23)。成功の場合(S23のY)、判定部1151eは、受信したメッセージが、先頭の路車間メッセージか、後続の路車間メッセージであるか、車車間メッセージであるかを判定する(S24)。受信したメッセージが、先頭の路車間メッセージである場合(S24のN)、判定部1151eは、当該メッセージに含まれるハッシュリストに、署名者ID(例えば、公開鍵証明書のシリアル番号)及びフレームIDを紐付けして、ダイジェスト保持部1151cに退避する(S25)。判定部1151eは、当該メッセージが署名検証対象であるか否かを判定する(S26)。この判定方法の具体例は後述する。
【0143】
当該メッセージが署名検証対象である場合(S26のY)、判定部1151eは、署名検証部1151bに「署名検証リクエスト」を発行する(S27)。当該メッセージが署名検証対象でない場合(S26のN)、「署名検証リクエスト」は発行されない。
【0144】
図35は、図34の署名検証のサブルーチンを示すフローチャートである。このフローチャートに示す処理では、パラメータとしてState、Entryの2つを使用する。署名検証部1151bは複数バンクで構成される。バンク数はEntryの最大数に設定される。本実施例ではEntryの最大数が2で、署名検証部1151bは2バンクで構成される。すなわち、同時に2つの署名検証のリクエストを受け付け、Entryによって管理される。また、署名検証部1151bの署名検証のリクエストを受け付けるリクエストスレッドと、署名検証処理を実行する処理スレッドは並列に動作する。なお図35のステップS710、ステップS712の記号は、ステップS72などの記号と同様に判断を示すものとする。以後のフローチャートについても同様である。
【0145】
Stateの初期値としてreadyを設定し、Entryの初期化として0を設定する(S71)。判定部1151eから「署名検証リクエスト」が発行されると(S72のY)、署名検証部1151bのリクエストスレッドは、Entryをインクリメントする(S73)。Entryが最大値の2の場合(S74のY)、Stateにbusyを設定する(S75)。Entryが2以下の場合(S74のN)、ステップS72に遷移し、リクエスト待ち状態になる。Stateにbusyを設定した後、Entryを監視し(S76)、Entryが2以外になると(S76のN)、Stateにreadyを設定し(S77)、ステップS72に遷移し、リクエスト待ち状態になる。
【0146】
Entryがゼロより大きい場合(S78のY)、署名検証部1151bの処理スレッドは、受信したメッセージの公開鍵証明書のハッシュを演算し(S79)、公開鍵証明書の署名を検証する(S710)。公開鍵証明書の署名検証に成功すると(S710のY)、署名検証部1151bの処理スレッドは、受信したメッセージのハッシュリストのハッシュを演算し(S711)、ハッシュリストの署名を検証する(S712)。ハッシュリストの署名検証に成功すると(S712のY)、「署名検証リクエスト」に係るメッセージの署名検証成功をダイジェスト保持部1151cに退避する(S713)。
【0147】
公開鍵証明書の署名検証に失敗した場合(S710のN)、またはハッシュリストの署名検証に失敗した場合(S712のN)、「署名検証リクエスト」に係るメッセージの署名検証失敗をダイジェスト保持部1151cに退避する(S714)。署名検証結果の退避が終了すると、Entryをデクリメントし(S715)、ステップS78に遷移する。Entryがゼロの間(S78のN)、処理待ち状態となり、Entryが1又は2の場合(S78のY)、ステップS79以降の処理を実行する。
【0148】
図34に戻る。ステップS24にて受信したメッセージが後続の路車間メッセージである場合(S24のY)、又は先頭の路車間メッセージであり(S24のN)、署名検証に関する処理(S25〜S27)が終了した後、判定部1151eは、ハッシュ比較部1151aに「ハッシュ一致検証リクエスト」を発行する(S28)。ハッシュ比較部1151aは、上記の図15に示したフローチャートに示したハッシュ比較処理を実行する。
【0149】
判定部1151eは、受信したメッセージに含まれる署名者IDに基づき、ダイジェスト保持部1151cから当該署名者IDを持つメッセージの署名検証結果を取得する(S29)。署名検証結果を取得するとステップS31に遷移する。ステップS21にて、受信したメッセージがMAC付きデータでない場合(S21のN)、対象外通知を生成して(S30)、ステップS31に遷移する。またステップS23にて、MAC検証が失敗であった場合(S23のN)、ステップS24にて、受信したメッセージが車車間メッセージである場合(S21のB)もステップS31に遷移する。
【0150】
判定部1151eは、受信したメッセージからアプリケーションデータを抽出する(S31)。判定部1151eは、抽出したアプリケーションデータと、各種の検証結果を受信処理部161に通知する(S32)。
【0151】
図36は、図34の署名検証対象の判定方法の一例を示すフローチャートである。以下に説明する判定方法では、順位管理リストと候補リストを使用する。順位管理リストは、署名者ID、優先順位、受信マークの3つの項目を有する。優先順位(優先レベル)の段階は、(路車間サブフレームの最大数/スーパーフレーム期間の検証回数×2)以上に設定される。路車間サブフレームの最大数は、同時受信する基地局装置20の最大数に設定される。優先順位の初期値は中間値に設定される。
【0152】
順位管理リストのサイズは、路車間サブフレームの最大数に設定される。受信マークは、スーパーフレーム期間における初回受信でセット、スーパーフレーム期間の先頭でクリアされるパラメータである。
【0153】
候補リストは、順位管理リストでのエントリと、スーパーフレーム周期で優先順位が最も高いものによるエントリの2つを有する。候補リストのサイズは、スーパーフレーム期間に処理できる最大数に設定される。
【0154】
以下、図36のフローチャートを具体的に説明する。判定部1151eは、順位管理リストを初期値する(S61)。判定部1151eは、受信したメッセージがスーパーフレーム期間の先頭であるか否か判定する(S62)。先頭の場合(S62のY)、判定部1151eは、その時点で最も優先順位が高い署名者IDを署名検証候補として候補リストに登録する(S63)。判定部1151eは、一つ前のスーパーフレーム期間に受信が無かった署名者IDに対する優先順位を1つ下げ(S64)、当該署名者IDの受信マークをクリアする(S65)。ステップS62にて、受信したメッセージがスーパーフレーム期間の先頭でない場合(S62のN)、ステップS63〜S65をスキップする。
【0155】
次に判定部1151eは、受信したメッセージが、ステップS67以降の判定処理を実行すべき先頭の路車間メッセージであるか否か判定する(S66)。先頭の路車間メッセージではなく後続の路車間メッセージ又は車車間メッセージである場合(S66のN)、ステップS62に遷移し、ステップS62以降の処理を繰り返す。先頭の路車間メッセージである場合(S66のY)、判定部1151eは、当該メッセージに含まれる署名者IDが順位管理リストに登録されているか否か判定する(S67)。登録されていない場合(S67のN)、順位管理リストに空きエントリが存在するか否か判定する(S68)。
【0156】
空きエントリが存在する場合(S68のY)、判定部1151eは当該署名者IDを、空きエントリに、当該署名者IDの優先順位は中間値に設定して登録する(S69)。空きエントリが存在しない場合(S68のN)、判定部1151eは当該署名者IDを、その時点で最も優先順位が低いエントリに、当該署名者IDの優先順位は中間値に設定して上書き登録する(S610)。当該署名者IDが順位管理リストに新たに登録された後、当該署名者IDに対する受信マークをセットし(ステップS617)、ステップS615に遷移する。
【0157】
ステップS67にて、受信したメッセージに含まれる署名者IDが順位管理リストに登録されている場合(S67のY)、判定部1151eは、当該署名者IDに対する受信マークがセットされているか否か判定する(S611)。セットされていない場合(S611のN)、判定部1151eは、当該署名者IDに対する優先順位を1つ上げ(S612)、当該署名者IDに対する受信マークをセットする(S613)。次に判定部1151eは、当該署名者IDが候補リストに登録されているか否か判定する(S614)。登録されている場合(S614のY)、ステップS615に遷移する。登録されていない場合(S614のN)、当該署名者IDを含む受信したメッセージを署名検証対象外と判定する(S619)。その後、ステップS62に遷移し、ステップS62以降の処理を繰り返す。
【0158】
ステップS611にて、当該署名者IDに対する受信マークがセットされている場合(S611のY)、ステップS612〜S614をスキップし、当該署名者IDを含む受信したメッセージを署名検証対象外と判定する(S619)。その後、ステップS62に遷移し、ステップS62以降の処理を繰り返す。
【0159】
ステップS615では判定部1151eは、署名検証部1151bのStateがreadyであるか否か確認する。Stateがreadyではなくbusyの場合(S615のN)、当該署名者IDを含む受信したメッセージを署名検証対象外と判定する(S619)。その後、ステップS62に遷移し、ステップS62以降の処理を繰り返す。
【0160】
ステップS615にてStateがreadyの場合(S615のY)、当該署名者IDに対する優先順位を中間値に設定する(S616)。判定部1151eは、当該署名者IDを含む受信したメッセージを署名検証対象と判定する(S618)。その後、ステップS62に遷移し、ステップS62以降の処理を繰り返す。
【0161】
ステップS69およびステップS610では、優先順位を中間値に設定するとしたが、優先順位を最も高く設定するようにしてもよい。優先順位を最も高く設定することで、当該基地局装置20から初めて路車間メッセージを受信したスーパーフレームあるいはその後のより直近のスーパーフレームで署名検証が行われるようになる。
【0162】
図37は、図34の署名検証対象の判定方法の別の例を示すフローチャートである。この例では、候補リストを使用せずに順位管理リストのみを使用する。以下、図36のフローチャートとの相違点を説明する。図37のフローチャートでは、ステップS63及びステップS614が省略される。またステップS67のYとステップS611の間に、ステップS6105が挿入され、ステップS617が、テップS616とステップS618の間に移動する。
【0163】
ステップS6105では判定部1151eは、受信したメッセージに含まれる署名者IDが、順位管理リスト内で上位2位以内か否か判定する。上位2位以内であれば(S6105のY)、ステップS615に遷移し、上位2位以内でなければ(S6105のN)、ステップS611に遷移する。
【0164】
図37のフローチャートでは、1つの基地局装置20から複数のコンテナを受信する場合にスーパーフレーム期間で最初に受信したコンテナの先頭の路車間メッセージを受信したときに署名検証がbusyであった場合、その後受信したコンテナの先頭の路車間メッセージに対して署名検証の機会を与えられるようになる。また、図36のフローチャートと同様に、ステップS69およびステップS610では、優先順位を中間値に設定するとしたが、優先順位を最も高く設定するようにしてもよい。優先順位を最も高く設定することで、当該基地局装置20から初めて路車間メッセージを受信したスーパーフレームあるいはその後のより直近のスーパーフレームで署名検証が行われるようになる。
【0165】
さらに、図36および図37のフローチャートにおいて公開鍵証明書の検証を間引くようにしてもよい。すなわち、署名検証が実施され、かつ、署名検証に成功した公開鍵証明書を、あるいは公開鍵証明書の識別情報、公開鍵等を記録しておき、受信したメッセージに含まれる公開鍵証明書が、それと一致すると判断される場合、公開鍵証明書の署名検証を間引く。
【0166】
以上のように、署名検証を間引くことによって、署名検証処理の負荷を軽減し、コストダウンを図ることができる。また、スーパーフレーム期間に送信されるコンテナの数に上限を定める必要がない。図34図37のフローチャートに従えば、基地局装置20から始めて受信したパケット信号に含まれるコンテナ、すなわち、コンテナを送信した送信元の基地局装置20からのコンテナに対する署名検証結果を保持しない場合、そのコンテナの署名検証を優先的に実行する。また、パケット信号を受信したことのある基地局装置20からのパケット信号に含まれるコンテナ、すなわち、コンテナを送信した送信元の基地局装置20からのコンテナに対する署名検証結果を保持しない場合、基地局装置20ごとに均等に署名検証を実施することができる。
【0167】
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【0168】
なお、本実施の形態に係る発明は、以下に記載する項目によって特定されてもよい。
【0169】
[項目1]
発信元固有の公開鍵証明書、代表値リスト、アプリケーションデータ、前記公開鍵証明書に含まれる公開鍵で検証可能な署名、共通鍵暗号方式によるメッセージ認証コードが付加された第1パケット信号、及び発信元固有の公開鍵証明書のダイジェスト、アプリケーションデータ、共通鍵暗号方式によるメッセージ認証コードが付加された第2パケット信号を、他の無線装置から受信する受信部と、
前記第1パケット信号に含まれる公開鍵証明書の署名および前記第1パケット信号に含まれる前記代表値リストを少なくとも含むデータ列から生成された署名を検証するための第1検証部と、
前記第1パケット信号または前記第2パケット信号に含まれるメッセージ認証コードを検証するための第2検証部と、
前記第2パケット信号に含まれるアプリケーションデータを少なくとも含むデータ列から演算された代表値と、前記代表値リスト内に含まれている、前記第2パケット信号に含まれるアプリケーションデータを少なくとも含む予め演算されたデータ列の代表値とを比較する比較部と、
前記第1検証部による署名の検証結果、前記第2検証部によるメッセージ認証コードの検証結果、前記比較部による比較結果をもとに、前記アプリケーションデータにより構成されるメッセージを承認するか否か判定する判定部と、
を備えることを特徴とする無線装置。
【0170】
[項目2]
前記第1パケット信号に含まれる代表値リストを一時保持するための保持部をさらに備え、
前記第1検証部は、前記第1パケット信号に含まれる代表値リストを前記保持部に格納し、
前記第2検証部は、前記保持部に保持される代表値リスト内の代表値と、前記第2パケット信号に含まれるアプリケーションデータを少なくとも含むデータ列から演算された代表値とを比較することを特徴とする項目1に記載の無線装置。
【0171】
[項目3]
前記第1検証部は、前記第1パケット信号に含まれる公開鍵証明書のダイジェストを生成して前記保持部に格納し、
前記第1検証部は、前記保持部に保持される公開鍵証明書のダイジェストと、受信した第1パケット信号に含まれる公開鍵証明書から生成した公開鍵証明書のダイジェストとが一致する場合、当該第1パケット信号に含まれる公開鍵証明書の署名検証成功と判定することを特徴とする項目2に記載の無線装置。
【0172】
[項目4]
アプリケーションデータと発信元固有の公開鍵証明書と前記公開鍵証明書に含まれる公開鍵で検証可能な署名と共通鍵暗号方式によるメッセージ認証子を含む第1のメッセージと、アプリケーションデータと発信元を特定する情報と共通鍵暗号方式によるメッセージ認証子を含む1つ以上の第2のメッセージとを生成し、
前記第1のメッセージおよび1つ以上の前記第2のメッセージを1つのグループとして送信する無線装置であって、
1つ以上の全ての無線装置での受信が許可されるサービスに属するアプリケーションデータと、1つ以上の特定の無線装置のみが受信が許可されるサービスに属するアプリケーションデータを受け取り、
前記第1のメッセージは、自身のアプリケーションデータおよび1つ以上の前記第2のメッセージにそれぞれ含まれるアプリケーションデータに対するダイジェストあるいはメッセージ認証子を含む認証用リストを含み、前記署名は前記認証用リストに対する署名であり、
前記第1のメッセージに含まれる前記アプリケーションデータは、受け取った全ての無線装置での受信が許可されるサービスに属するアプリケーションデータの1つであり、
前記第2のメッセージの前記メッセージ認証子は、当該メッセージに含まれる前記公開鍵証明書の特定情報と前記アプリケーションデータに対するものであり、
前記第2のメッセージに含まれる前記アプリケーションデータは、受け取った全ての無線装置での受信が許可されるサービスに属するアプリケーションデータあるいは特定の無線装置のみが受信が許可されるアプリケーションデータの内の1つであることを特徴とする無線装置。
【0173】
[項目5]
当該メッセージに含まれる前記アプリケーションデータのサービスに固有の共通鍵の中から1つを選択し、選択した共通鍵を前記メッセージ認証子の生成に用いる通信鍵とし、前記通信鍵を用いて前記メッセージ認証子を生成することを特徴とする項目4に記載の無線装置。
【0174】
[項目6]
前記メッセージ認証子の生成に用いる通信鍵を乱数生成し、前記通信鍵を用いて前記メッセージ認証子を生成し、
当該メッセージに含まれる前記アプリケーションデータのサービスに固有の共通鍵の中から1つを選択し、選択した共通鍵を用いて暗号化した前記通信鍵を当該メッセージに含めることを特徴とする項目4に記載の無線装置。
【0175】
[項目7]
前記第1のメッセージに含まれる前記公開鍵証明書と前記認証用リストと前記署名と前記アプリケーションデータと前記メッセージ認証子とを前記メッセージ認証子の生成に用いた前記通信鍵を用いて暗号化して、送信することを特徴とする項目5または6に記載の無線装置。
【0176】
[項目8]
一部あるいは全ての前記第2のメッセージに含まれる前記公開鍵証明書の特定情報と前記アプリケーションデータとを前記メッセージ認証子の生成に用いた前記通信鍵を用いて暗号化して、送信することを特徴とする項目5から7のいずれかに記載の無線装置。
【0177】
[項目9]
前記第1のメッセージおよび前記第2のメッセージを、1つ以上のパケット信号に分割して、送信することを特徴とする項目4から8のいずれかに記載の無線装置。
【0178】
[項目10]
前記第1のメッセージは前記アプリケーションデータのバイト数が0であることを特徴とする項目4から8のいずれかに記載の無線装置。
【符号の説明】
【0179】
10 端末装置、 11 アンテナ、 12 RF部、 13 変復調部、 14 MACフレーム処理部、 15 セキュリティ処理部、 1151 検証部、 1152 復号部、 1153 記憶部、 17 データ生成部、 18 記憶部、 19 制御部、 20 基地局装置、 21 アンテナ、 22 RF部、 23 変復調部、 24 MACフレーム処理部、 25 セキュリティ処理部、 1251 署名部、 1252 暗号部、 1253 記憶部、 26 データ生成部、 27 ネットワーク通信部、 28 記憶部、 29 制御部、 100 車両、 161 受信処理部、 162 通知部、 200 外部ネットワーク、 202 エリア、 204 エリア外、 500 通信システム。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30
図31
図32
図33
図34
図35
図36
図37