(57)【要約】【課題】共通鍵暗号化方式を用いた通信システムのセキュリティを効率的に向上させる技術を提供する。【解決手段】記憶部１８は、車車間通信に使用可能な共通鍵を複数種類含む共通鍵テーブルが複数世代にわたって記憶される。セキュリティ処理部１５は、記憶部１８に記憶される複数世代の共通鍵テーブルのうち、ひとつの世代の共通鍵テーブルを送信用鍵テーブルとして使用することによって、ブロードキャスト送信すべきパケット信号に対する暗号化を実行するとともに、記憶部１８に記憶される複数世代の共通鍵テーブルを受信用鍵テーブルとして使用することによって、受信したパケット信号に対する復号を実行する。監視部３０は、セキュリティ処理部１５において使用される送信用鍵テーブルと受信用鍵テーブルとを監視する。【選択図】図７
2015050586.tif 000002
【特許請求の範囲】
【請求項１】
パケット信号をブロードキャスト送信する車車間通信を実行する車載器であって、
車車間通信を実行可能な期間において、他の車載器からブロードキャスト送信されたパケット信号を受信するとともに、車車間通信を実行可能な期間のうちのパケット信号の受信期間以外の期間において、パケット信号をブロードキャスト送信する通信部と、
車車間通信に使用可能な共通鍵を複数種類含む共通鍵テーブルが複数世代にわたって記憶される記憶部と、
前記記憶部に記憶される複数世代の共通鍵テーブルのうち、ひとつの世代の共通鍵テーブルを送信用鍵テーブルとして使用することによって、前記通信部からブロードキャスト送信すべきパケット信号に対する暗号化を実行するとともに、前記記憶部に記憶される複数世代の共通鍵テーブルを受信用鍵テーブルとして使用することによって、前記通信部において受信したパケット信号に対する復号を実行するセキュリティ処理部と、
前記セキュリティ処理部において使用される送信用鍵テーブルと受信用鍵テーブルとを監視する監視部とを備え、
前記セキュリティ処理部は、受信用鍵テーブルに含まれた複数世代の共通鍵テーブルのうち、中間の世代の共通鍵テーブルを送信用鍵テーブルとして使用し、
前記監視部は、共通鍵テーブルの監視結果に応じた警告を出力することを特徴とする車載器。
【請求項２】
前記セキュリティ処理部において送信用鍵テーブルとして使用される共通鍵テーブルの世代よりも前の共通テーブルの数と、送信用鍵テーブルとして使用される共通鍵テーブルの世代よりも先の共通テーブルの数とは予め規定されており、
前記監視部は、送信用鍵テーブルとして使用される共通鍵テーブルの世代よりも先の共通テーブルの数が、予め規定された数よりも少ない場合に、警告を出力することを特徴とする請求項１に記載の車載器。
【請求項３】
前記監視部は、前記セキュリティ処理部において送信用鍵テーブルとして使用予定の共通鍵テーブルが、前記記憶部に記憶されている共通鍵テーブルと異なる場合に、警告を出力することを特徴とする請求項１に記載の車載器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信技術に関し、特に所定の情報が含まれた信号を送受信する車載器に関する。
【背景技術】
【０００２】
無線通信は有線通信に比較して通信の傍受や第三者のなりすましによる不正な介入が容易であるため、無線通信ではそれらへの対策が有線通信より重要となる。通信内容の秘匿性を確保するには、通信データを暗号化する手法が有効である。暗号化方式には、大別すると公開鍵暗号化方式と共通鍵暗号化方式がある。前者は後者と比較し、セキュリティは高いがデータ量が多く、かつ、処理負荷が大きいため実装コストが高くなる。すなわち、両者はトレードオフの関係にある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平２００７−１０４３１０号公報
【特許文献２】特開平８−３３１０７５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
リアルタイム性を重視する必要がある路車間通信および車車間通信では、共通鍵暗号化方式を採用することが有力である。しかしながら、路車間通信および車車間通信を同じ共通鍵で運用すると、その鍵が漏洩した場合、路車間通信および車車間通信の両方のセキュリティが破れてしまう。
【０００５】
本発明はこうした状況に鑑みてなされたものであり、その目的は、共通鍵暗号化方式を用いた通信システムのセキュリティを効率的に向上させる技術を提供することにある。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明のある態様の車載器は、パケット信号をブロードキャスト送信する車車間通信を実行する車載器であって、車車間通信を実行可能な期間において、他の車載器からブロードキャスト送信されたパケット信号を受信するとともに、車車間通信を実行可能な期間のうちのパケット信号の受信期間以外の期間において、パケット信号をブロードキャスト送信する通信部と、車車間通信に使用可能な共通鍵を複数種類含む共通鍵テーブルが複数世代にわたって記憶される記憶部と、記憶部に記憶される複数世代の共通鍵テーブルのうち、ひとつの世代の共通鍵テーブルを送信用鍵テーブルとして使用することによって、通信部からブロードキャスト送信すべきパケット信号に対する暗号化を実行するとともに、記憶部に記憶される複数世代の共通鍵テーブルを受信用鍵テーブルとして使用することによって、通信部において受信したパケット信号に対する復号を実行するセキュリティ処理部と、セキュリティ処理部において使用される送信用鍵テーブルと受信用鍵テーブルとを監視する監視部とを備える。セキュリティ処理部は、受信用鍵テーブルに含まれた複数世代の共通鍵テーブルのうち、中間の世代の共通鍵テーブルを送信用鍵テーブルとして使用し、監視部は、共通鍵テーブルの監視結果に応じた警告を出力する。
【０００７】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００８】
本発明によれば、共通鍵暗号化方式を用いた通信システムのセキュリティを効率的に向上できる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施例に係る通信システムの構成を示す図である。
【図２】図２（ａ）−（ｄ）は、通信システムにおいて規定されるスーパーフレームのフォーマットを示す図である。
【図３】図３（ａ）−（ｂ）は、サブフレームの構成を示す図である。
【図４】図４（ａ）−（ｆ）は、通信システムにおいて規定される各レイヤのフレームのフォーマットを示す図である。
【図５】セキュリティフレームのデータ構造の一例を示す図である。
【図６】実施例に係る基地局装置の構成を示す図である。
【図７】実施例に係る、車両に搭載された端末装置の構成を示す図である。
【図８】実施例に係る通信システムを用いた路車間通信における通常のメッセージ送受信手順を説明するための図である。
【図９】路車間通信において生成されるパケットに含まれるセキュリティフレームのデータ構造の一例を示す図である。
【図１０】実施例に係る通信システムを用いた車車間通信における通常のメッセージ送受信手順を説明するための図である。
【図１１】車車間通信において生成されるパケットに含まれるセキュリティフレームのデータ構造の一例を示す図である。
【図１２】共通鍵テーブルのフォーマットを示す図である。
【図１３】図１３（ａ）−（ｂ）は、実施例に係る、端末装置に保持された共通鍵テーブルを示す図である（その１）。
【図１４】図１４（ａ）−（ｂ）は、実施例に係る、端末装置に保持された共通鍵テーブルを示す図である（その２）。
【図１５】図１５（ａ）−（ｂ）は、実施例に係る共通鍵テーブルの切替の様子を示す図である（その１）。
【図１６】図１６（ａ）−（ｂ）は、実施例に係る共通鍵テーブルの切替の様子を示す図である（その２）。
【図１７】図１７（ａ）−（ｃ）は、図７の監視部における警告がなされる状況を説明するための図である。
【図１８】図１８（ａ）−（ｃ）は、図７の監視部における警告がなされる別の状況を説明するための図である。
【図１９】実施例に係る共通鍵テーブルの追加または更新を説明するための図である。
【発明を実施するための形態】
【００１０】
本発明の実施例の基礎となった知見は、次の通りである。リアルタイム性を重視する必要がある路車間通信および車車間通信では、共通鍵暗号化方式を採用することが有力である。しかしながら、路車間通信および車車間通信を同じ共通鍵で運用すると、その鍵が漏洩した場合、路車間通信および車車間通信の両方のセキュリティが破れてしまう。実施例はこうした状況に鑑みてなされたものであり、その目的は、共通鍵暗号化方式を用いた通信システムのセキュリティを効率的に向上させる技術を提供することにある。
【００１１】
本発明の実施例を具体的に説明する前に、概要を述べる。本発明の実施例は、交差点や路側などに設置された基地局装置（路側機）から、主に、車両に搭載された端末装置に情報を提供するために路側機から情報を送信する路車間通信、および車両に搭載された端末装置から、主に、他の車両に情報を提供するために端末装置から情報を送信する車車間通信を用いたＩＴＳ（Ｉｎｔｅｌｌｉｇｅｎｔ  Ｔｒａｎｓｐｏｒｔ  Ｓｙｓｔｅｍｓ）などの通信システムに関する。
【００１２】
ＩＴＳでは、ＩＥＥＥ８０２．１１などの無線ＬＡＮ規格に類した無線通信を用いることが検討されている。そのような無線通信では、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ  ｗｉｔｈ  Ｃｏｌｌｉｓｉｏｎ  Ａｖｏｉｄａｎｃｅ）と呼ばれるアクセス制御機能が使用されている。そのため、当該無線通信では、基地局装置および複数の端末装置によって同一の無線チャネルが共有される。このようなＣＳＭＡ／ＣＡでは、キャリアセンスによって他のパケット信号が送信されていないことを確認した後に、パケット信号がブロードキャストにより送信される（以下、パケット信号のブロードキャストによる送信を「報知」という）。
【００１３】
車車間通信として、端末装置は、それが搭載されている車両のサイズや車種などの車両の静的な情報と、日時、速度、位置やウィンカー点灯などの車両に関する動的な情報を含む車両情報を格納したパケット信号を報知する。そのパケット信号を受信した端末装置は、そのパケット信号に格納された情報をもとに車両の接近などを認識する。また、路車間通信として、基地局装置は、静的な交差点情報と、動的なセンサ情報、信号機の点灯情報、渋滞情報などが格納されたパケット信号を報知する。
【００１４】
交差点情報には、交差点の位置情報、基地局装置が設置された交差点の路線情報、センサの設置位置など、交差点の状況に関する情報が含まれる。センサ情報には、撮影画像、交差点内に設置されたセンサからの車両や歩行者の位置情報などが含まれる。端末装置は、この交差点情報をモニタに表示する。また、この交差点情報をもとに交差点の状況を認識し、出会い頭・右折・左折による、車両、自転車、歩行者との衝突防止を目的とした視覚情報あるいは音声メッセージをユーザに通知してもよい。渋滞情報には、基地局装置が設置された走路の混雑状況、道路工事、事故に関する情報が含まれる。端末装置は、この渋滞情報をもとに進行方向の渋滞をユーザに伝達する。また、その渋滞を迂回するための迂回路を提示してもよい。
【００１５】
図１は、本発明の実施例に係る通信システム５００の構成を示す。これは、ひとつの交差点を上方から見た場合に相当する。通信システム５００は、基地局装置２０、第１車両１００ａに搭載された端末装置１０ａ、第２車両１００ｂに搭載された端末装置１０ｂを含む。なお、第１車両１００ａおよび第２車両１００ｂは車両１００と総称し、端末装置１０ａおよび端末装置１０ｂは端末装置１０と総称する。エリア２０２は基地局装置２０の電波圏内を示し、エリア外２０４は基地局装置２０の電波圏外を示す。図面の上側が「北」に対応し、第１車両１００ａは「南」から「北」に進んでおり、第２車両１００ｂは「東」から「西」に進んでいる。基地局装置２０は外部ネットワーク２００を介して外部の装置と通信が可能である。
【００１６】
図２（ａ）−（ｄ）は、通信システム５００において規定されるスーパーフレームのフォーマットを示す。図２（ａ）は、スーパーフレームの構成を示す。スーパーフレームは、第１サブフレームから第Ｎサブフレームと示されるＮ個のサブフレームによって形成されている。例えば、スーパーフレームの長さが１００ｍｓｅｃであり、Ｎが８である場合、１２．５ｍｓｅｃの長さのサブフレームが規定される。Ｎは、８以外であってもよい。
【００１７】
図２（ｂ）は、図示しない第１基地局装置２０ａによって生成されるスーパーフレームの構成を示す。第１基地局装置２０ａは、基地局装置２０のうちの任意のひとつに相当する。第１基地局装置２０ａは、第１サブフレームの先頭部分に路車送信期間を設定する。また、第１基地局装置２０ａは、第１サブフレームにおいて路車送信期間に続いて車車送信期間を設定する。車車送信期間とは、端末装置１０がパケット信号を報知する期間である。つまり、第１サブフレームの先頭期間である路車送信期間において第１基地局装置２０ａは必ずこの期間にパケット信号を報知する。逆に、第１基地局装置２０ａの電波到達距離内に配置される他の基地局装置２０、および、この電波到達距離内にいる端末装置１０は、この期間にパケット信号を報知することはない。第１サブフレームの路車送信期間に後続する車車送信期間において端末装置１０がパケット信号を報知可能であるように規定される。さらに、第１基地局装置２０ａは、第２サブフレームから第Ｎサブフレームに車車送信期間のみを設定する。
【００１８】
図２（ｃ）は、図示しない第２基地局装置２０ｂによって生成されるスーパーフレームの構成を示す。第２基地局装置２０ｂは、第１基地局装置２０ａとは異なった基地局装置２０に相当する。第２基地局装置２０ｂは、第２サブフレームの先頭部分に路車送信期間を設定する。また、第２基地局装置２０ｂは、第２サブフレームにおける路車送信期間の後段、第１サブフレーム、第３サブフレームから第Ｎサブフレームに車車送信期間を設定する。
【００１９】
図２（ｄ）は、図示しない第３基地局装置２０ｃによって生成されるスーパーフレームの構成を示す。第３基地局装置２０ｃは、第１基地局装置２０ａや第２基地局装置２０ｂとは異なった基地局装置２０に相当する。第３基地局装置２０ｃは、第３サブフレームの先頭部分に路車送信期間を設定する。また、第３基地局装置２０ｃは、第３サブフレームにおける路車送信期間の後段、第１サブフレーム、第２サブフレーム、第４サブフレームから第Ｎサブフレームに車車送信期間を設定する。このように、複数の基地局装置２０は、互いに異なったサブフレームを選択し、選択したサブフレームの先頭部分に路車送信期間を設定する。このように、基地局装置２０は、自身がパケット信号（情報）を報知するためにひとつのサブフレームの路車送信期間を独占することで、固有の報知期間をスーパーフレーム内に設けている。スーパーフレーム内に設定可能なサブフレームは有限（本実施例では８個）ではあるが、複数の基地局装置２０の電波到達距離を考慮して、スーパーフレームを選択すれば、基地局装置２０の設置台数を制限することはない。逆に、スーパーフレーム内のすべてのサブフレームに対して基地局装置２０が設置されるものとは限らない。
【００２０】
図３（ａ）−（ｂ）は、サブフレームの構成を示す。図３（ａ）に示すように、サブフレームは、路車送信期間、車車送信期間の順に構成される。路車送信期間では基地局装置２０がパケット信号を報知し、車車送信期間では端末装置１０がパケット信号を報知可能である。図３（ｂ）は、路車送信期間におけるパケット信号の配置を示す。図示のごとく、路車送信期間（以下、ＲＳＵ（Ｒｏａｄ  Ｓｉｄｅ  Ｕｎｉｔ）期間という）において、複数の路車間通信のパケット信号（以下、ＲＳＵパケットという）が並べられている。ここで、前後のＲＳＵパケットは、ＳＩＦＳ（Ｓｈｏｒｔ  Ｉｎｔｅｒｆｒａｍｅ  Ｓｐａｃｅ）だけ離れている。
【００２１】
図４（ａ）−（ｆ）は、通信システム５００において規定される各レイヤのフレームのフォーマットを示す。図４（ａ）は、物理レイヤのフレームフォーマットを示す。図示のごとく、フレームには、ＰＬＣＰプリアンブル、ＰＬＣＰヘッダ、ＰＳＤＵ（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）、テールが順に配置される。図４（ｂ）は、ＭＡＣレイヤのフレームフォーマットを示す。このフレームは、図４（ａ）のＰＳＤＵに格納される。図示のごとく、フレームには、ＭＡＣヘッダ、ＭＳＤＵ（ＭＡＣ  Ｌａｙｅｒ  Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）、ＦＣＳ（Ｆｒａｍｅ  Ｃｈｅｃｋ  Ｓｅｑｕｅｎｃｅ）が順に配置される。図４（ｃ）は、ＬＬＣレイヤのフレームフォーマットを示す。このフレームは、図４（ｂ）のＭＳＤＵに格納される。図示のごとく、フレームには、ＬＬＣヘッダ、ＬＳＤＵ（ＬＬＣ  Ｌａｙｅｒ  Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）が順に配置される。
【００２２】
図４（ｄ）は、車車間・路車間共用通信制御情報レイヤのフレームフォーマットを示す。このフレームは、図４（ｃ）のＬＳＤＵに格納される。図示のごとく、フレームには、ＩＲヘッダ、ＡＰＤＵ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）が順に配置される。図４（ｅ）は、セキュリティレイヤのフレームフォーマットを示す。このフレームは、図４（ｄ）のＡＰＤＵに格納される。図示のごとく、フレームには、セキュリティヘッダ（Ｓｅｃｕｒｉｔｙ  Ｈｅａｄｅｒ）、ペイロード（Ｐａｙｌｏａｄ）、セキュリティフッタ（Ｓｅｃｕｒｉｔｙ  Ｆｏｏｔｅｒ）が順に配置される。図４（ｆ）は、アプリケーションレイヤのフレームフォーマットを示す。このフレームは、図４（ｅ）のペイロードに格納されており、アプリケーションデータによって構成される。以下では、ＭＡＣレイヤのフレームをＭＡＣフレームといい、セキュリティレイヤのフレームをセキュリティフレームという。また、フレームフォーマットをデータ構造という。
【００２３】
図５は、セキュリティフレームのデータ構造の一例を示す。これは、図４（ｅ）の内容を詳細にした図である。セキュリティヘッダには、バージョン（ＶＥＲ）、メッセージタイプ（ＭＴ）、鍵情報、ＮＯＮＣＥおよびデータ長を含む。バージョン（ＶＥＲ）はフレームフォーマットのバージョンを示し、固定値（＝１）である。メッセージタイプ（ＭＴ）は、管理アプリフラグ、データ認証形式、鍵共有形式、メッセージ形式を含み、当該メッセージのフレーム構造を特定する。すなわち、メッセージのデコード（解釈）方法を決定づける。管理アプリフラグは、ペイロードに管理アプリケーションデータが含まれるか否かを示すフラグ情報である。「０」が管理アプリケーション無し、「１」が管理アプリケーションありを示す。
【００２４】
データ認証形式は、当該メッセージの形式が、どのデータ認証方式に対応した形式であるかを示す情報である。データ認証方式とは、データが改ざんされていないこと（完全性）やデータ送信元のたしからしさ（真正性）を確かめる方式である。本システムでは、共通鍵暗号によるメッセージ認証コード（ＭＡＣ：Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）方式と公開鍵暗号による電子署名方式の２つを採用している。「０」がＭＡＣ方式に対するデータ形式（以下、単にＭＡＣ方式ともいう）、「１」が電子署名方式に対するデータ形式（以下、単に電子署名方式ともいう）であることを示す。
【００２５】
鍵共有形式は、当該メッセージが、どの鍵共通方式に対応したデータ形式であるかを示す情報である。メッセージに対するＭＡＣ生成、検証および暗号化、復号に用いる通信鍵（共通鍵）を送信側と受信側で共有する必要があり、この通信を送信側と受信側で共有する方式が鍵共有方式である。本システムでは、システム内のすべての端末装置１０および基地局装置２０が事前に共有、すなわち、システム内のすべての端末装置１０および基地局装置２０が内部に保持している共通鍵テーブル内の鍵を使用する鍵テーブル共有方式と、送信側で送信毎にランダムに生成した値を通信鍵として使用する通信鍵報知方式を採用する。なお、通信鍵報知方式でも、送信側で生成した通信鍵を共通鍵テーブル内の鍵（以下、マスタ鍵という）を使用して暗号化し、当該メッセージに含めて送信する。なお、共通鍵テーブル、鍵テーブル共有方式、通信鍵報知方式については、後で説明する。「０」が鍵テーブル共有方式に対するデータ形式、「１」が通信鍵報知方式に対するデータ形式であることを示す。
【００２６】
メッセージ形式は、当該メッセージのペイロードに対する保護の形式を示す。「０」が認証無しデータ（平文）、「１」が認証付きデータ、「２」が認証付き暗号化データ、「３」が予約を示す。
【００２７】
鍵情報は、送信側が受信側に対して送信時に使用した通信鍵を通知するための情報であり、鍵ＩＤおよび暗号化通信鍵を含む。暗号化通信鍵はオプションである。鍵ＩＤは共通鍵テーブルから鍵をひとつ取得するための識別番号であり、鍵ＩＤは共通鍵テーブルを特定するテーブルＩＤと、共通鍵テーブル内の個々の鍵を特定する個別ＩＤとを含む。送信時、端末装置１０および基地局装置２０は、送信用の共通鍵テーブルから鍵をランダムに選択し、送信用の共通鍵テーブルのテーブルＩＤおよび選択した鍵の個別ＩＤからなる鍵ＩＤをセットする。受信時、端末装置１０および基地局装置２０は鍵ＩＤに含まれるテーブルＩＤによって共通鍵テーブルの有効性および有無を確認し、有効な共通鍵テーブルを保持する場合、個別ＩＤにしたがって共通鍵テーブルから鍵を選択する。メッセージタイプ（ＭＴ）の鍵共有形式が「０」、鍵テーブル共有方式のとき、鍵ＩＤには送信時に使用された通信鍵を指定する識別番号がセットされ、鍵共有形式が「１」、通信鍵報知方式のとき、鍵ＩＤには送信時に使用されたマスタ鍵を指定する識別番号がセットされる。
【００２８】
暗号化通信鍵は鍵ＩＤで特定されるマスタ鍵で暗号化された通信鍵を示す。暗号化通信鍵は共通鍵暗号方式の鍵であり、ＡＥＳ（Ａｄｖａｎｃｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  Ｓｔａｎｄａｒｄ）を採用したとき１６バイトである。メッセージタイプ（ＭＴ）の鍵共有形式が通信鍵報知方式のときのみ有効なオプションであり、鍵テーブル共有方式のときは省略される。ＮＯＮＣＥは送信毎にユニークな値を持ち、ペイロードに同じアプリケーションデータがセットされたときでもメッセージ認証コード（ＭＡＣ）や暗号化データが、送信毎に異なった値となるようにしている。ＮＯＮＣＥは機器ＩＤおよび乱数を含む。機器ＩＤには、発信元の端末装置１０あるいは基地局装置２０を一意に特定する識別情報で、発信元の端末装置１０または基地局装置２０が、自己の機器ＩＤをセットする。乱数は送信毎にユニークになるように送信元の端末装置１０あるいは基地局装置２０が生成する。なお、乱数に換えて、送信毎に違う値を示す発信日時やカウンタ値を用いてもよい、同様な効果が得られる。データ長はペイロードのバイト長を示す。
【００２９】
ペイロードは通信鍵による秘匿およびメッセージ認証対象となる。ペイロードは管理アプリおよびサービスアプリを含む。管理アプリは、更新用共通鍵テーブルなどの管理アプリケーションデータを示し、メッセージタイプ（ＭＴ）の管理アプリフラグによって指定されるオプションである。サービスアプリは通常のアプリケーションデータを示す。管理アプリおよびサービスアプリのデータ長は可変である。
【００３０】
セキュリティフッタはデータ認証がセットされる。データ認証はメッセージ認証コード（ＭＡＣ）または電子署名を示す。メッセージタイプ（ＭＴ）のデータ認証形式がＭＡＣ方式のときにはメッセージ認証コードがセットされ、電子署名方式のときには電子署名がセットされる。
【００３１】
図６は、基地局装置２０の構成を示す。基地局装置２０は、アンテナ２１、ＲＦ部２２、変復調部２３、ＭＡＣフレーム処理部２４、セキュリティ処理部２５、データ生成部２６、ネットワーク通信部２７、記憶部２８および制御部２９を備える。セキュリティ処理部２５は暗復号部２５６、暗号部２５７および鍵更新部２５８を含む。
【００３２】
ＭＡＣフレーム処理部２４、セキュリティ処理部２５、データ生成部２６、ネットワーク通信部２７、記憶部２８および制御部２９の構成は、ハードウエア的には、任意のプロセッサ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００３３】
ＲＦ部２２は、受信処理として、端末装置１０および他の基地局装置２０からのパケット信号をアンテナ２１にて受信する。ＲＦ部２２は、受信した無線周波数のパケット信号に対して周波数変換を実行し、ベースバンドのパケット信号を生成する。ＲＦ部２２は、ベースバンドのパケット信号を変復調部２３に出力する。一般的に、ベースバンドのパケット信号は、同相成分と直交成分によって形成されるため、２つの信号線が示されるべきであるが、図を簡略化するため、図６ではひとつの信号線だけを示している。ＲＦ部２２は、受信系の構成要素として、図示しないＬＮＡ（Ｌｏｗ  Ｎｏｉｓｅ  Ａｍｐｌｉｆｉｅｒ）、ミキサ、ＡＧＣ、Ａ／Ｄ変換部などを含む。
【００３４】
ＲＦ部２２は、送信処理として、生成したパケット信号を基地局装置２０から送信する。ＲＦ部２２は、変復調部２３から入力されるベースバンドのパケット信号に対して周波数変換を実行し、無線周波数のパケット信号を生成する。ＲＦ部２２は、ＲＳＵ期間において、無線周波数のパケット信号をアンテナ２１から送信する。ＲＦ部２２は、送信系の構成要素として、図示しないＰＡ（Ｐｏｗｅｒ  Ａｍｐｌｉｆｉｅｒ）、ミキサ、Ｄ／Ａ変換部などを含む。
【００３５】
変復調部２３は、受信処理として、ＲＦ部２２からのベースバンドのパケット信号に対して、復調を実行する。変復調部２３は、復調した結果から、ＭＡＣフレームをＭＡＣフレーム処理部２４に出力する。また、変復調部２３は、送信処理として、ＭＡＣフレーム処理部２４からのＭＡＣフレームに対して、変調を実行する。変復調部２３は、変調した結果をベースバンドのパケット信号としてＲＦ部２２に出力する。
【００３６】
本実施例に係る通信システム５００では、ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）変調方式を採用する。この場合、変復調部２３は受信処理としてＦＦＴ（Ｆａｓｔ  Ｆｏｕｒｉｅｒ  Ｔｒａｎｓｆｏｒｍ）を実行し、送信処理としてＩＦＦＴ（Ｉｎｖｅｒｓｅ  Ｆａｓｔ  Ｆｏｕｒｉｅｒ  Ｔｒａｎｓｆｏｒｍ）を実行する。
【００３７】
ＭＡＣフレーム処理部２４は、受信処理として、変復調部２３からのＭＡＣフレームから、セキュリティフレームを取り出し、セキュリティ処理部２５に出力する。また、ＭＡＣフレーム処理部２４は、送信処理として、セキュリティ処理部２５からのセキュリティフレームに対して、ＭＡＣヘッダ、ＬＬＣヘッダおよびＩＲ情報ヘッダを付加し、ＭＡＣフレームを生成し、変復調部２３に出力する。また、他の基地局装置２０または端末装置１０からのパケット信号が衝突しないようパケット信号の送受信タイミングを制御する。
【００３８】
ネットワーク通信部２７は、外部ネットワーク２００に接続される。ネットワーク通信部２７は、外部ネットワーク２００から工事や渋滞などに関する道路情報を受けつける。また、本実施例では後述するシステム運用管理装置から提供される、暗号化用更新鍵テーブルおよびテーブル更新鍵を受けつける。また、ネットワーク通信部２７は、セキュリティ処理部２５による処理結果を外部ネットワーク２００へ出力したり、記憶部２８に蓄積して、定期的に外部ネットワーク２００へ出力したりする。
【００３９】
記憶部２８は、種々の情報（例えば、共通鍵テーブル、自己の機器ＩＤ、送信用鍵テーブルのテーブルＩＤ）を記憶する。本実施例では、外部ネットワーク２００から取得される道路情報、システム運用管理装置から提供される、更新鍵テーブルおよびテーブル更新鍵、ならびに端末装置１０から提供される機器ＩＤおよび共通鍵テーブルＩＤ（以下適宜、テーブルＩＤという）を一時的に記憶する。制御部２９は、基地局装置２０全体の処理を制御する。データ生成部２６は、センサやカメラなどからの情報や、記憶部２８に記憶されている情報を利用してアプリケーションデータを生成する。そして、アプリケーションデータの内容によって、メッセージ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部２５に出力する。
【００４０】
セキュリティ処理部２５は、セキュリティフレームを生成または解釈する。セキュリティ処理部２５は、送信処理として、データ生成部２６からアプリケーションデータを受け取ると、ＭＡＣフレーム処理部２４に出力すべきセキュリティフレームを、受け取ったアプリケーションデータと記憶部２８に記憶されているデータをもとに生成する。例えば、図５に示すペイロードのサービスアプリに、データ生成部２６から受け取ったアプリケーションデータをセットし、そのデータ長をセキュリティヘッダのデータ長にセットする。また、セキュリティヘッダの鍵情報の暗号化通信鍵に、マスタ鍵で暗号化された通信鍵（乱数）をセットする。また、当該通信鍵（乱数）を用いて生成されるメッセージ認証コード（ＭＡＣ）をセキュリティフッタにセットする。そして、その他のセキュリティヘッダを付加してセキュリティフレームを生成する。その後、指定されたメッセージ形式が認証付き暗号化データの場合、ペイロードおよびメッセージ認証コード（ＭＡＣ）を当該通信鍵（乱数）を用いて暗号化することで、メッセージを秘匿することも可能である。なお、本実施例では基地局装置２０は、データ認証形式がＭＡＣ認証方式、鍵共有形式が通信鍵報知方式のセキュリティフレームを生成する。ここで、セキュリティ処理部２５は、記憶部２８に記憶される複数世代の共通鍵テーブルのうち、ひとつの世代の共通鍵テーブルを送信用の共通鍵テーブル（以下、送信用鍵テーブルという）とし、送信用鍵テーブルからマスタ鍵をランダムに選択する。
【００４１】
セキュリティ処理部２５は、受信処理として、ＭＡＣフレーム処理部２４からのセキュリティフレームを受けつける。セキュリティ処理部２５は、セキュリティフレームのうちのセキュリティヘッダの内容を確認する。メッセージタイプが認証付きデータである場合、暗復号部２５６にてメッセージの検証処理を実行する。メッセージタイプが認証付き暗号化データである場合、暗復号部２５６にてメッセージの復号処理を実行し、検証処理を実行する。なお、メッセージタイプが平文である場合、これらの処理は省略される。
【００４２】
セキュリティ処理部２５は、暗復号部２５６、暗号部２５７および鍵更新部２５８を含む。本実施例では、基地局装置２０からのパケット送信に注目するため、送信処理として実行されるセキュリティフレームを生成する処理に注目する。受信処理として行われるセキュリティフレームを解釈する処理については、後述する端末装置１０の受信処理と同じである。暗復号部２５６は、通信鍵を用いてペイロードを対象としたメッセージ認証コード（ＭＡＣ）を生成する。メッセージ認証コード（ＭＡＣ）は、ＡＥＳ（Ａｄｖａｎｃｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  Ｓｔａｎｄａｒｄ）−ＣＢＣ（Ｃｉｐｈｅｒ  Ｂｌｏｃｋ  Ｃｈａｉｎｉｎｇ）モードを利用したＭＡＣアルゴリズムを適用して生成される。なお、ＭＡＣの生成には、ＮＯＮＣＥやデータ長も利用される。次いで、メッセージ形式が認証付き暗号化データの場合、通信鍵を用いてペイロードとセキュリティフッダの暗号化が行われる。暗号化は、ＡＥＳ＿ＣＴＲ（ＣｏｕｎＴｅＲ）モードを適用する。本実施例では、暗復号部２５６は、メッセージ形式が認証付き暗号化データの場合には、通信鍵（乱数）を用いたＡＥＳ−ＣＣＭ（Ｃｏｕｎｔｅｒ  ｗｉｔｈ  ＣＢＣ−ＭＡＣ）モードを適用したため、ペイロードに対するメッセージ認証コード（ＭＡＣ）の付加およびペイロードとメッセージ認証コード（ＭＡＣ）の暗号化を行う。なお、ＡＥＳ―ＣＣＭモードを適用せずに、ペイロードより暗号化を行った後、メッセージ認証コード（ＭＡＣ）の付加を行ってもよいし、メッセージ認証コード（ＭＡＣ）の付加および暗号化のいずれか一方のみを行ってもよい。なお、ペイロードを対象としたメッセージ認証コードの生成、および、ペイロードとセキュリティフッダの暗号化には、通信鍵の他に、ＮＯＮＣＥやデータ長が利用される。ＣＢＣ−ＭＡＣおよびＣＣＭモードのアルゴリズムによるものであり、ＮＯＮＣＥの使用により、ペイロードと通信鍵が同じであっても、異なったメッセージ認証コード値、暗号化の結果が得られる。
【００４３】
暗号部２５７は、基地局装置２０より端末装置１０に対して送信する鍵を暗号化する。具体的には、暗復号部２５６で使用した通信鍵（乱数）を送信用鍵テーブルから選択したマスタ鍵で暗号化する。また、暗号部２５７は、共通鍵テーブルを更新する際、更新用鍵テーブルでテーブル更新鍵を暗号化した管理アプリケーションデータを生成する。
【００４４】
鍵更新部２５８は、端末装置１０が保持すべき共通鍵テーブルの更新処理を行う。これらの更新処理の詳細は後述する。
【００４５】
図７は、車両１００に搭載された端末装置１０の構成を示す。端末装置１０は、アンテナ１１、ＲＦ部１２、変復調部１３、ＭＡＣフレーム処理部１４、セキュリティ処理部１５、データ生成部１６、受信処理部１７１、通知部１７２、監視部３０、記憶部１８および制御部１９を備える。セキュリティ処理部１５は、暗復号部１５６、復号部１５７および鍵更新部１５８を含む。
【００４６】
ＭＡＣフレーム処理部１４、セキュリティ処理部１５、データ生成部１６、受信処理部１７１、通知部１７２、監視部３０、記憶部１８および制御部１９の構成は、ハードウエア的には、任意のプロセッサ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
【００４７】
アンテナ１１、ＲＦ部１２、変復調部１３およびＭＡＣフレーム処理部１４は、図６のアンテナ２１、ＲＦ部２２、変復調部２３およびＭＡＣフレーム処理部２４の構成および動作は基本的に共通する。つまり、アンテナ１１、ＲＦ部１２、変復調部１３は、車車間通信を実行可能な期間において、他の端末装置１０からブロードキャスト送信されたパケット信号を受信するとともに、車車間通信を実行可能な期間のうちのパケット信号の受信期間以外の期間において、パケット信号をブロードキャスト送信する。以下、これらの構成要素については、相違点を中心に説明する。
【００４８】
受信処理部１７１は、セキュリティ処理部１５から受け取ったデータと、データ生成部１６から受け取った自車の車両情報にもとづき、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また、データが画像情報であれば通知部１７２に表示するよう処理する。
【００４９】
通知部１７２は、図示しないモニタ、ランプ、スピーカなどのユーザへの通知手段を含む。受信処理部１７１からの指示にしたがって、図示しない他の車両の接近などを当該通知手段を介して運転者に通知する。また、渋滞情報、交差点などの画像情報などをモニタに表示する。
【００５０】
データ生成部１６は、図示しないＧＰＳ受信機、ジャイロスコープ、車速センサなどから供給される情報にもとづき、端末装置１０が搭載された車両１００の現在位置、進行方向、移動速度などを特定する。なお、現在位置は、緯度・経度によって示される。これらの情報の特定方法は一般的な公知の技術により実現可能であるため、ここでは説明を省略する。データ生成部１６は、特定した情報をもとに他の端末装置１０や基地局装置２０に報知すべきデータを生成し、生成したデータ（以下、アプリケーションデータという）をセキュリティ処理部１５に出力する。そして、アプリケーションデータの内容によって、メッセージ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部１５に出力する。また、特定した情報を受信処理部１７１に自車の車両情報として出力する。
【００５１】
記憶部１８は、種々の情報（例えば、共通鍵テーブル、テーブル更新鍵、自己の機器ＩＤ、送信用鍵テーブルのテーブルＩＤ）を記憶する。ここで、記憶部１８では、車車間通信に使用可能な共通鍵を複数種類含む共通鍵テーブルが複数世代にわたって記憶される。また、本実施例では基地局装置２０から取得される道路情報、自己または他の端末装置１０から取得される車両情報、ならびに基地局装置２０から取得される暗号化更新用共通鍵テーブルを一時的に保持する。制御部１９は、端末装置１０全体の処理を制御する。
【００５２】
セキュリティ処理部１５は、送信処理として、セキュリティフレームを生成または解釈する。セキュリティ処理部１５は、ＭＡＣフレーム処理部１４に出力すべきセキュリティフレームを、記憶部１８に記憶されたデータをもとに生成する。例えば、図５に示すペイロードのサービスアプリにアプリケーションデータをセットする。また、セキュリティヘッダの鍵情報の鍵ＩＤに、メッセージ認証コード（ＭＡＣ）生成に使用する通信鍵の鍵ＩＤをセットし、ＮＯＮＣＥに自己の機器ＩＤと乱数をセットする。また、鍵ＩＤによって共通鍵テーブルより選択された通信鍵を用いて生成されるメッセージ認証コード（ＭＡＣ）をセキュリティフッタのデータ認証としてセットする。そして、その他のセキュリティヘッダを付加してセキュリティフレームを生成する。メッセージ形式が、認証付き暗号化データの場合、ペイロードおよびメッセージ認証コード（ＭＡＣ）を当該通信鍵を用いて暗号化することで、メッセージを秘匿する。なお、メッセージタイプが平文である場合、これらの処理は省略される。なお、本実施例では端末装置１０のセキュリティ処理部１５は、データ認証形式がＭＡＣ認証方式、鍵共有形式が鍵テーブル共有方式のセキュリティフレームを生成する。ここで、セキュリティ処理部１５は、記憶部１８に記憶される複数世代の共通鍵テーブルのうち、ひとつの世代の共通鍵テーブルを送信用鍵テーブルとして使用し、送信鍵用鍵テーブルから通信鍵をランダムに選択する。
【００５３】
セキュリティ処理部１５は、受信処理として、ＭＡＣフレーム処理部１４からのセキュリティフレームを受けつける。セキュリティ処理部１５は、セキュリティフレームのうちのセキュリティヘッダの内容を確認する。メッセージタイプが認証付きデータである場合、暗復号部１５６にてメッセージの検証処理を実行する。メッセージ形式が認証付き暗号化データである場合、暗復号部１５６にてメッセージの復号処理および検証処理を実行する。なお、メッセージ形式が平文である場合、これらの処理は省略される。ここで、セキュリティ処理部１５は、記憶部１８に記憶される複数世代の共通鍵テーブルを受信用鍵テーブルとして使用することによって、通信において受信したパケット信号に対する復号を実行する。本実施例では、端末装置１０のセキュリティ処理部１５は、受信用の共通鍵テーブル（以下、受信用鍵テーブルという）として、送信用鍵テーブル（現世代）と１世代前の送信用鍵テーブル（前世代）と１世代先の送信用鍵テーブル（次世代）の３つの共通鍵テーブルを受信用鍵テーブルとする。前世代および次世代の共通鍵テーブルを受信用鍵テーブルに加えるのは、すべての端末装置１０における送信用鍵テーブルの切替における過渡期間を保証するためのものである。なお、本実施例では、現世代以前および現世代以降の各１世代を受信用鍵テーブルとして用いているが、これを制限するものではない。現世代以前および現世代以降に対してそれぞれ何世代を受信用共通鍵テーブルとして用いるかはシステムの仕様に基づいて決められる。
【００５４】
セキュリティ処理部１５は、暗復号部１５６、復号部１５７および鍵更新部１５８を含む。暗復号部１５６は、ペイロードに対するＭＡＣの生成と検証および、ペイロードとメッセージ認証コード（ＭＡＣ）に対する暗号化および復号を行うことができる。すなわち、セキュリティヘッダのメッセージタイプのメッセージ形式にしたがった処理を行い、基地局装置２０の暗復号部２５１と同等の機能を備える。したがって、送信処理は、基地局装置２０の暗復号部２５１と同じであるため説明を割愛する。暗復号部１５６は、受信処理として、ＭＡＣフレーム処理部１４からセキュリティフレームを受け取る。メッセージ形式が認証付き暗号化データの場合、暗復号部１５６は、通信鍵を用いてペイロードとセキュリティフッタを復号する。そして、ペイロードに付加されたメッセージ認証コード（ＭＡＣ）を検証する。メッセージ形式が暗号化データの場合、暗復号部１５６は、通信鍵を用いてペイロードを復号する。なお、復号および検証は送信側の暗号アルゴリズムに対応する復号アルゴリズムにより実行される。また、メッセージ形式が平文である場合、暗復号部１５６は復号および検証を実行しない。
【００５５】
復号部１５７は、基地局装置２０から報知されるパケット信号に含まれる暗号化通信鍵を鍵ＩＤで指定されたマスタ鍵を共通鍵テーブルから取得して、マスタ鍵で復号して通信鍵（乱数）を取り出す。また、記憶部１８に保持される共通鍵テーブルが更新される際、復号部１５７は基地局装置２０から管理アプリケーションデータとして報知される暗号化された更新用共通鍵テーブルをテーブル更新鍵で復号して更新用の共通鍵テーブルを取り出す。
【００５６】
鍵更新部１５８は、自己（端末装置１０）が保持すべき共通鍵テーブルの更新処理を行う。鍵更新部１５８のこれらの更新処理の詳細は後述する。監視部３０は、セキュリティ処理部１５において使用される送信用鍵テーブルと受信用鍵テーブルとを監視する。監視部３０の監視処理の詳細は後述する。
【００５７】
図８は、通信システム５００を用いた路車間通信における通常のメッセージ送受信手順を説明するための図である。基地局装置２０の暗号部２５７は、通信鍵とすべき乱数を発生させる。暗復号部２５６は、平文のアプリケーションデータに対して当該通信鍵（乱数）を用いて、ＭＡＣを付加して、ＭＡＣ付きのアプリケーションデータを暗号化し、暗号化アプリケーションデータとする。それとともに、暗号部２５７は当該通信鍵（乱数）を共通鍵テーブル内からランダムにマスタ鍵を選択し、選択したマスタ鍵を用いて暗号化し、暗号化通信鍵とする。これらの暗号化にはいずれも共通鍵暗号化方式が用いられる。セキュリティ処理部２５は、暗号化アプリケーションデータ、暗号化通信鍵、及びマスタ鍵を特定する鍵ＩＤを格納したパケット信号を生成する。当該パケット信号は、ＭＡＣフレーム処理部２４および変復調部２３を経て、ＲＦ部２２からアンテナ２１を介して外部に報知される。
【００５８】
端末装置１０のＲＦ部１２は、当該パケット信号を、アンテナ１１を介して受信する。当該パケット信号は、変復調部１３およびＭＡＣフレーム処理部１４を経て、セキュリティ処理部１５に渡される。復号部１５７は、当該パケット信号に格納された暗号化通信鍵を、基地局装置２０と共通しているマスタ鍵（鍵ＩＤで特定されるマスタ鍵）で復号する。暗復号部１５６は、当該パケット信号に格納された暗号化アプリケーションデータを、復号された通信鍵（乱数）で復号し、ＭＡＣ検証する。復号化およびＭＡＣ検証が成功したら、暗号化アプリケーションデータは平文のアプリケーションデータに復元される。
【００５９】
このメッセージ送受信方法には以下に示す様々なメリットがある。まず、動的に通信鍵を変えることができるので、後述する車車間通信におけるメッセージ送受信方法のように事前に複数の通信鍵を保持しておく必要がない。また、通信鍵として乱数を暗号化するため、通信路中からマスタ鍵が漏洩するリスクが小さい。マスタ鍵が漏洩しない限り、基本的に、システム運用管理機関や路車間サービス提供者は何もしなくてよい。また、マスタ鍵が漏洩しても、マスタ鍵の更新の仕組みが知られない限り、通信鍵が漏洩するリスクは小さい。さらに、路車間通信によりマスタ鍵を更新することにより、漏洩リスクを低減できる。更新されるデータ量が少ないため、マスタ鍵の更新は、路車間通信で十分に対応可能である。
【００６０】
図９（ａ）−（ｂ）は、路車間通信において生成されるパケットに含まれるセキュリティフレームのデータ構造の一例を示す。図９（ａ）のセキュリティフレームが通常メッセージ送受信時のデータ構造を示し、図９（ｂ）のセキュリティフレームが路車間通信による鍵テーブル更新時のデータ構造を示す。通常メッセージ送信時のセキュリティフレームのデータ構造では、セキュリティヘッダとして「バージョン（ＶＥＲ）」、「メッセージタイプ（ＭＴ）」、「鍵ＩＤ」、「通信鍵」、「ＮＯＮＣＥ」および「データ長」が配置され、その後にペイロードとして「サービスアプリ（アプリケーションデータ）」が配置され、最後にセキュリティフッタとして「ＭＡＣ」が配置される。この例では、鍵共有形式として報知共有方式を採用し、データ認証形式としてメッセージ認証コード（ＭＡＣ）方式を採用しているため、セキュリティヘッダには「通信鍵」が配置され、セキュリティフッタには「ＭＡＣ」が配置されている。「ＮＯＮＣＥ」、「データ長」、および「サービスアプリ」がＭＡＣ対象である。「通信鍵」に格納される通信鍵（乱数）は「鍵ＩＤ」で指定されてマスタ鍵により暗号化され、秘匿される。当該通信鍵（乱数）により「ＭＡＣ」が生成され、当該通信鍵（乱数）により「サービスアプリ」および「ＭＡＣ」が暗号化されて、秘匿される。なお、先のも述べたようにＭＡＣ生成および暗号化には、通信鍵と「ＮＯＮＣＥ」が使用される。
【００６１】
鍵テーブル更新時のセキュリティフレームのデータ構造では、通常メッセージ送信時のセキュリティフレームのデータ構造と比較し、「サービスアプリ」に換えて「管理アプリ（暗号化更新用鍵テーブル）」が配置される。「管理アプリ」には、テーブル更新鍵で暗号化された更新用共通鍵テーブルが管理アプリケーションデータとしてセットされる。また、「メッセージタイプ」の管理アプリフラグには、管理アプリの存在を示す「１」がセットされる。
【００６２】
図１０は、通信システム５００を用いた車車間通信における通常のメッセージ送受信手順を説明するための図である。端末装置１０の暗復号部１５６は、共通鍵テーブルに格納された複数の通信鍵の中からひとつの通信鍵をランダムに選択する。暗復号部１５６は、平文のアプリケーションデータに対して当該通信鍵を用いてＭＡＣを生成し、ＭＡＣ付きのアプリケーションデータを暗号化し、暗号化アプリケーションデータとする。セキュリティ処理部１５は、暗号化アプリケーションデータと、選択された通信鍵の鍵ＩＤを格納したパケット信号を生成する。当該パケット信号は、ＭＡＣフレーム処理部１４および変復調部１３を経て、ＲＦ部１２からアンテナ１１を介して外部に報知される。
【００６３】
別の端末装置１０のＲＦ部１２は、当該パケット信号を、アンテナ１１を介して受信する。当該パケット信号は、変復調部１３およびＭＡＣフレーム処理部１４を経て、セキュリティ処理部１５に渡される。暗復号部１５６は、当該パケット信号に格納された鍵ＩＤにより特定される通信鍵を共通鍵テーブルから読み出し、当該パケット信号に格納された暗号化アプリケーションデータを、当該通信鍵で復号し、ＭＡＣ検証する。ＭＡＣ検証が成功したら、暗号化アプリケーションデータは平文のアプリケーションデータに復元される。
【００６４】
このメッセージ送受信方法には以下に示す様々なメリットがある。まず、静的に通信鍵を使用するため、上述した路車間通信におけるメッセージ送受信方法より、データ通信量を抑えられる。また、複数の通信鍵を保持しておくことにより、通信路中から通信鍵が漏洩するリスクを小さくできる。また、共通鍵テーブルが漏洩した場合、新バージョンの通信鍵テーブルを追加することにより、セキュリティ低下を抑えられる。
【００６５】
図１１は、車車間通信において生成されるパケットに含まれるセキュリティフレームのデータ構造の一例を示す。当該セキュリティフレームのデータ構造では、セキュリティヘッダとして「バージョン（ＶＥＲ）」、「メッセージタイプ（ＭＴ）」、「鍵ＩＤ」、「ＮＯＮＣＥ」および「データ長」が配置され、その後にペイロードとして「サービスアプリ（アプリケーションデータ）」が配置され、最後にセキュリティフッタとして「ＭＡＣ」が配置される。この例では、「ＮＯＮＣＥ」、「データ長」、および「サービスアプリ」がＭＡＣ対象である。「鍵ＩＤ」により特定される共通鍵テーブル内の通信鍵により「ＭＡＣ」が生成され、当該通信鍵により「サービスアプリ」および「ＭＡＣ」が暗号化されて、秘匿される。この例では、鍵共有形式として鍵テーブル方式を採用し、データ認証形式としてメッセージ認証コード（ＭＡＣ）方式を採用しているため、セキュリティヘッダには「通信鍵」が配置されず、セキュリティフッタには「ＭＡＣ」が配置されている。なお、車車間通信でも、ＭＡＣ生成および暗号化には、通信鍵と「ＮＯＮＣＥ」が使用される。
【００６６】
図１２は、共通鍵テーブルのフォーマットを示す。共通鍵テーブルの「Ｆｉｅｌｄ」には、「Ｖｅｒｓｉｏｎ」、「Ｔａｂｌｅ  ＩＤ」、「Ｎｕｍｂｅｒ  ｏｆ  ｋｅｙ」および「Ｋｅｙ  Ｌｉｓｔ」が設けられる。が「Ｋｅｙ  Ｌｉｓｔ」には「Ｋｅｙ  ０」〜「Ｋｅｙ  ２５５」が設けられる。なお、ひとつの共通鍵テーブルに含まれる鍵の数は２５６に限るものではない。
【００６７】
「Ｔａｂｌｅ  ＩＤ」には当該共通鍵テーブルのテーブルＩＤがセットされる。「Ｎｕｍｂｅｒ  ｏｆ  ｋｅｙ」にはテーブル内の鍵の数がセットされる。「Ｋｅｙ  ０」には鍵番号０のＡＥＳ鍵がセットされる。「Ｋｅｙ  １」には鍵番号１のＡＥＳ鍵がセットされる。以下、「Ｋｅｙ  ２５５」まで同様である。なお、ＡＥＳ以外の共通鍵暗号を用いてもよい。また、共通鍵テーブルに含まれる鍵の数が、一定の場合「Ｎｕｍｂｅｒ  ｏｆ  ｋｅｙ」は省略してもよい。さらには、共通鍵テーブル内の鍵を用途毎に分けて管理してもよい。例えば、鍵共有形式毎に管理する、すなわち、鍵テーブル方式における通信鍵と報知共有方式におけるマスタ鍵に分けて管理する。この場合、通信鍵とマスタ鍵の鍵番号が重複してもよいし、分離してもよい。なお、ここでは鍵テーブル方式における通信鍵と報知共有方式におけるマスタ鍵は分けて管理する、すなわち、車車間通信で使用する通信鍵と、路車間通信で使用するマスタ鍵とは、同じ鍵テーブルから選択されるが、両者は異なるものとする。
【００６８】
これまでは、ひとつの共通鍵テーブルに対する処理を説明している。しかしながら、複数の共通鍵テーブルは一度に端末装置１０に提供され、端末装置１０は提供された複数の共通鍵テーブルを保持する。そして、端末装置１０は保持している使用可能な共通鍵テーブルが無くなるまで、その複数の共通鍵テーブルを順次切り替えて使用する。端末装置１０は保持している使用可能な共通鍵テーブルが無くなると、ひとつ以上の新たな共通鍵テーブルの提供を受けて、それを保持する。また、管理システム（図示されない。）からの要求により、ひとつ以上の新たな共通鍵テーブルの提供を受けて、それを保持する。以下では、複数の共通鍵テーブルの使用、更新に関する処理を説明する。
【００６９】
図１３（ａ）−（ｂ）は、端末装置１０に保持された共通鍵テーブルを示す（その１）。図１４（ａ）−（ｂ）は、端末装置１０に保持された共通鍵テーブルを示す（その２）。実施例では、路車間通信で使用するマスタ鍵も、車車間通信で使用されている通信鍵と同様に共通鍵テーブルから選択されるものとする。以下、端末装置１０は八つの共通鍵テーブルを格納可能な記憶領域（以下、格納領域という）を有し、各共通鍵テーブルの運用期間、すなわち、送信用鍵テーブルとして使用される期間が２年とし、端末装置１０を出荷から８〜１０年間は追加更新を行わないとした場合の共通鍵テーブルの保持例を説明する。当該実施例では、ひとつの共通鍵テーブルに保持される通信鍵の数は２５６である。なお、端末装置１０に保持される共通鍵テーブルの数およびひとつの共通鍵テーブルに保持される通信鍵の数は複数であればよく、前述の数に限定されない。共通鍵テーブルの格納領域の数は、端末装置１０に保持される共通鍵テーブルの数以上であればよい。すなわち、テーブルＩＤにより識別する数と共通鍵テーブルの格納領域の数は一致している必要はなく、多くても少なくてもよい。また、上述のごとく車車間の通信鍵のみでなく、マスタ鍵にも適用可能できる。
【００７０】
共通鍵テーブルの管理はバージョンおよびテーブルＩＤにより行われる。バージョンの異なる同じテーブルＩＤで特定される共通鍵テーブルが同時に使用されることはない。必ず、バージョンが大きい方が使用される。テーブルＩＤはＮ（Ｎは自然数）の剰余系として設定される。本実施例ではＮ＝８である。例えば、１番目の共通鍵テーブルと９番目の共通鍵テーブルのテーブルＩＤは「０」となる。バージョンは同じテーブルＩＤの新しい共通鍵テーブルが生成される度にカウントアップしていく。したがって、前者では「０」、後者では「１」となる。
【００７１】
格納領域に保持される複数の共通鍵テーブルのうち、ひとつが送信用鍵テーブルに指定され、複数が受信用鍵テーブルに指定される。複数の受信用鍵テーブルは送信用鍵テーブルを含み、送信用鍵テーブルよりｎ（ｎは自然数、ｎ＜Ｎ）世代未来までの共通鍵テーブルを含む。なお、複数の受信用鍵テーブルはｍ（ｍは０または自然数、ｍ＋ｎ−１＜＜Ｎ）世代過去までの共通鍵テーブルを含んでもよい。i世代未来の共通鍵テーブルのテーブルＩＤは、｛（送信用鍵テーブルのテーブルＩＤ＋i）  ｍｏｄ  Ｎ｝で、ｊ世代前の共通鍵テーブルのテーブルＩＤは、｛（送信用鍵テーブルのテーブルＩＤ−ｊ）  ｍｏｄ  Ｎ｝で算出される。なお、i世代未来の共通鍵テーブルのバージョンは、少なくとも、テーブルＩＤが送信用鍵テーブルのテーブルＩＤより大きい場合、送信用鍵テーブルのバージョン以上、テーブルＩＤが送信用鍵テーブルのテーブルＩＤより小さい場合、送信用鍵テーブルのバージョンを越える値である必要がある。また、ｊ世代過去の共通鍵テーブルのバージョンは、少なくとも、テーブルＩＤが送信用鍵テーブルのテーブルＩＤより大きい場合、送信用鍵テーブルのバージョン未満、テーブルＩＤが送信用鍵テーブルのテーブルＩＤより小さい場合、送信用鍵テーブルのバージョン以下である必要がある。なお、格納領域に保持される同じテーブルＩＤの共通鍵テーブルが複数保持されている場合には、バージョンの値が小さいもの（古いもの）は、無効（保持していない）として扱う。このように図７のセキュリティ処理部１５は、受信用鍵テーブルに含まれた複数世代の共通鍵テーブルのうち、中間の世代の共通鍵テーブルを送信用鍵テーブルとして使用する。また、送信用鍵テーブルとして使用される共通鍵テーブルの世代よりも前の共通テーブルの数と、送信用鍵テーブルとして使用される共通鍵テーブルの世代よりも先の共通テーブルの数とは予め規定されている。
【００７２】
システム運用管理装置が送信用鍵テーブルの切替を指示しても、すべての端末装置１０において送信用鍵テーブルが同時に切り替わるわけではない。端末装置１０間において送信用鍵テーブルが切り替わるタイミングに時間差が生じる。例えば、長期間使用されていない車両１００に搭載された端末装置１０では、２つ以上過去の共通鍵テーブルが送信用鍵テーブルに設定されている可能性もある。この車両１００が使用されると別の車両１００に搭載された端末装置１０は、２世代過去の共通鍵テーブルで処理されたパケット信号を受信する。暗号化システムの運用上、受信用鍵テーブルの範囲が狭いほどセキュリティが高くなるが、正当な端末装置１０からの送信データを復号できないケースが多くなる。両者の要請を考慮して受信用鍵テーブルの範囲は設定される。
【００７３】
送信用鍵テーブルの切替周期が長い場合（例えば、数年）、受信用鍵テーブルは、送信用鍵テーブルと次の共通鍵テーブル（ｎ＝１）で構成されるとよい。また、送信用鍵テーブルの切替周期が短い場合（例えば、１年以内）、受信用鍵テーブルは、送信用鍵テーブルと、次の共通鍵テーブル（ｎ＝１）と、さらにそれ以降の共通鍵テーブル（ｎ＞１）とで構成されるとよい。切替期間が短いほどｎを大きくし、多くの共通鍵テーブルを受信用鍵テーブルに組み入れるとよい。切替期間が短い場合、複数の端末装置１０間で送信用鍵テーブルのばらつきが大きくなる。これに対し、受信用鍵テーブルに組み入れる共通鍵テーブルの数を増やすことにより、送信用鍵テーブルのミスマッチを減らすことができる。以上より、ｍは１または０が、ｎは１または２が適当である。
【００７４】
図１３（ａ）は、車車間通信における共通鍵テーブルを用いた暗号化サービスの運用開始〜１年目に出荷される端末装置１０が保持する共通鍵テーブルを示す。図１３（ｂ）は、運用開始２〜３年目に出荷される端末装置１０が保持する共通鍵テーブルを示す。なお、ｍ＝１、ｎ＝１として説明する。また、説明を簡単にするため車車間通信の通信鍵についてのみ記載するが、路車間通信のマスタ鍵も同様である。
【００７５】
運用開始〜１年目は、共通鍵テーブル（バージョン＝０、テーブルＩＤ＝０）が送信用鍵テーブルとして使用される。各端末装置１０は、共通鍵テーブル（バージョン＝０、テーブルＩＤ＝０）からひとつの通信鍵を選択して車車間通信に使用する。このとき、現世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝０）と次世代送信用として次世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝１）が受信用鍵テーブルとして使用される。運用開始２〜３年目は、共通鍵テーブル（バージョン＝０、テーブルＩＤ＝１）が送信用鍵テーブルとして使用され、前世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝０）、現世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝１）と次世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝２）が受信用鍵テーブルとして使用される。同様に、図示しない運用開始４〜５年目は、共通鍵テーブル（バージョン＝０、テーブルＩＤ＝２）が送信用鍵テーブルとして使用され、前世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝１）、現世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝２）と次世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝３）が受信用鍵テーブルとして使用される。
図１４（ａ）は、運用開始１２〜１３年目に出荷される端末装置１０が保持する共通鍵テーブルを示す。図１４（ｂ）は、運用開始１４〜１５年目に出荷される端末装置１０が保持する共通鍵テーブルを示す。
運用開始１２〜１３年目は、共通鍵テーブル（バージョン＝０、テーブルＩＤ＝６）が送信用鍵テーブルとして使用され、前世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝５）、現世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝６）と次世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝７）が受信用鍵テーブルとして使用される。運用開始１４〜１５年目は、共通鍵テーブル（バージョン＝０、テーブルＩＤ＝７）が送信用鍵テーブルとして使用され、前世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝６）、現世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝７）と次世代送信用として次世代送信用鍵テーブル（バージョン＝１、テーブルＩＤ＝０）が受信用鍵テーブルとして使用される。
このように本実施例では２年ごとに送信用鍵テーブルを順次切り替える運用を行うこととし、以前に出荷した端末装置１０との通信を保証する共通鍵テーブルおよび切替に必要な共通鍵テーブルを事前に格納領域に格納して出荷する。この共通鍵テーブルの切替はシステム運用管理装置３００により統一的に管理される。
【００７６】
各端末装置１０は出荷時に運用開始〜１年目は五つの、それ以降は六つの共通鍵テーブルを保持するため、基本的に出荷から８〜１０年間、各端末装置１０は共通鍵テーブルを追加更新せずに暗号化システムを使用できる。ただし、出荷から８〜１０年目以降もこの暗号化システムを使用するためには、８〜１０年経過前に新たな共通鍵テーブルを追加更新する必要がある。すなわち、使用可能な共通鍵テーブルが無くなる前に、新たな共通鍵テーブルを追加更新する必要がある。
【００７７】
図１５（ａ）−（ｂ）は、共通鍵テーブルの切替の様子を示す（その１）。図１３（ａ）にしたがって、出荷される端末装置１０における共通鍵テーブルの切替の様子である。図１５（ａ）は、出荷直後の状態を示し、共通鍵テーブル（バージョン＝０、テーブルＩＤ＝０）が送信用鍵テーブルに指定されている。この状態で送信用鍵テーブルの切替が指示されると、鍵更新部１５８は、図１５（ｂ）に示すように送信用鍵テーブルを共通鍵テーブル（バージョン＝０、テーブルＩＤ＝１）に切り替える。送信用鍵テーブルの切替に伴って、受信用鍵テーブルは前世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝０）、現世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝１）と次世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝２）に切り替えられる。この結果、運用開始２〜３年目に出荷された端末装置１０と同じ、送信用鍵テーブルと受信用鍵テーブルを使用することになる。
図１６（ａ）−（ｂ）は、共通鍵テーブルの切替の様子を示す（その２）。図１４（ａ）に示す運用開始１２〜１３年後に出荷される端末装置１０に対して、１回の共通鍵テーブルの切替が行われた後の切替の様子である。この１回の切替によって、図１６（ａ）では共通鍵テーブル（バージョン＝０、テーブルＩＤ＝７）が送信用鍵テーブルに指定されている。この状態で送信用鍵テーブルの切替が指示されると、鍵更新部１５８は、図１６（ｂ）に示すように送信用鍵テーブルを共通鍵テーブル（バージョン＝１、テーブルＩＤ＝０）に切り替える。これに伴って、受信用鍵テーブルは前世代送信用鍵テーブル（バージョン＝０、テーブルＩＤ＝７）、現世代送信用鍵テーブル（バージョン＝１、テーブルＩＤ＝０）と次世代送信用鍵テーブル（バージョン＝１、テーブルＩＤ＝１）に切り替えられる。
【００７８】
このように、送信用鍵テーブルの切替が指示されると、鍵更新部１５８は、テーブルＩＤがＮ（ここでは８）の剰余系において次の値に切り替える。ただし、切替後の共通鍵テーブルのバージョンが同じ、または＋１である必要がある。図１５（ａ）−（ｂ）に示す例では切替前後でバージョンが同じである。図１６（ａ）−（ｂ）に示す例では切替前後でバージョンが＋１されている。複数のバージョンの共通鍵テーブルが格納領域に併存する場合、実装上、送信用鍵テーブルのバージョンより古いバージョンの共通鍵テーブルは存在しないものとして扱えばよい。なお、図１５（ａ）−（ｂ）の切替後、さらに３回の切替が行われると、送信用鍵テーブルが共通鍵テーブル（バージョン＝０、テーブルＩＤ＝４）に切り替わることになる。このとき、格納領域には次世代未来の共通鍵テーブルが保持されていなくなるので、新たに数世代未来の共通鍵テーブルを追記することで、図１３（ａ）にしたがって、出荷される端末装置１０の共通鍵テーブルの更新を行うことができる。なお余裕をみて、送信用鍵テーブルが共通鍵テーブル（バージョン＝０、テーブルＩＤ＝３）または（バージョン＝０、テーブルＩＤ＝４）のいずれかのときに更新するものとしてもよい。端末装置１０によって更新のタイミングが異なり、更新に時間的余裕があることから、路車間通信を使用しない、メンテナンスによる共通鍵テーブルの更新が行えるので、路車間通信のトラフィックをさかない運用ができるといった利点がある。
【００７９】
ここでは、図７の監視部３０における処理を説明する。図１７（ａ）−（ｃ）は、監視部３０における警告がなされる状況を説明するための図である。図１７（ａ）は、記憶部１８に記憶されている複数世代の共通鍵テーブルを示す。図示のごとく、テーブルＩＤ＝１から５の共通鍵テーブル（テーブル１〜テーブル５）が記憶部１８に記憶される。図１７（ｂ）は、記憶部１８に記憶されている送信用鍵テーブルのテーブルＩＤにしたがって、記憶部１８からセキュリティ処理部１５のワーク用メモリ（ＲＡＭ、図示されず）に読み出された送信用鍵テーブルを示す。ここでは、記憶部１８には送信用鍵テーブル（テーブル５）のテーブルＩＤとして、「５」が記憶される。図１７（ｃ）は、セキュリティ処理部１５のワーク用メモリに読み出された受信用鍵テーブルを示す。ここでは、受信用鍵テーブルは、前世代送信用鍵テーブル（テーブル４）、現世代送信用鍵テーブル（テーブル５）と次世代送信用鍵テーブル（テーブル６）が選択可能である。これに対し、図１７（ｃ）では、テーブルＩＤ＝４と５の２つの共通鍵テーブル（テーブル４、テーブル５）が受信用鍵テーブルとして設定される。破線で示される次世代送信用鍵テーブル（テーブル６）は、記憶部１８に記憶されていないため読み出されない。このとき受信用鍵テーブルには、次世代送信用鍵テーブルが含まれないので、監視部３０は警告を出力する。
なお、ｎ＞１とした場合でも同様に、受信用鍵テーブルに次世代送信用鍵テーブルが含まれないと判断したとき、監視部３０は警告を出力するようにしてもよいし、受信用鍵テーブルに２世代先の送信用鍵テーブルが含まれないと判断したとき監視部３０は警告を出力するようにしてもよい。いすれのタイミングで警告を通知するかは、ひとつの共通鍵テーブルを送信用鍵テーブルとして使用する期間によって決められるべきである。
【００８０】
図１８（ａ）−（ｃ）は、監視部３０における警告がなされる別の状況を説明するための図である。図１８（ａ）は、図１７（ａ）と同様に、記憶部１８に記憶されている複数世代の共通鍵テーブルを示しており、テーブルＩＤ＝１から５の共通鍵テーブルが示されている。図１８（ｂ）は、送信用鍵テーブルを示す。ここでは、セキュリティ処理部１５において送信用鍵テーブルのテーブルＩＤの書換エラーが生じ、送信用鍵テーブルのテーブルＩＤとして、「６」が記憶される。そのため、セキュリティ処理部１５では、テーブルＩＤ＝６が誤って設定されている。そのため破線で示される現世代送信用鍵テーブル（テーブル６）は、記憶部１８に記憶されていないため読み出されない。図１８（ｃ）は、図１７（ｃ）と同様に、受信用鍵テーブルを示す。破線で示される現世代送信用鍵テーブル（テーブル６）および次世代送信用鍵テーブル（テーブル７）は、記憶部１８に記憶されていないため読み出されない。監視部３０は、セキュリティ処理部１５において送信用鍵テーブルとして使用すべき共通鍵テーブルが、記憶部１８に記憶されている共通鍵テーブルと異なる場合に、警告を出力する。ここでは、テーブルＩＤ＝６の共通鍵テーブルが、記憶部１８に記憶されていないので、警告が出力される。つまり、監視部３０は、監視結果に応じた警告を出力する。
以上のように、何らかの理由で送信用鍵テーブルとして使用すべき共通鍵テーブルが、記憶部１８に記憶されている共通鍵テーブルと異なる場合、あるいは、受信用鍵テーブルのうち、次世代または２世代先の送信用鍵テーブルが記憶部１８に記憶されている共通鍵テーブルと異なる場合に、監視部３０は、監視結果に応じた警告を出力する。
なお、図１３（ａ）の出荷時の受信用鍵テーブルの説明で記したように、受信用鍵テーブルに、前世代送信鍵テーブルを含めることができない場合には、監視部３０は、警告を出力しない。ｍ＞１とした場合でも同様に、受信用鍵テーブルに、２世代以前の送信用鍵テーブルを含めることができない場合にも、監視部３０は、警告を出力しない。
【００８１】
図１９は、共通鍵テーブルの追加または更新を説明するための図である。システム運用管理機関のシステム運用管理装置３００は、複数の共通鍵テーブルを生成し、車両メーカの共通鍵テーブル設定装置４６０に提供する。共通鍵テーブル設定装置４６０は、提供された複数の共通鍵テーブルを、車両１００に新規に搭載された端末装置１０に書き込む。この書き込む複数の共通鍵テーブルの種類は出荷時期により異なる。
【００８２】
システム運用管理装置３００は、送信用鍵テーブルの切替タイミングが到来すると、路車間サービス提供者端末装置４００にテーブル切替指示を発行する。路車間サービス提供者端末装置４００は、システム運用管理装置３００から受け付けたテーブル切替指示を基地局装置２０に伝達する。基地局装置２０は、路車間サービス提供者端末装置４００から受け付けたテーブル切替指示を路車間通信でブロードキャスト送信する。車両１００に既に搭載された端末装置１０は、そのテーブル切替指示を受け付けると、送信用鍵テーブルを切り替える。また、端末装置１０は、受け付けたテーブル切替指示を車車間通信でブロードキャスト送信する。別の端末装置１０は、テーブル切替指示を受け付けると、送信用鍵テーブルを切り替える。システム運用管理装置３００からのテーブル切替指示は、共通鍵テーブル設定装置４６０および新規の端末装置１０を介して既存の端末装置１０に伝達されてもよい。
【００８３】
なお、送信用鍵テーブルの切替タイミングは端末装置１０が判断して切り替えていくようにしてもよい。ここでは、路車間通信で使用するマスタ鍵も、車車間通信で使用されている通信鍵と同様に共通鍵テーブルから選択されるものとする。また、図５における鍵ＩＤは、路車間通信でも使用する。なお、予め車車間通信で使用されている通信鍵とマスタ鍵の範囲を分けておいてもよい。この場合、双方の共通鍵テーブルに帰属する鍵の数が同じである必要はなく、鍵寿命の観点から、通信鍵よりマスタ鍵は少なくてもよい。
【００８４】
システム運用管理装置３００は、送信用鍵テーブルの切替タイミングが到来すると、路車間サービス提供者端末装置４００にテーブル切替指示を発行する。路車間サービス提供者端末装置４００は、システム運用管理装置３００からテーブル切替指示を受け取ると、基地局装置２０に送信用鍵テーブルのテーブル切替指示を発行する。基地局装置２０は、テーブル切替指示を受け取ると、自身の使用する送信用鍵テーブルを切り替える。そして、切り替えた共通鍵テーブルよりマスタ鍵を選択して、メッセージ形式が認証付き暗号化データまたは認証付きデータのセキュリティフレームを含むパケット信号を報知する。
【００８５】
車両１００に既に搭載された端末装置１０は、そのパケット信号を受信すると受信処理を行う。セキュリティ処理部１５は、受信したパケット信号に含まれるセキュリティフレームのＭＡＣを検証する。検証に成功すると、受信したセキュリティフレームの鍵ＩＤからテーブルＩＤを取り出して、自身の送信用鍵テーブルのテーブルＩＤと比較する。自身の送信用鍵テーブルより未来の世代の共通鍵テーブルを用いている場合、送信用鍵テーブルをそれに切り替える。また、他の端末装置１０から車車間通信で受信したパケット信号にもとづいて切り替えるようにしてもよい。
【００８６】
車両１００に既に搭載された端末装置１０は、前述のパケット信号を受信すると受信処理を行う。セキュリティ処理部１５は、受信したパケット信号に含まれるセキュリティフレームのＭＡＣを検証する。検証に成功すると、受信したセキュリティフレームの鍵ＩＤからテーブルＩＤを取り出して、自身の送信用鍵テーブルより未来の世代の共通鍵テーブルを用いている場合、そのテーブルＩＤと送信元の機器ＩＤを保持する。そして、例えば、１０台の他の端末装置１０から、未来の世代の同じ共通鍵テーブルを用いていると判断された場合、送信用鍵デーブルをそれに切り替える。両者の切り替え判断は併用できる。新規の端末装置１０の送信用鍵テーブルは、事前に切り替えて提供されるので、基地局装置２０がない場所であっても、切替を伝搬させることができる。すなわち、基地局装置２０がない場所を移動する車両であっても、切替後の他の端末装置１０からのパケット信号を受信することによって切り替わる。なお、ＭＡＣ検証は、発信元の真正性が確認できない点に鑑み、異なる複数（例えば１０台）の基地局装置２０または他の端末装置１０から受信したパケット信号の検証の成功にもとづいて、送信用鍵デーブルを切り替えるようにする。また、路車間通信のパケット信号に電子署名が付いている場合、電子署名は発信元の真正性が確認できることに鑑みて、受信したパケット信号に対する電子署名の検証成功時と、ＭＡＣの検証成功時の切替の判断基準を変えてもよい。例えば、基地局装置２０から受信したパケット信号に含まれるセキュリティフレームの電子署名の検証に成功したとき、あるいは、複数台（例えば１０台）の他の端末装置１０から受信したパケット信号に含まれるセキュリティフレームのＭＡＣの検証に成功したときとなる。
【００８７】
なお、共通鍵テーブルの更新は次のように行われてもよい。まず、端末装置１０は自己の機器ＩＤを含む更新要求信号をシステム運用管理装置３００に送信する。システム運用管理装置３００は、各機器ＩＤに対応する公開鍵で新たな共通鍵テーブルを暗号化し、端末装置１０に送信する。両者の通信は、路車間サービス提供者端末装置４００および基地局装置２０を介して実行されてもよいし、その他のネットワークを介して実行されてもよい。端末装置１０は、暗号化された共通鍵テーブルを受信すると、ユニークな秘密鍵で復号する。
【００８８】
また、各機器ＩＤに対応する公開鍵にかえて各機器ＩＤに対応する共通鍵を使用してもよい。システム運用管理装置３００は、各機器ＩＤを受け取って、その機器ＩＤに対応する共通鍵を使用して新たな共通鍵テーブルを暗号化し、端末装置１０に送信する。このとき、端末装置１０とシステム運用管理装置３００間の通信路については特に限定を加えない。
【００８９】
本発明の実施例によれば、複数世代の共通鍵テーブルのうち、中間の世代の共通鍵テーブルを送信用鍵テーブルとして使用している状況下において、送信用鍵テーブルと受信用鍵テーブルとを監視するので、共通鍵テーブルに問題が発生しうる場合を検出できる。また、共通鍵テーブルに問題が発生しうる場合が検出されるので、共通鍵暗号化方式を用いた通信システムのセキュリティを効率的に向上できる。また、送信用鍵テーブルとして使用される共通鍵テーブルの世代よりも先の共通テーブルの数が、予め規定された数よりも少ない場合に、警告を出力するので、共通鍵テーブルが更新されていない状況を知らせることができる。また、共通鍵テーブルが更新されていない状況が知らされるので、共通鍵テーブルを更新させるための対策を施すことができる。また、送信用鍵テーブルとして使用すべき共通鍵テーブルが、記憶されている共通鍵テーブルと異なる場合に、警告を出力するので、送信用鍵テーブルとして使用すべき共通鍵テーブルの書換エラーを検出できる。
【００９０】
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素あるいは各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００９１】
上記課題を解決するために、本発明のある態様の車載器は、パケット信号をブロードキャスト送信する車車間通信を実行する車載器であって、車車間通信を実行可能な期間において、他の車載器からブロードキャスト送信されたパケット信号を受信するとともに、車車間通信を実行可能な期間のうちのパケット信号の受信期間以外の期間において、パケット信号をブロードキャスト送信する通信部と、車車間通信に使用可能な共通鍵を複数種類含む共通鍵テーブルが複数世代にわたって記憶される記憶部と、記憶部に記憶される複数世代の共通鍵テーブルのうち、ひとつの世代の共通鍵テーブルを送信用鍵テーブルとして使用することによって、通信部からブロードキャスト送信すべきパケット信号に対する暗号化を実行するとともに、記憶部に記憶される複数世代の共通鍵テーブルを受信用鍵テーブルとして使用することによって、通信において受信したパケット信号に対する復号を実行するセキュリティ処理部と、セキュリティ処理部において使用される送信用鍵テーブルと受信用鍵テーブルとを監視する監視部とを備える。セキュリティ処理部は、受信用鍵テーブルに含まれた複数世代の共通鍵テーブルのうち、中間の世代の共通鍵テーブルを送信用鍵テーブルとして使用し、監視部は、共通鍵テーブルの監視結果に応じた警告を出力する。
【００９２】
この態様によると、受信用鍵テーブルに含まれた複数世代の共通鍵テーブルのうち、中間の世代の共通鍵テーブルを送信用鍵テーブルとして使用している場合に、それらを監視するので、共通鍵テーブルに問題が発生しうる状態を警告できる。
【００９３】
セキュリティ処理部において送信用鍵テーブルとして使用される共通鍵テーブルの世代よりも前の共通テーブルの数と、送信用鍵テーブルとして使用される共通鍵テーブルの世代よりも先の共通テーブルの数とは予め規定されており、監視部は、送信用鍵テーブルとして使用される共通鍵テーブルの世代よりも先の共通テーブルの数が、予め規定された数よりも少ない場合に、警告を出力してもよい。この場合、送信用鍵テーブルとして使用される共通鍵テーブルの世代よりも先の共通テーブルの数が、予め規定された数よりも少ない場合に、警告を出力するので、共通鍵テーブルが更新されていないことを知らせることができる。
【００９４】
監視部は、セキュリティ処理部において送信用鍵テーブルとして使用予定の共通鍵テーブルが、記憶部に記憶されている共通鍵テーブルと異なる場合に、警告を出力してもよい。この場合、送信用鍵テーブルとして使用すべき共通鍵テーブルの設定に誤りがあることを知らせることができる。
【符号の説明】
【００９５】
１０  端末装置、  １１  アンテナ、  １２  ＲＦ部、  １３  変復調部、  １４  ＭＡＣフレーム処理部、  １５  セキュリティ処理部、  １６  データ生成部、  １８  記憶部、  １９  制御部、  ２０  基地局装置、  ２１  アンテナ、  ２２  ＲＦ部、  ２３  変復調部、  ２４  ＭＡＣフレーム処理部、  ２５  セキュリティ処理部、  ２６  データ生成部、  ２７  ネットワーク通信部、  ２８  記憶部、  ２９  制御部、  ３０  監視部、  １００  車両、  １５６  暗復号部、  １５７  復号部、  １５８  鍵更新部、  １７１  受信処理部、  １７２  通知部、  ２００  外部ネットワーク、  ２０２  エリア、  ２０４  エリア外、  ２５６  暗復号部、  ２５７  暗号部、  ２５８  鍵更新部、  ３００  システム運用管理装置、  ４００  路車間サービス提供者端末装置、  ４６０  共通鍵テーブル設定装置、  ５００  通信システム。
【図１】
2015050586.tif 000003
【図２】
2015050586.tif 000004
【図３】
2015050586.tif 000005
【図４】
2015050586.tif 000006
【図５】
2015050586.tif 000007
【図６】
2015050586.tif 000008
【図７】
2015050586.tif 000009
【図８】
2015050586.tif 000010
【図９】
2015050586.tif 000011
【図１０】
2015050586.tif 000012
【図１１】
2015050586.tif 000013
【図１２】
2015050586.tif 000014
【図１３】
2015050586.tif 000015
【図１４】
2015050586.tif 000016
【図１５】
2015050586.tif 000017
【図１６】
2015050586.tif 000018
【図１７】
2015050586.tif 000019
【図１８】
2015050586.tif 000020
【図１９】
2015050586.tif 000021