JP6103274B2

JP6103274B2 - 車載器

Info

Publication number: JP6103274B2
Application number: JP2015232011A
Authority: JP
Inventors: 堀　吉宏; 吉宏堀
Original assignee: Panasonic Intellectual Property Management Co Ltd
Current assignee: Panasonic Intellectual Property Management Co Ltd
Priority date: 2011-01-25
Filing date: 2015-11-27
Publication date: 2017-03-29
Anticipated expiration: 2031-12-20
Also published as: JP5895216B2; JP2013232952A; JP5350559B2; JP5367917B2; WO2012101721A1; JP2017143519A; JP5341272B2; JP2016054545A; US20130230173A1; JP2014030207A; JP2013225875A; JPWO2012101721A1; CN103141055A

Description

本発明は、通信技術に関し、特に所定の情報が含まれた信号を送受信する車載器に関する。

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

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

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

ブロードキャストを前提とした路車間通信および車車間通信では、メッセージを送信する場合に、鍵データの交換ができないこと、および、リアルタイム性を重視する必要があることから、共通鍵暗号化方式を採用することが有力である。この場合、同一システム上の車載器および路側機では原則的にすべて共通の暗号鍵が共有されることになる。しかしながら、このようなシステムにおいて、いずれかの車載器または路側機から暗号鍵が漏洩すると、システム全体のセキュリティが大きく低下する。そこで、複数の暗号鍵を含む暗号鍵テーブルを作成して、データ送信の際に使用する暗号鍵をランダムに選択したり、暗号鍵テーブル自体を定期的に更新することにより、セキュリティを向上させる手法が検討されている。

本発明はこうした状況に鑑みてなされたものであり、その目的は、暗号鍵テーブルの更新処理の安全性を高める技術を提供することにある。

さらに本発明の別の目的は、通信鍵が漏洩することによるセキュリティ低下を緩和させる技術を提供することにある。

本発明のある態様の通信装置は、同一システム内における他の通信装置との通信に使用可能な共通鍵を複数種類含む共通鍵テーブル、自己の識別情報および当該識別情報に紐付けされた更新鍵を記憶する記憶部と、識別情報を、システム内で使用される共通鍵テーブルおよびシステム内における通信装置の識別情報と当該識別情報に紐付けされた更新鍵を管理するシステム管理装置に送信する送信部と、識別情報を受信したシステム管理装置から、識別情報に紐付けされた更新鍵を使用して暗号化された更新用の共通鍵テーブルを取得する取得部と、暗号化された更新用の共通鍵テーブルを、記憶部に記憶された更新鍵を使用して復号する復号部と、を備える。

本発明の別の態様もまた、通信装置である。この装置は、受信データを復号するセキュリティ処理部と、同一システム内における他の通信装置との通信に使用可能な共通鍵を複数種類含む共通鍵テーブル、セキュリティ処理部の登録情報および当該登録情報に紐付けされた登録鍵を記憶する記憶部と、登録情報を、システム内で使用される共通鍵テーブルおよびシステム内における通信装置に含まれるセキュリティ処理部の登録情報と当該登録情報に紐付けされた登録鍵を管理するシステム管理装置に送信する送信部と、登録情報を受信したシステム管理装置から、登録情報に紐付けされた登録鍵を使用して暗号化された更新用の共通鍵テーブルを取得する取得部と、を備える。セキュリティ処理部は、暗号化された更新用の共通鍵テーブルを、記憶部に記憶された登録鍵を使用して復号する。

本発明の別の態様もまた、通信装置である。この装置は、同一システム内における他の通信装置との通信に使用可能な共通鍵を複数種類含む共通鍵テーブルおよびシステム内で共通の更新マスタ鍵を記憶する記憶部と、共通鍵テーブルを管理するシステム管理装置から送信された更新用の共通鍵テーブルを暗号化するためのテーブル更新鍵およびテーブル更新鍵により暗号化された更新用の共通鍵テーブルを取得し、更新対象となる通信装置から送信されたその通信装置の識別情報を取得する取得部と、更新マスタ鍵と通信装置の識別情報を使用して、テーブル更新鍵を暗号化する暗号部と、暗号部により暗号化されたテーブル更新鍵と、暗号化された更新用の共通鍵テーブルを報知する報知部と、を備える。

本発明の別の態様もまた、通信装置である。この装置は、同一システム内における他の通信装置との通信に使用可能な共通鍵を複数種類含む共通鍵テーブル、システム内で共通の更新マスタ鍵および自己の識別情報を記憶する記憶部と、識別情報を報知する報知部と、識別情報を取得した通信装置から、識別情報と通信装置が保有する更新マスタ鍵を使用して暗号化されたテーブル更新鍵と、テーブル更新鍵により暗号化された更新用の共通鍵テーブルを取得する取得部と、暗号化されたテーブル更新鍵を、記憶部に記憶された識別情報および更新マスタ鍵を使用して復号し、復号したテーブル更新鍵により暗号化された更新用の共通鍵テーブルを復号する復号部と、を備える。

本発明の別の態様もまた、通信装置である。この装置は、同一システム内における他の通信装置との通信に使用可能な通信鍵を複数含む鍵テーブルを記憶する記憶部と、鍵テーブルを運用管理するシステム運用管理装置から送信された使用不可とすべき通信鍵の識別情報を取得する取得部と、取得部により取得された使用不可とすべき通信鍵の識別情報を報知する報知部と、を備える。

本発明の別の態様もまた、通信装置である。この装置は、同一システム内における他の通信装置との通信に使用可能な通信鍵を複数含む鍵テーブルを記憶する記憶部と、他の通信装置から、使用不可とすべき通信鍵の識別情報を取得する取得部と、取得部により取得された使用不可とすべき通信鍵の識別情報をもとに、鍵テーブルに含まれる当該通信鍵を無効化する更新部と、を備える。

本発明の別の態様もまた、通信装置である。この装置は、同一システム内における他の通信装置との通信に使用可能な共通鍵を複数含む共通鍵テーブルおよびシステム内で共通の更新マスタ鍵を記憶する記憶部と、共通鍵テーブルを管理するシステム管理装置から送信された、失効させるべき共通鍵を示すネガフラグ付き共通鍵テーブルを暗号化するためのテーブル更新鍵およびテーブル更新鍵により暗号化された更新用の共通鍵テーブルを取得し、更新対象となる通信装置から送信されたその通信装置の識別情報を取得する取得部と、更新マスタ鍵と前記通信装置の識別情報を使用して、テーブル更新鍵を暗号化する暗号部と、暗号部により暗号化されたテーブル更新鍵と、暗号化された更新用の共通鍵テーブルを報知する報知部と、を備える。

本発明の別の態様もまた、通信装置である。この装置は、同一システム内における他の通信装置との通信に使用可能な共通鍵を複数含む共通鍵テーブル、システム内で共通の更新マスタ鍵および自己の識別情報を記憶する記憶部と、識別情報を報知する報知部と、識別情報を取得した通信装置から、識別情報と通信装置が保有する更新マスタ鍵を使用して暗号化されたテーブル更新鍵と、前記テーブル更新鍵により暗号化されたネガフラグ付き共通鍵テーブルを取得する取得部と、暗号化されたテーブル更新鍵を、記憶部に記憶された識別情報および更新マスタ鍵を使用して復号し、復号したテーブル更新鍵により暗号化されたネガフラグ付き共通鍵テーブルを復号する復号部と、を備える。

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

本発明によれば、暗号鍵テーブルの更新処理の安全性を高めることができる。

本発明の実施例に係る通信システムの構成を示す図である。基地局装置の構成を示す図である。通信システムにおいて規定されるパケット信号に格納されるＭＡＣフレームのフォーマットを示す図である。図４（ａ）−（ｂ）は、セキュリティフレームを構成するメッセージのデータ構造の例を示す図である。メッセージタイプのデータ構造を示す図である。鍵ＩＤのデータ構造を示す図である。通信システム上の各機器で共有されるべき共通鍵テーブルの例を示す図である。送信テーブルの切り替えを説明するための図である。車両に搭載された端末装置の構成を示す図である。路側機（基地局装置）から車載器（端末装置）への路車間通信におけるメッセージ送信を説明するための図である。共通鍵テーブルの書き換えを説明するための図である。共通鍵テーブルのフォーマットを示す図である。路側機（基地局装置）から車載器（端末装置）への路車間通信における共通鍵テーブルの更新を説明するための図である。路側機（基地局装置）から車載器（端末装置）への路車間通信における共通鍵テーブルの更新の変形例を説明するための図である。ネガフラグ付き共通鍵テーブルのフォーマットを示す図である。失効鍵の書き換えを説明するための図である。路側機（基地局装置）から車載器（端末装置）への路車間通信における共通鍵の失効を説明するための図である。路側機（基地局装置）から車載器（端末装置）への路車間通信におけるネガフラグ付き共通鍵テーブルの更新を説明するための図である。変形例に係る共通鍵テーブルの書き換えを説明するための図である。図２０（ａ）−（ｂ）は、変形例に係る共通鍵テーブルの更新手順を説明するための図である。変形例に係る共通鍵テーブルのフォーマットを示す図である。変形例に係るセキュリティフレームの第１のフォーマットを示す図である。変形例に係るセキュリティフレームの第２のフォーマットを示す図である。変形例に係る共通鍵テーブルの運用方法を説明するための図である。図２２のセキュリティフレームの第１のフォーマットの変形例を示す図である。

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

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

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

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

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

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

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

図３は、通信システム５００において規定されるパケット信号に格納されるＭＡＣフレームのフォーマットを示す。ＭＡＣフレームには、前段から「ＭＡＣヘッダ」、「ＬＬＣヘッダ」、「情報ヘッダ」、「セキュリティフレーム」が配置される。「ＭＡＣヘッダ」、「ＬＬＣヘッダ」および「情報ヘッダ」にはデータ通信制御に関わる情報が格納されており、それぞれが通信レイヤの各層に対応する。各フィード長は、たとえば、「ＭＡＣヘッダ」が３０バイト、「ＬＬＣヘッダ」が８バイト、「情報ヘッダ」が１２バイトで規定される。セキュリティフレームには、前段から「セキュリティヘッダ」、「ペイロード」、「セキュリティフッタ」が配置される。

図４（ａ）−（ｂ）は、セキュリティフレームを構成するメッセージのデータ構造の例を示す。図４（ａ）に示すメッセージのデータ構成には、セキュリティヘッダとして、「バージョン」、「メッセージタイプ」、「鍵ＩＤ」、「ｎｏｎｃｅ」および「ペイロード長」が含まれる。ペイロードとして、「機器ＩＤ」、「アプリケーションデータ長」、「アプリケーションデータ」、「管理データ長」および「管理データ」が含まれる。セキュリティフッタとして、「メッセージ認証コード」が含まれる。

本来、「ペイロード」が認証および暗号化の対象データである。しかしながら、認証の信頼性を上げるために、「ｎｏｎｃｅ」、「ペイロード長」も認証の対象に含める。具体的には、先頭ブロックに「ｎｏｎｃｅ」、「ペイロード長」を配置し、第２ブロック以降に「ペイロード」を配置したブロック列を対象としてメッセージ認証コードを求める。ここで、ブロックとはメッセージ認証コードを演算するための単位である。「ｎｏｎｃｅ」は、「ペイロード」が同一であっても、発信毎に「メッセージ認証コード」の値が異なるようにすることを目的とするデータであり、メッセージ毎にユニークな値がセットされる。「ペイロード長」は、「ペイロード」のデータ長を示し、データ挿入または削除を伴うデータ改ざんに対する信頼性を向上させる。同様に、「メッセージ認証コード」も暗号化対象範囲に含める。

このデータ構造では、「ｎｏｎｃｅ」、「ペイロード長」、「機器ＩＤ」、「アプリケーションデータ長」、「アプリケーションデータ」、「管理データ長」および「管理データ」が認証対象範囲である。また、「機器ＩＤ」、「アプリケーションデータ長」、「アプリケーションデータ」、「管理データ長」、「管理データ」および「メッセージ認証コード」が暗号化対象範囲である。

図４（ｂ）に示すメッセージのデータ構成には、セキュリティヘッダとして、「バージョン」、「メッセージタイプ」、「鍵ＩＤ」および「ｎｏｎｃｅ」が含まれる。ｎｏｎｃｅには、「機器ＩＤ」および「送信日時」が含まれる。ペイロードとして、「アプリケーションデータ長」、「アプリケーションデータ」、「管理データ長」および「管理データ」が含まれる。セキュリティフッダとして、「メッセージ認証コード」が含まれる。このデータ構造では、「ｎｏｎｃｅ」、「ペイロード長」、「アプリケーションデータ長」、「アプリケーションデータ」、「管理データ長」および「管理データ」が認証対象範囲である。また、「アプリケーションデータ長」、「アプリケーションデータ」、「管理データ長」、「管理データ」および「メッセージ認証コード」が暗号化対象範囲である。なお、いずれの場合も暗号の対象となるのは、ペイロードとメッセージ認証コードである。

図５は、メッセージタイプのデータ構造を示す。メッセージタイプは「保護形式」および「管理データ」により構成される。「保護形式」には「０」、「１」、「２」、「３」のいずれかがセットされる。「０」はメッセージが平文であることを示す。メッセージ認証コードは添付されず、暗号化されない。「１」はメッセージがデータ認証付きデータであることを示す。たとえば、ＡＥＳ（ＡｄｖａｎｃｅｄＥｎｃｒｙｐｔｉｏｎＳｔａｎｄａｒｄ）−ＣＢＣ（ＣｉｐｈｅｒＢｌｏｃｋＣｈａｉｎｉｎｇ）−ＭＡＣ（ＭｅｓｓａｇｅＡｕｔｈｅｎｔｉｃａｔｉｏｎＣｏｄｅ）方式を採用することができる。この場合、ＡＥＳ−ＣＢＣモード暗号処理により生成されたＭＡＣがメッセージに添付される。「２」はメッセージがデータ認証付き暗号化データであることを示す。たとえば、ＡＥＳ−ＣＣＭ（ＣｏｕｎｔｅｒｗｉｔｈＣＢＣ−ＭＡＣ）方式を採用することができる。ＡＥＳ−ＣＣＭモード暗号処理により生成されたＭＡＣがメッセージに添付されるとともに、ＡＥＳ−Ｃｏｕｎｔｅｒモードで暗号化される。「３」はリザーブである。

「管理データ」には「０」、「１」のいずれかがセットされる。「０」は管理データが含まれないことを示す。この場合、管理データフィールド（管理データ長と管理データをいう）は設定されない。車車間通信では、原則として「０」がセットされる。「１」は管理データフィールドが含まれることを示す。なお、「０」がセットされた場合、冗長を排除するために、アプリケーションデータ長も設定しないように変更してもよい。図４（ａ）では、ペイロードに含まれるデータが、固定長の機器ＩＤと、アプリケーションデータとなるため、アプリケーションデータ長を設定しなくても、アプリケーションデータを特定できる。図４（ｂ）では、ペイロードに含まれるデータが、アプリケーションデータのみとなるためより自明である。

図６は、鍵ＩＤのデータ構造を示す。鍵ＩＤは「テーブル番号」および「鍵番号」により構成される。「テーブル番号」には、共通鍵テーブルの識別番号がセットされる。「鍵番号」には、共通鍵テーブル内での鍵の識別番号がセットされる。発信時には、予め定められた送信用に使用される共通鍵テーブルから、ランダムに選択された鍵を通信鍵として使用する。よって、テーブル番号には、送信用の共通鍵テーブルの番号が、鍵番号には、乱数がセットされる。

「機器ＩＤ」は「種別」および「個別情報」により構成される。「種別」には路側機であるか、緊急車両であるか、一般車両であるかを識別するための情報がセットされる。「個別情報」には各機器を識別するためのユニークな値がセットされる。

図４（ａ）における「ｎｏｎｃｅ」には、メッセージ毎にユニークな値がセットされる。この値は乱数であってもよい。図４（ｂ）における「ｎｏｎｃｅ」には、当該ユニークな値の代わりに、機器ＩＤと送信時刻がセットされる。機器ＩＤと送信時刻が特定されれば、各メッセージをユニークに特定できるという設計思想にもとづいている。

「アプリケーションデータ」には、上述した交差点情報、渋滞情報、車両情報などがセットされる。「管理データ」には、鍵の更新などセキュリティに関するメンテナンス情報などがセットされる。

図７は、通信システム５００上の各機器で共有されるべき共通鍵テーブルの例を示す。それぞれ複数種類の共通鍵を含む複数の共通鍵テーブルが共有される。複数の共通鍵テーブルはそれぞれ、値の異なる複数の共通鍵を含む。本実施例では、それぞれ１６種類の共通鍵を含む１６種類の共通鍵テーブルが共有される例を挙げる。すなわち、２５６個の共通鍵を共有する例を挙げる。なお、各共通鍵テーブルに含まれる共通鍵の数は同じである必要はなく、異なっていてもよい。

複数の共通鍵テーブルのうち、送信用に使用される共通鍵テーブル（以下、送信テーブルという）が一つ選択される。この送信テーブルは定期的（たとえば、６ヶ月、１年または２年ごと）に切り替えられる。図７では、共通鍵テーブル０→共通鍵テーブル１→・・・共通鍵テーブル１５と切り替えられ、最後の共通鍵テーブル１５に到達すると、最初の共通鍵テーブル０に戻る。送信テーブルにおいて、使用される共通鍵はランダムに選択される。

図８は、送信テーブルの切り替えを説明するための図である。本実施例では、送信テーブルの切り替えタイミングは、システム運用管理機関３０により決定される。システム運用管理機関３０のシステム運用管理装置３００は、路車間サービス事業者４０の路車間サービス事業者端末装置４００および車両メーカ６０の車両メーカ端末装置６００に、送信テーブルの切り替えを指示する。本実施例では、インターネットや専用回線などの外部ネットワーク２００を介してシステム運用管理装置３００から路車間サービス事業者端末装置４００および車両メーカ端末装置６００に送信テーブルの切り替えを指示する例を想定する。なお、システム運用管理機関３０は、その他の通信手段（たとえば、郵便）を用いて路車間サービス事業者４０および車両メーカ６０に指示してもよい。

路車間サービス事業者端末装置４００は、路側機（基地局装置２０）に切り替え後の送信テーブルに含まれる共通鍵を含むメッセージを送信する。路側機は、そのメッセージを受信すると、当該共通鍵を含む共通鍵テーブルを新たな送信テーブルに設定する。路側機は、新たに送信テーブルに設定された共通鍵テーブルに含まれる共通鍵を用いたメッセージを報知する。既存車両１００の車載器（端末装置１０）は、そのメッセージを受信すると、当該共通鍵を含む共通鍵テーブルを新たな送信テーブルに設定する。その後、当該車載器は、新たに送信テーブルに設定された共通鍵テーブルに含まれる共通鍵を含むメッセージを報知する。別の既存車両１００の車載器は、そのメッセージを受信すると、当該共通鍵を含む共通鍵テーブルを新たな送信テーブルに設定する。この処理を繰り返す。

また、車両メーカ端末装置６００は、新車両１００の車載器（端末装置１０）に、路車間サービス事業者端末装置４００から指示された共通鍵テーブルを送信テーブルに設定する。当該車載器は、その送信テーブルに設定された共通鍵テーブルに含まれる共通鍵（通信鍵）を含むメッセージを報知する。既存車両１００の車載器は、そのメッセージを受信すると、当該共通鍵を含む共通鍵テーブルを新たな送信テーブルに設定する。その後、当該車載器は、新たに送信テーブルに設定された共通鍵テーブルに含まれる共通鍵を含むメッセージを報知する。別の既存車両１００の車載器は、そのメッセージを受信すると、当該共通鍵を含む共通鍵テーブルを新たな送信テーブルに設定する。この処理を繰り返す。

以上の処理により、通信システム５００における各機器の送信テーブルが伝搬的に切り替えられていく。なお、このような伝搬システムの代わりに、各機器に予め設定されたスケジュールプログラムにしたがって送信テーブルを切り替えてもよい。ただし、この手法は時計が搭載されていること、その時計が正確であること、そして路側機および車載器の時計の同期がとれていることが条件となる。したがって、それを補完するために、両者の手法を併用してもよい。なお、図８では路車間サービス事業者端末装置４００、車両メーカ端末装置６００および路側機を一つずつ描いているが、実際にはそれぞれ多数存在する。

図２に戻る。ＲＦ部２２は、受信処理として、端末装置１０および他の基地局装置２０からのパケット信号をアンテナ２１にて受信する。本実施例では、ＲＦ部２２は共通鍵テーブルの更新対象となる端末装置１０からその端末装置１０の機器ＩＤを格納するパケット信号を受信する。

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

ＲＦ部２２は、送信処理として、生成したパケット信号を基地局装置２０から送信する。本実施例では、ＲＦ部２２はセキュリティ処理部２５により暗号化されたテーブル更新鍵（以下、暗号化テーブル更新鍵という）を格納するパケット信号、および暗号化された更新共通鍵テーブル（以下、暗号化更新共通鍵テーブルという）を格納するパケット信号を報知する。暗号化テーブル更新鍵を報知するタイミングと、暗号化更新共通鍵テーブルを報知するタイミングは異なっていてもよいし、同じであってもよい。タイミングが異なる場合、暗号化テーブル更新鍵が暗号化更新共通鍵テーブルより先に報知されてもよいし、後に報知されてもよい。

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

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

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

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

ネットワーク通信部２７は、外部ネットワーク２００に接続される。ネットワーク通信部２７は、外部ネットワーク２００から工事や渋滞などに関する道路情報を受けつける。本実施例ではシステム運用管理装置３００から送信された後述する失効鍵ＩＤを路車間サービス事業者端末装置４００を介して受信する。また、本実施例ではシステム運用管理装置３００から送信された更新用の共通鍵テーブルを暗号化するためのテーブル更新鍵および当該テーブル更新鍵により暗号化された暗号化更新共通鍵テーブルを路車間サービス事業者端末装置４００を介して受信する。また、システム運用管理装置３００から送信される共通鍵テーブルを更新すべきでない端末装置１０のリスト（以下、機器ネガリストという）も受信する。機器ネガリストに登録される機器は、改ざん車載器や機器に不具合が発見され、メーカによる回収が進められている機器などが該当する。

また、ネットワーク通信部２７は、セキュリティ処理部２５による処理結果を外部ネットワーク２００へ出力したり、記憶部２８に蓄積して、定期的に外部ネットワーク２００へ出力したりする。データ生成部２６は、アプリケーションデータを生成する。たとえば、アプリケーションデータに道路情報をセットする。そして、アプリケーションデータの内容によって、保護形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部２５に出力する。

記憶部２８は、種々の情報を記憶する。本実施例では、上記共通鍵テーブル、通信システム５００内で共通の更新マスタ鍵および上記機器ネガリストを記憶する。なお、当該共通鍵テーブルおよび当該更新マスタ鍵は出荷時に組み込まれていてもよいし、事後的にネットワーク通信部２７を介して取得されたものであってもよい。また、記憶部２８は、端末装置１０から取得した機器ＩＤおよび車両情報、ならびにシステム運用管理装置３００から取得した暗号化更新共通鍵テーブル、テーブル更新鍵および道路情報を一時的に記憶する。制御部２９は、基地局装置２０全体の処理を制御する。

セキュリティ処理部２５は、セキュリティフレームを生成または解釈する。セキュリティ処理部２５は、ＭＡＣフレーム処理部２４に出力すべきセキュリティフレームを、記憶部２８に記憶されているデータをもとに生成する。データ生成部２６から受け取ったアプリケーションデータを、ペイロードの「アプリケーションデータ」に、データ長をペイロードの「アプリケーションデータ長」にセットする。または、「管理データ」に、必要に応じて、後述する失効鍵ＩＤ、後述する暗号化テーブル更新鍵または暗号化更新共通鍵テーブルをセットし、セキュリティヘッダおよびセキュリティフッタを付加してセキュリティフレームを生成する。その際、上述したようにメッセージ認証コードを生成して添付し、データ認証させることが可能である。さらに、ペイロードおよびメッセージ認証コードを暗号化することで、メッセージを秘匿することも可能である。

セキュリティ処理部２５は、暗復号部２５１および暗号部２５２を含む。暗復号部２５１は、ペイロードに対するデータ認証および暗号化を行うことができる。セキュリティ処理部２５は、データ生成部２６から指示されるアプリケーションデータからの要求と、セキュリティ処理部２５がセットする管理データからの要求の双方に鑑み、セキュリティフレームの保護機能を選択する。管理データを発信する場合は、通常、データ認証付き暗号化データ（＝３）が選択される。そして、保護機能を、セキュリティフレームの当該フィールドにセットする。次いで、暗復号部２５１に保護機能をセットしたセキュリティフレームを出力する。暗復号部２５１は、保護機能が平文（＝０）の場合、処理を省略する。データ認証付きデータ（＝１）の場合、送信テーブルから鍵を選択し、その鍵を用いてメッセージ認証コードを生成する。次いで、選択した鍵の鍵ＩＤおよびメッセージ認証コードを、セキュリティフレームの当該フィールドにセットする。データ認証付き暗号化データ（＝３）の場合、送信テーブルから鍵を選択し、その鍵を用いてメッセージ認証コードを生成し、選択した鍵の鍵ＩＤおよびメッセージ認証コードを、セキュリティフレームの当該フィールドにセットする。次いで、選択した鍵を使用して、ペイロードおよびメッセージ認証コードを暗号化する。

セキュリティ処理部２５は、送信処理として、共通鍵テーブルに含まれる複数の通信鍵のうち、使用不可とすべき通信鍵（以下、失効鍵という）の識別情報を報知するために失効鍵の識別情報（以下、失効鍵ＩＤという）を管理データにセットする。この失効鍵ＩＤは、失効の対象となる通信鍵の鍵ＩＤに、その真正性を確認するためのメッセージ認証コードを連ねたデータである。また、セキュリティ処理部２５は、暗号化テーブル更新鍵、および暗号化更新共通鍵テーブルを管理データにセットする。なお、更新共通鍵テーブルは、端末装置１０の記憶部１８に記憶されている共通鍵テーブルを書き換える（更新する）ための新たな共通鍵テーブルである。テーブル更新鍵は、暗号化更新共通鍵テーブルを復号するために使用する復号鍵である。失効鍵ＩＤ、暗号化テーブル更新鍵、および、暗号化更新共通鍵テーブルをセットするパケットは、異なっていてもよいし、同じであってもよい。また、タイミングが異なる場合、暗号化テーブル更新鍵が暗号化更新共通鍵テーブルより先に報知されてもよいし、後に報知されてもよい。また、管理データにセットされる失効鍵ＩＤ、および、暗号化テーブル更新鍵は、１つであってもよいし、複数であってもよい。

暗号部２５２は管理データに対するメッセージ認証コードの生成および暗号化を行うことができる。また、本実施例では「管理データ」に上記テーブル更新鍵をセットするに先立ち、暗号部２５２は、上記更新マスタ鍵と端末装置１０の機器ＩＤを使用した所定の暗号化関数を実行することにより、上記テーブル更新鍵を暗号化するための暗号鍵を生成する。管理データとしてテーブル更新鍵を送信する場合は、「管理データ」にはこの暗号鍵により暗号化された暗号化テーブル更新鍵がセットされる。

なお、暗号部２５２は、上記機器ネガリストに含まれる端末装置１０の機器ＩＤについては、上記暗号鍵の生成対象としない。また、仮にその機器ＩＤを使用して上記テーブル更新鍵が暗号化されたとしても、その暗号化テーブル更新鍵は報知の対象から外される。すなわち、当該機器ＩＤと上記更新マスタ鍵を使用して暗号化されるテーブル更新鍵の報知は中止される。また、暗号部２５２にて暗号化されたデータは、「管理データ」にセットされた後、暗復号部２５１にて、メッセージタイプの保護機能にしたがった暗号処理がなされるのは自明である。

セキュリティ処理部２５は、受信処理として、ＭＡＣフレーム処理部２４からのセキュリティフレームを受けつける。セキュリティ処理部２５は、セキュリティフレームのうちのセキュリティヘッダの内容を確認する。メッセージタイプがデータ認証付きデータである場合、暗復号部２５１にてメッセージの検証処理を実行する。メッセージタイプがデータ認証付き暗号化データである場合、暗復号部２５１にてメッセージの検証処理を実行し、復号処理を実行する。なお、メッセージタイプが平文である場合、これらの処理は省略される。

図９は、車両１００に搭載された端末装置１０の構成を示す。端末装置１０は、アンテナ１１、ＲＦ部１２、変復調部１３、ＭＡＣフレーム処理部１４、セキュリティ処理部１５、受信処理部１６１、通知部１６２、データ生成部１７、記憶部１８および制御部１９を備える。セキュリティ処理部１５は、暗復号部１５１および復号部１５２を含む。

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

アンテナ１１、ＲＦ部１２、変復調部１３およびＭＡＣフレーム処理部１４は、図２のアンテナ２１、ＲＦ部２２、変復調部２３およびＭＡＣフレーム処理部２４の構成および動作は基本的に共通する。以下、これらの構成要素については、相違点を中心に説明する。

受信処理部１６１は、セキュリティ処理部１５から受け取ったデータと、データ生成部１７から受け取った自車の車両情報にもとづき、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また、データが画像情報であれば通知部１６２に表示するよう処理する。

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

データ生成部１７は、図示しないＧＰＳ受信機、ジャイロスコープ、車速センサなどから供給される情報にもとづき、端末装置１０が搭載された車両１００の現在位置、進行方向、移動速度などを特定する。なお、現在位置は、緯度・経度によって示される。これらの情報の特定方法は一般的な公知の技術により実現可能であるため、ここでは説明を省略する。データ生成部１７は、特定した情報をもとに他の端末装置１０や基地局装置２０に報知すべきデータを生成し、生成したデータ（以下、アプリケーションデータという）をセキュリティ処理部１５に出力する。また、生成した情報を受信処理部１６１に自車の車両情報として出力する。

記憶部１８は、種々の情報を記憶する。本実施例では、上記共通鍵テーブル、通信システム５００内で共通の更新マスタ鍵、自己の機器ＩＤを記憶する。なお、当該共通鍵テーブルおよび当該更新マスタ鍵は出荷時に組み込まれていてもよいし、事後的にＲＦ部１２を介して取得されたものであってもよい。また、記憶部１８は、自車の車両情報、他の端末装置１０から取得した自車以外の車両情報、基地局装置２０から取得した失効鍵ＩＤ、暗号化更新共通鍵テーブル、暗号化テーブル更新鍵および道路情報を一時的に記憶する。制御部１９は、端末装置１０全体の処理を制御する。

セキュリティ処理部１５は、セキュリティフレームを生成または解釈する。セキュリティ処理部１５は、ＭＡＣフレーム処理部１４に出力すべきセキュリティフレームを、記憶部１８に記憶されたデータをもとに生成する。たとえば、ペイロードの「アプリケーションデータ」に自車の車両情報をセットし、または「機器ＩＤ」に自己の機器ＩＤをセットし、セキュリティヘッダおよびセキュリティフッダを付加してセキュリティフレームを生成する。その際、上述したように、メッセージ認証コードを生成してデータ認証することが可能である。さらに、ペイロードおよびメッセージ認証コードを暗号化することも可能である。

セキュリティ処理部１５は、暗復号部１５１および復号部１５２を含む。暗復号部１５１は、ペイロードのデータ認証および暗号化を行うことができる。すなわち、セキュリティヘッダのメッセージタイプの保護機能に従った処理を行い、基地局装置２０の暗復号部２５１と同等の機能を備える。したがって、送信処理および受信処理は、基地局装置２０の暗復号部２５１と同じであるため説明を割愛する。

本実施例では、セキュリティ処理部１５は、「機器ＩＤ」に自己の機器ＩＤをセットしたセキュリティフレームを生成し、ＭＡＣフレーム処理部１４に出力する。ＭＡＣフレーム処理部１４、変復調部１３およびＲＦ部１２は、当該セキュリティフレームを含むＭＡＣフレームを格納したパケット信号をアンテナ１１から報知する。これにより、自己の機器ＩＤを報知することができる。

ＲＦ部１２は、基地局装置２０からパケット信号を受信する。ＲＦ部１２は、受信したパケット信号を変復調部１３に出力する。具体的には、ＲＦ部１２は、当該機器ＩＤを取得した基地局装置２０から、当該機器ＩＤと当該基地局装置２０が保有するマスタ鍵を使用して暗号化された暗号化テーブル更新鍵を格納したパケット信号を受信する。また、当該基地局装置２０から当該テーブル更新鍵により暗号化された暗号化更新共通鍵テーブルを格納したパケット信号を受信する。暗号化テーブル更新鍵および暗号化更新共通鍵テーブルはペイロードの「管理データ」にセットされる。なお、暗号化テーブル更新鍵と暗号化更新共通鍵テーブルとは、同じパケット信号に格納されていてもよい。

ＲＦ部１２は、これらパケット信号を変復調部１３に出力し、変復調部１３はこれらパケット信号を復調し、ＭＡＣフレーム処理部１４に出力する。ＭＡＣフレーム処理部１４は、ＭＡＣフレームからセキュリティフレームを取り出し、セキュリティ処理部１５に出力する。

セキュリティ処理部１５は、ＭＡＣフレーム処理部１４から受け取ったセキュリティフレームを暗復号部１５１に出力する。暗復号部１５１は、セキュリティフレームを受け取るとメッセージタイプの保護機能に従った処理を行い、セキュリティフレームを、セキュリティ処理部１５に返す。この時、データ認証の結果も通知する。セキュリティ処理部１５は、暗復号部１５１から出力を受けて、処理結果とアプリケーションデータ長およびアプリケーションデータを、受信処理部１６１に出力する。また、データが認証された場合、管理データ長と機器管理データを復号部１５２に出力する。復号部１５２は、管理データに暗号化テーブル更新鍵が含まれる場合、自己の機器ＩＤおよび更新マスタ鍵を使用して復号する。そして、復号したテーブル更新鍵を内部に保持する。暗復号部１５１から入力された管理データに、暗号化更新共通鍵テーブルが含まれる場合、内部に保持したテーブル更新鍵を用いて復号するとともに、復号結果の検証を行う。そして、検証が成功すると更新用の共通鍵テーブルであると判断する。この検証処理の詳細は後述する。さらに、管理データに失効鍵ＩＤが含まれる場合、失効鍵ＩＤに添付されているメッセージ認証コードを利用して、失効鍵ＩＤの検証を行う。この検証処理の詳細は後述する。

図１０は、路側機（基地局装置２０）から車載器（端末装置１０）への路車間通信におけるメッセージ送信を説明するための図である。路側機（基地局装置２０）の処理は、暗復号部２５１の処理に相当し、車載器（端末装置１０）の処理は、暗復号部１５１の処理に相当する。図１１では、メッセージタイプ（保護機能）として、データ認証付き暗号化データが選択されたことを前提とする。他については、不要な処理を省略すればよいので自明である。暗復号部２５１は、送信テーブルのテーブル番号と、乱数を結合して鍵ＩＤを生成する。この時、送信テーブルの乱数は送信テーブルに含まれる共通鍵の数の範囲でランダムに発生する。本実施例では、０〜１５の範囲でランダムに発生する。このとき送信テーブルの「Ｎｅｇａｆｌａｇｓ」を確認し、生成した鍵ＩＤで指定された通信鍵が使用不可の場合、再び、鍵ＩＤを生成する。この処理を、生成した鍵ＩＤで指定された通信鍵が使用可となるまで繰り返す。

暗復号部２５１は、生成した鍵ＩＤにもとづく共通鍵テーブルの通信鍵を今回使用する通信鍵として読み出す。暗復号部２５１は、車載器に報知すべきメッセージのデータ認証範囲に存在するデータと当該通信鍵をもとに、メッセージ認証コード（ＭＡＣ）を生成する。その後、生成されたＭＡＣをメッセージの「メッセージ認証コード」にセットし、当該通信鍵を使用して、「ペイロード」と共に暗号化する。なお、当該メッセージのペイロードに含まれるデータは、アプリケーションデータであってもよいし、管理データであってもよいし、それらの両方であってもよい。このように生成されたメッセージは、路車間メッセージとして報知される。

暗復号部１５１は、受信したメッセージに含まれる鍵ＩＤにもとづき、受信テーブルに設定されている共通鍵テーブルの共通鍵（すなわち、通信鍵）を読み出す。暗復号部１５１は、その通信鍵を用いて当該メッセージの暗号化部分を復号する。これにより、メッセージ認証コード（ＭＡＣ）も復号される。暗復号部１５１は、復号されたＭＡＣおよび当該通信鍵を使用して、受信したメッセージを検証する。検証が成功であれば、受信したメッセージを真正なメッセージとして報告する。なお、説明の簡単のため、ＭＡＣフレームの生成、変調処理については省略した。また、図１０に示した手順は、車車間通信におけるメッセージ送信でも同様である。

つぎに、共通鍵テーブルの書き換え処理について説明する。書き換えの対象となるのは、送信テーブルに設定されていない共通鍵テーブルである。複数の共通鍵テーブルを切り替えて使用することにより一定のセキュリティを確保できるが、長期間使用すると、やはり全体としてのセキュリティは低下していく。そこで、送信テーブルに設定されていない待機中の共通鍵テーブルをテーブル単位で書き換えることにより、セキュリティを向上させることが考えられる。

図１１は、共通鍵テーブルの書き換えを説明するための図である。本実施例では、更新されるべき新共通鍵テーブルは、システム運用管理機関３０により生成される。システム運用管理機関３０のシステム運用管理装置３００は、路車間サービス事業者４０の路車間サービス事業者端末装置４００およびメンテナンス事業者７０のメンテナンス事業者端末装置７００にそれぞれ、上記暗号化更新共通鍵テーブル、上記テーブル更新鍵および上記機器ネガリストを送信する。メンテナンス事業者端末装置７００は、メンテナンス工場に設置された路側機であってもい。路車間サービス事業者端末装置４００は、受信した上記暗号化更新共通鍵テーブル、上記テーブル更新鍵および上記機器ネガリストを路側機（基地局装置２０）に送信する。

当該路側機は、既存車両１００の車載器（端末装置１０）から機器ＩＤを取得し、その機器ＩＤを用いて上記テーブル更新鍵を暗号化し、当該暗号化テーブル更新鍵および上記暗号化更新共通鍵テーブルを上記車載器に提供する。同様に、メンテナンス事業者端末装置７００は、既存車両１００の車載器（端末装置１０）から機器ＩＤを取得し、その機器ＩＤを用いて上記テーブル更新鍵を暗号化し、当該暗号化テーブル更新鍵および上記暗号化更新共通鍵テーブルを上記車載器に提供する。

図１２は、共通鍵テーブルのフォーマットを示す。共通鍵テーブルの「ＦＩｅｌｄ」には、「Ｖｅｒｓｉｏｎ」、「ＴａｂｌｅＩＤ」、「Ｎｕｍｂｅｒｏｆｋｅｙ」、「ＴａｂｌｅＭａｓｔｅｒ」、「ｋｅｙｌｉｓｔ」および「ＭＡＣ」が設けられる。「ｋｅｙｌｉｓｔ」には「ｋｅｙ０」〜「ｋｅｙｎ（ｎは自然数）」が設けられる。

「Ｖｅｒｓｉｏｎ」、「ＴａｂｌｅＩＤ」および「Ｎｕｍｂｅｒｏｆｋｅｙ」は、１バイトの領域が定義される。「ＴａｂｌｅＭａｓｔｅｒ」、「ｋｅｙ０」〜「ｋｅｙｎ」は、１６バイトの領域が定義される。「ＭＡＣ」は１４バイトの領域が定義される。

「ＴａｂｌｅＩＤ」にはテーブル番号がセットされる。「Ｎｕｍｂｅｒｏｆｋｅｙ」にはテーブル内の鍵の数ｎがセットされる。図７に示した例では、１５がセットされる。なお、０も含まれるため、鍵の種類は１６種類である。「ＴａｂｌｅＭａｓｔｅｒ」にはテーブル鍵（テーブルマスタ鍵）がセットされる。「ｋｅｙ０」には鍵番号０のＡＥＳ鍵がセットされる。「ｋｅｙ１」には鍵番号１のＡＥＳ鍵がセットされる。以下、「ｋｅｙｎ」まで同様である。「ＭＡＣ」には前の共通鍵テーブルのテーブル鍵により生成されたＭＡＣ（メンテナンス認証コード）がセットされる。すなわち、テーブル番号ｍ（ｍは自然数）の共通鍵テーブルの「ＭＡＣ」に、テーブル番号（ｍ−１）の共通鍵テーブルに含まれるテーブル鍵を使用して生成されたＭＡＣがセットされる。

図１３は、路側機（基地局装置２０）から車載器（端末装置１０）への路車間通信における共通鍵テーブルの更新を説明するための図である。図１３では、メッセージタイプとして、データ認証付きデータまたはデータ認証付き暗号化データが選択されたことを前提とする。車載器のセキュリティ処理部１５は、記憶部１８に記憶される自己の機器ＩＤを含むメッセージを生成し、生成されたメッセージはブロードキャスト送信される。その機器ＩＤを含むメッセージを受信した路側機のセキュリティ処理部２５は、その機器ＩＤを取り出し、機器ネガリストに登録されているか否か判定する。登録されている場合、以降の処理は実行しない。

登録されていない場合、暗号部２５２は、記憶部２８に記憶されている更新マスタ鍵と当該機器ＩＤを使用した所定の暗号化関数を実行することにより、別の暗号鍵を生成する。暗号部２５２は、その暗号鍵を用いて上記テーブル更新鍵を暗号化する。セキュリティ処理部２５は、この暗号化テーブル更新鍵をメッセージ内のペイロードの「管理データ」にセットする。そして、暗復号部２５１において処理を施した後、そのメッセージを路車間通信で報知する。また、セキュリティ処理部２５は、別の通信パケットにおいて、上記暗号化更新共通鍵テーブルをメッセージ内のペイロードの「管理データ」にセットする。そして、暗復号部２５１において処理を施した後、そのメッセージを路車間通信で報知する。図１３では、上記暗号化更新共通鍵テーブルのほうが上記暗号化テーブル更新鍵の後に報知されているが、先に報知されてもよい。また、暗号化テーブル更新鍵を個別に発信するように記載したが、複数の車載器別の暗号化テーブル更新鍵を同じパケットの管理データ内に配置して発信してもよい。

当該車載器は、共通鍵デーブルの更新が行われる場合、管理データ、すなわち上記暗号化テーブル更新鍵を含むメッセージまたは上記暗号化更新共通鍵テーブルを含むメッセージを受信する。車載器の復号部１５２は、記憶部１８に記憶される自己の機器ＩＤと更新マスタ鍵を使用した所定の暗号化関数を実行することにより、暗号鍵を生成する。この暗号化関数は、路側機で実行される暗号化関数と同じものである。

復号部１５２は、さらに生成した暗号鍵を用いて、路側機から受信したメッセージに含まれる暗号化テーブル更新鍵を復号する。そして、路側機から受信したメッセージに含まれる暗号化更新共通鍵テーブルを復号する。

復号部１５２は、さらに復号して得られた更新用の共通鍵テーブルに含まれるテーブル番号ｍを参照して、記憶部１８に格納される同一テーブル番号ｍの共通鍵テーブルに含まれるテーブル鍵を読み出す。同じテーブル番号で示されるテーブルの世代管理は、バージョンによって識別される。バージョンがことなれば、テーブル鍵も異なるものがセットされている。そして、そのテーブル鍵を使用して、更新用の共通鍵テーブルに含まれるメッセージ認証コードを検証する。検証が成功であれば、受信した共通鍵テーブルを真正な共通鍵テーブルであり、かつ、記憶部１８に格納される共通鍵テーブルであると判断し、記憶部１８に格納されるテーブル番号ｍの共通鍵テーブルを、更新用の共通鍵テーブルで書き換える。なお、メッセージタイプとしてデータ認証付き暗号化データが選択されている場合、復号部１５２での処理の前に、暗復号部１５１にて暗号の復号およびメッセージ認証コードの検証をし、正当であると検証されている必要がある。また、図１３では、説明の簡単のため、ＭＡＣフレームの生成、変調処理については省略した。

図１４は、路側機（基地局装置２０）から車載器（端末装置１０）への路車間通信における共通鍵テーブルの更新の変形例を説明するための図である。車載器のセキュリティ処理部１５は、記憶部１８に記憶される自己の機器ＩＤを含むメッセージを生成する。生成されたメッセージは、ブロードキャスト送信される。その機器ＩＤを含むメッセージを受信した路側機のセキュリティ処理部２５は、その機器ＩＤを取り出し、機器ネガリストに登録されているか否か判定する。登録されている場合、以降の処理は実行しない。

登録されていない場合、暗復号部２５１は、記憶部２８に記憶されている更新マスタ鍵と当該機器ＩＤを使用した所定の暗号化関数を実行することにより、別の暗号鍵を生成する。暗復号部２５１は、その暗号鍵を用いて上記テーブル更新鍵を暗号化し、更新用の共通鍵テーブルのテーブル番号ｍと結合する。この暗号化テーブル更新鍵およびテーブル番号の結合データはメッセージ内のペイロードの「管理データ」にセットされ、そのメッセージは路車間通信で報知される。また、上記暗号化共通鍵更新テーブルもメッセージ内のペイロードの「管理データ」にセットされ、そのメッセージは路車間通信で報知される。

当該車載器は、上記暗号化共通鍵テーブルおよびテーブル番号の結合データを含むメッセージおよび上記暗号化更新共通鍵テーブルを含むメッセージを受信する。車載器の暗復号部１５１は、記憶部１８に記憶される自己の機器ＩＤと更新マスタ鍵を使用した所定の暗号化関数を実行することにより、暗号鍵を生成する。この暗号化関数は、路側機で実行される暗号化関数と同じものである。

復号部１５２は、生成された暗号鍵を用いて、路側機から受信したメッセージに含まれる暗号化テーブル更新鍵とテーブル番号の結合データを分離し、暗号化テーブル更新鍵を復号する。そして、復号部１５２は、共通鍵テーブルのテーブル番号ｍを参照して、記憶部１８に記憶されている１世代前のテーブル番号ｍの共通鍵テーブルに含まれるテーブル鍵を読み出す。同じテーブル番号で示されるテーブルの世代管理は、バージョンによって識別される。

復号部１５２は、さらに復号したテーブル更新鍵と、読み出されたテーブル鍵を使用した所定の暗号化関数を実行することにより、別の復号鍵を生成する。この暗号化関数は、上記機器ＩＤと上記更新マスタ鍵を使用する暗号化関数とは別の関数である。

復号部１５２は、この暗号鍵を使用して上記暗号化更新共通鍵テーブルを復号すると同時に、復号された共通鍵テーブルに含まれるメッセージ認証コードを検証する。

図１５は、ネガフラグ付き共通鍵テーブルのフォーマットを示す。共通鍵テーブルの「Ｆｉｅｌｄ」には、「Ｖｅｒｓｉｏｎ」、「ＴａｂｌｅＩＤ」、「Ｎｅｇａｆｌａｇｓ」、「Ｎｕｍｂｅｒｏｆｋｅｙ」、「ＴａｂｌｅＭａｓｔｅｒ」、「ｋｅｙｌｉｓｔ」および「ＭＡＣ」が設けられる。「ｋｅｙｌｉｓｔ」には「ｋｅｙ０」〜「ｋｅｙｎ（ｎは自然数）」が設けられる。

「Ｖｅｒｓｉｏｎ」、「ＴａｂｌｅＩＤ」および「Ｎｕｍｂｅｒｏｆｋｅｙ」は、１バイトの領域が定義される。「Ｎｅｇａｆｌａｇｓ」は（ｉｎｔ（ｎ／８）＋１）バイト（すなわち、（ｎ＋１）ビットの領域を確保できる最小のバイト数）の領域が定義される。ここで、ｉｎｔ（）は、整数部を取り出す関数である。「ＴａｂｌｅＭａｓｔｅｒ」、「ｋｅｙ０」〜「ｋｅｙｎ」は、１６バイトの領域が定義される。「ＭＡＣ」は１４バイトの領域が定義される。

「ＴａｂｌｅＩＤ」にはテーブル番号がセットされる。「Ｎｕｍｂｅｒｏｆｋｅｙ」にはテーブル内の通信鍵の数−１の値（ｎ）がセットされる。図７に示した例では、１５（ｎ＝１５）がセットされる。なお、０も含まれるため、通信鍵の数は１６個である。「Ｎｅｇａｆｌａｇｓ」にはテーブル内の鍵の使用可否を示すビットマップがセットされる。図７に示した例では、１６個の鍵に対して１６ビットデータが必要となるため、２バイトの領域が用意され、各ビットは各鍵番号に対応する。各ビットの値が「０」で使用可、「１」で使用不可を表す。「ＴａｂｌｅＭａｓｔｅｒ」にはテーブル鍵（テーブルマスタ鍵）がセットされる。「ｋｅｙ０」には鍵番号０の通信鍵がセットされる。「ｋｅｙ１」には鍵番号１の通信鍵がセットされる。以下、「ｋｅｙｎ」まで同様である。暗復号部２５１および暗復号部１５１では、当該共通鍵テーブルのテーブル鍵により生成されたＭＡＣ（メッセージ認証コード）がセットされる。なお、本実施例は、ｎは１５である。なお、この共通鍵テーブルは全ての路側機および車載器が内部に記憶している。

ネガフラグ付き共通鍵テーブルを使用する場合、上記図１０を参照して説明した路車間通信および車車間通信におけるメッセージ送信の手順において、受信側の手順が以下のように変更される。暗復号部１５１は、受信したメッセージに含まれる鍵ＩＤにもとづき、送信テーブルに設定されている共通鍵テーブルの共通鍵（すなわち、通信鍵）を読み出す。このとき「Ｎｅｇａｆｌａｇｓ」の確認も行う。当該鍵ＩＤに対する通信鍵が使用不可になっていれば、検証失敗とする。当該鍵ＩＤに対する通信鍵が使用可の場合、暗復号部１５１は、その通信鍵を用いて当該メッセージの暗号化部分を復号する。これにより、メッセージ認証コード（ＭＡＣ）も復号される。暗復号部１５１は、復号されたＭＡＣおよび当該通信鍵を使用して、受信したメッセージを検証する。検証が成功であれば、受信したメッセージを真正なメッセージとして報告する。

つぎに、失効鍵ＩＤにより共通鍵テーブルの「Ｎｅｇａｆｌａｇｓ」の書き換え処理について説明する。失効鍵は漏洩された通信鍵または漏洩された可能性がある通信鍵である。たとえば、不正な通信傍受により通信鍵が漏洩したことが確認された場合、その通信メッセージに使用されていた通信鍵が該当する。その他、システム運用管理機関３０の判断により、失効が決定された通信鍵も該当する。暗号化・復号化演算においてエラーが発生した通信鍵などが該当する。

図１６は、失効鍵ＩＤによる共通鍵テーブルの「Ｎｅｇａｆｌａｇｓ」の書き換えを説明するための図である。本実施例では、失効鍵ＩＤは、システム運用管理機関３０により生成される。この失効鍵ＩＤには、失効する通信鍵の鍵ＩＤの他に、当該鍵ＩＤで指定される通信鍵が含まれる共通鍵テーブルのテーブル鍵を使用して検証できるメッセージ認証コード（ＭＡＣ）が含まれている。システム運用管理機関３０のシステム運用管理装置３００は、路車間サービス事業者４０の路車間サービス事業者端末装置４００に失効鍵ＩＤを送信する。路車間サービス事業者端末装置４００は、受信した失効鍵ＩＤを路側機（基地局装置２０）に送信する。当該路側機は、受信した失効鍵ＩＤを既存車両１００の車載器に提供する。失効鍵ＩＤを受信すると既存車両１００の車載器は、失効鍵ＩＤの検証を行う。検証によって真正性が確認された場合、失効鍵ＩＤによって示された鍵ＩＤで特定される共通鍵テーブルの「Ｎｅｇａｆｌａｇｓ」に使用不可を示す「１」をセットする。

失効鍵を含む共通鍵テーブル（すなわち、ネガフラグ付き共通鍵テーブル）全体を書き換えることもできる。システム運用管理装置３００は、メンテナンス事業者７０のメンテナンス事業者端末装置７００に当該ネガフラグ付き共通鍵テーブルが暗号化された暗号化更新共通鍵テーブル、当該暗号化更新共通鍵テーブルを復号するためのテーブル更新鍵および上記機器ネガリストを送信する。本実施例では、メンテナンス事業者端末装置７００としてメンテナンス施設に設置された路側機（基地局装置２０）を想定する。

当該路側機は、既存車両１００の車載器（端末装置１０）から機器ＩＤを取得し、その機器ＩＤを用いて上記テーブル更新鍵を暗号化し、当該暗号化テーブル更新鍵および上記暗号化更新共通鍵テーブルを上記車載器に提供する。もちろん、メンテナンス施設以外に設置された一般的な路側機からそれらを提供してもよい。

図１７は、路側機（基地局装置２０）から車載器（端末装置１０）への路車間通信における共通鍵の失効を説明するための図である。図１７は、「管理データ」に関する処理、ここでは失効鍵ＩＤに対する処理のみ記載してある。車載器における処理は、復号部１５２において実行される。前述したように、路車間メッセージには、これとは別にメッセージタイプによる処理が施される。管理データに失効鍵ＩＤが含められる場合、管理データの発信元を特定できるようにメッセージタイプはデータ認証付きデータまたはデータ認証付き暗号化データが選択される。ここでは、データ認証付き暗号化データとする。また、メッセージタイプに関わる処理は、送信側（路側機）では路車間メッセージ発信の直前、受信側（車載器）では、路車間メッセージ受信直後に実行される。図１７では、説明の簡単化のため、ＭＡＣフレーム処理、変調処理、および、メッセージタイプによる処理については省略した。路側機のセキュリティ処理部２５は、路車間サービス事業者端末装置４００から受け取った失効鍵ＩＤ、あるいは、路車間サービス事業者端末装置４００から受け取って記憶部２８に記憶されている失効鍵ＩＤを、メッセージ内のペイロードの「管理データ」にセットし、暗復号部２５１に出力する。そして、暗復号部２５１において、メッセージタイプによる処理（図１０）が行われたメッセージは路車間通信で報知される。

車載器のセキュリティ処理部１５は、路車間メッセージを受信すると、暗復号部１５１に、受信した路車間メッセージを出力する。暗復号部１５１は、メッセージタイプに関わる受信処理を行い、その結果をセキュリティ処理部１５に返す。セキュリティ処理部１５は、受信したメッセージが検証によって真正性ありと判断され、かつ、管理データに失効鍵ＩＤが含まれる場合、失効鍵ＩＤを復号部１５２に出力する。復号部１５２は、当該失効鍵ＩＤに含まれるテーブル番号を参照して、そのテーブル番号の共通鍵テーブルに含まれるテーブル鍵を読み出す。そして、そのテーブル鍵を使用して、上記失効鍵ＩＤに含まれるメッセージ認証コードを検証する。検証が成功であれば、暗復号部１５１は、当該失効鍵ＩＤに含まれるテーブル番号および鍵番号を参照して、対応する共通鍵テーブルに含まれる通信鍵を無効化する。すなわち、当該失効鍵ＩＤに含まれるテーブル番号で指定された共通鍵テーブルの「Ｎｅｇａｆｌａｇｓ」の内の、当該失効鍵ＩＤに含まれる鍵番号に対応するビットに使用不可を示す「１」をセットする。失効鍵ＩＤを含めた路車間メッセージの送信と受信処理について説明したが、失効鍵ＩＤの配布が必要ない場合は、路車間通信メッセージに失効鍵ＩＤを含める必要はない。また、失効鍵ＩＤの配布の必要がある場合であっても、全ての路車間通信メッセージに失効鍵ＩＤを含める必要はない。路車間メッセージによる通常のサービスに支障がない範囲で、失効鍵ＩＤを含めた路車間メッセージを送信すればよい。

図１８は、路側機（基地局装置２０）から車載器（端末装置１０）への路車間通信におけるネガフラグ付き共通鍵テーブルの更新を説明するための図である。図１７と同様に、説明の簡単化のため、ＭＡＣフレーム処理、変調処理、および、メッセージタイプによる処理については省略した。路側機における処理は暗号部２５２における処理、車載器における処理は復号部１５２における処理に相当する。車載器のセキュリティ処理部１５は、受信した車車間通信メッセージを参照しつつ、自身の周辺を走行する車両１００に搭載される車載器の機器ＩＤを収集する。そして、収集した機器ＩＤから、機器ＩＤを選択する。そして、選択した機器ＩＤを暗号部２５２に入力する。暗号部２５２は、機器ＩＤを受け取ると記憶部２８に記憶されている機器ネガリストに登録されているか否か判定する。登録されている場合、以降の処理は実行しない。

登録されていない場合、暗号部２５２は、記憶部２８に記憶されている更新マスタ鍵と当該機器ＩＤを使用した所定の暗号化関数を実行することにより、別の暗号鍵を生成する。暗号部２５２は、その暗号鍵を用いて上記テーブル更新鍵を暗号化する。セキュリティ処理部２５は、この暗号化テーブル更新鍵をメッセージ内のペイロードの「管理データ」にセットする。そして、暗復号部２５１において処理を施した後、その路車間メッセージを報知する。また、セキュリティ処理部２５は、別の路車間メッセージにおいて、上記暗号化更新共通鍵テーブルをメッセージ内のペイロードの「管理データ」にセットする。そして、暗復号部２５１において処理を施した後、そのメッセージを路車間通信で報知する。図１８では、上記暗号化更新共通鍵テーブルのほうが上記暗号化テーブル更新鍵の後に報知されているが、先に報知されてもよい。また、暗号化テーブル更新鍵を個別に発信するように記載したが、複数の車載器別の暗号化テーブル更新鍵を同じ路車間メッセージの管理データ内に配置して発信してもよい。また、暗号化テーブル更新鍵を含む路車間メッセージの報知と、暗号化更新共通鍵テーブルを含む路車間メッセージの報知の回数を一致させる必要はない。暗号化更新共通鍵テーブルを含む路車間メッセージの報知より、暗号化テーブル更新鍵を含む路車間メッセージの報知の数を増やすことによって、一度の暗号化更新共通鍵テーブルを含む路車間メッセージの報知によって、複数の車載器が、共通鍵テーブルの書き換えを行うことができ、共通鍵テーブルの書き換えに使われるトラヒックを軽減することができる。

当該車載器のセキュリティ処理部１５は、路車間メッセージを受信すると、暗復号部１５１に、受信した路車間メッセージを出力する。暗復号部１５１は、メッセージタイプに関わる受信処理を行い、その結果をセキュリティ処理部１５に返す。セキュリティ処理部１５は、受信したメッセージが検証によって真正性ありと判断され、かつ、自身に対する暗号化テーブル更新鍵が含まれる場合、暗号化テーブル更新鍵を復号部１５２に出力する。車載器の復号部１５２は、記憶部１８に記憶される自己の機器ＩＤと更新マスタ鍵を使用した所定の暗号化関数を実行することにより、暗号鍵を生成し、内部に保持する。この暗号化関数は、路側機で実行される暗号化関数と同じものである。

セキュリティ処理部１５は、受信したメッセージが検証によって真正性ありと判断され、かつ、暗号化更新共通鍵テーブルが含まれる場合、暗号化更新共通鍵テーブルを復号部１５２に出力する。復号部１５２は、内部に生成した暗号鍵を保持しているときに暗号化更新共通鍵テーブルを受け取ると、さらに生成した暗号鍵を用いて、路側機から受信したメッセージに含まれる暗号化テーブル更新鍵を復号する。そして、路側機から受信したメッセージに含まれる暗号化更新共通鍵テーブルを復号する。

復号部１５２は、さらに復号して得られたネガフラグ付き共通鍵テーブルに含まれるテーブル番号ｍを参照して、記憶部１８に格納される同一テーブル番号ｍの共通鍵テーブルに含まれるテーブル鍵を読み出す。同じテーブル番号ｍで示されるテーブルの世代管理は、バージョンによって識別される。バージョンがことなれば、テーブル鍵ｍも異なるものがセットされている。そして、そのテーブル鍵を使用して、ネガフラグ付き共通鍵テーブルに含まれるメッセージ認証コードを検証する。検証が成功であれば、受信したネガフラグ付き共通鍵テーブルを真正な共通鍵テーブルであり、かつ、記憶部１８に格納される共通鍵テーブルであると判断し、記憶部１８に格納されるテーブル番号ｍの共通鍵テーブルを、ネガフラグ付き共通鍵テーブルで書き換える。暗号化テーブル更新鍵または暗号化更新共通鍵テーブルを含めた路車間メッセージの送信と受信処理について説明したが、共通鍵テーブルの更新が必要ない場合は、路車間通信メッセージに暗号化テーブル更新鍵または暗号化更新共通鍵テーブルを含める必要はない。また、共通鍵テーブルの更新が必要な場合であっても、全ての路車間通信メッセージに暗号化テーブル更新鍵または暗号化更新共通鍵テーブルを含める必要はない。路車間メッセージによる通常のサービスに支障がない範囲で、暗号化テーブル更新鍵または暗号化更新共通鍵テーブルを含めた路車間メッセージを送信すればよい。通常のサービスを妨げない範囲で適時配布する。

以上説明したように本実施例によれば、暗号化更新共通鍵テーブルを復号するためのテーブル更新鍵を暗号化して、その暗号化テーブル更新鍵と暗号化更新共通鍵テーブルを基地局装置から端末装置に報知することにより、共通鍵テーブルの更新処理の安全性を高めることができる。また、共通鍵テーブルにメッセージ認証コードを設けることにより、更新用の共通鍵テーブルの真正を検証することができる。また、メッセージ認証コードを、更新用の共通鍵テーブルより、１世代前の共通鍵テーブルのテーブル鍵を用いて生成することにより、更新用の共通鍵テーブルが、端末装置で繰り返し更新される事態を回避することができる。

また、基地局装置から端末装置に失効鍵ＩＤを報知することにより、路車間通信または車車間通信において、共通鍵が漏洩することによるセキュリティ低下を回復させることができる。また、失効鍵ＩＤにメッセージ認証コードを設けることにより、失効鍵ＩＤの真正を検証することができる。また、ネガフラグ付き共通鍵テーブルを用いれば、共通鍵テーブル単位で使用不可とすべき共通鍵を報知することができる。

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

例えば、暗号化テーブル更新鍵を含むメッセージについては、ブロードキャスト送信ではなく、相手先を特定したユニキャスト送信を用いてもよい。

また、上記実施例では、セキュリティフッタにメッセージ認証コードを添付する例を説明したが、その代わりに電子署名を添付してもよい。電子署名は公開鍵暗号方式により暗号化されるため、共通鍵のほかに、秘密鍵と公開鍵が用いられる。

また、上記実施例では、路車間メッセージの管理データを利用して、車載器に記憶されているネガフラグ付き共通鍵テーブルのネガフラグを更新する方法を示したが、同様な暗号処理を用いて、路側機のネガフラグ付き共通鍵テーブルを更新することもできる。また、車車間メッセージに管理データを含めるように変更することで、車車間メッセージも配布するようにしてもよい。これによって、路側機の少ない地域においても失効鍵ＩＤの伝搬を円滑に進めることができる。また、上記実施例では、失効鍵ＩＤに含まれるメッセージ認証コード（ＭＡＣ）のセットや、ネガフラグ付き共通鍵テーブルの暗号化等の処理は、システム運用管理機関３０のシステム運用管理装置３００が行うように説明したが、路側機において行ってもよい。この場合、暗号部２５２において実行される。

また、上記実施例では、メッセージあるいはデータの真正性確認のために共通鍵暗号方式のメッセージ認証コード（ＭＡＣ）を使用するように説明したが、公開鍵方式における電子署名を用いることも可能である。この場合、共通鍵テーブルは、ペイロードおよび電子署名の暗号化に用いられる。そして、セキュリティフレームの「機器ＩＤ」に、機器ＩＤを含めた公開鍵証明書をセットし、「メッセージ認証コード」に、電子署名をセットすればよい。ネガフラグ付き共通鍵テーブルの真正性確認においても同様で、「ＴａｂｌｅＭａｓｔｅｒ」に検証用の公開鍵を、「ＭＡＣ」に電子署名をセットすればよい。

また、上記実施例では、通常サービスを提供する路側機からの失効鍵ＩＤの配布、あるいは、暗号化テーブル更新鍵と暗号化更新共通鍵テーブルの配布について説明したが、通常サービスを提供しない路側機を用いることもできる。車両が、配布専用の路側機のある通信スポットなどに移動して、失効鍵ＩＤや暗号化テーブル更新鍵と暗号化更新共通鍵テーブルの配布を受ける。

また、上記実施例では図１１−１３を参照しながら共通鍵テーブルの更新について説明した。その更新手順では、路側機（基地局装置２０）が車載器（端末装置１０）の機器ＩＤを取得し、通信システム５００で共通の更新マスタ鍵を使用して、テーブル更新鍵を暗号化した。そして、共通鍵テーブルはそのテーブル更新鍵で暗号化した。以下の変形例では更新マスタ鍵の代わりに車載器に紐付けされた、または関連づけられた鍵を使用する例を説明する。以下の変形例では図９に示した端末装置１０のセキュリティ処理部１５にセキュリティモジュール（ＳＡＭ；ＳｅｃｕｒｅＡｐｐｌｉｃａｔｉｏｎＭｏｄｕｌｅ）を使用することを前提とする。セキュリティモジュールは耐タンパ性のある、セキュリティ機能をワンチップ化したデバイスである。

車載器に紐付けられた鍵としてセキュリティモジュールの製造時に埋め込まれる登録鍵を使用できる。登録鍵は同時に埋め込まれた登録情報（たとえば、登録番号）と紐付け管理される。登録鍵は書き換え不能な鍵である。また車載器に紐付けられた鍵としてセキュリティモジュールに不揮発に格納される更新鍵を使用できる。更新鍵は同時に埋め込まれる機器ＩＤと紐付け管理される。更新鍵は登録鍵により書き換え可能である。

図１９は、変形例に係る共通鍵テーブルの書き換えを説明するための図である。システム運用管理装置３００は新しい鍵を発行し、新共通鍵テーブルを生成する鍵発行サーバである。当該変形例ではシステム運用管理装置３００は、出荷された全ての車載器に搭載されるセキュリティモジュールの登録番号と登録鍵および機器ＩＤと更新鍵のデータベースを備える。

専用路側機２０ａは自動車のメンテナンスを行う施設（以下、サービス施設という）に設置される小電力基地局装置である。この装置はリアルタイムの道路情報を端末装置１０に報知する路側機ではなく、特定の端末装置１０に共通鍵テーブルなどのシステム運用に関する情報を無線送信する専用機である。専用路側機２０ａとシステム運用管理装置３００とはインターネットで接続されてもよいし、専用回線で接続されてもよい。

車載器（端末装置１０）は図９に示した構成のうち、共通鍵テーブルの更新に関する構成のみを描いている。なお図１９では、図９のＲＦ部１２、変復調部１３、ＭＡＣフレーム処理部１４をまとめて無線部１１４と表記している。セキュリティ処理部１５はセキュリティモジュールで構成される。記憶部１８はフラッシュメモリで構成される。なお、ハードディスクでもよい。受信処理部１６１はペイロードのアプリケーションデータを処理する機能ブロックである。制御部１９は車載器全体を制御するメインプロセッサである。外部端子１９１は、無線部１１４、専用路側機２０ａを介さずにシステム運用管理装置３００とデータをやりとりするための端子である。例えば、外部端子１９１はＬＡＮケーブルによりサービス施設に設置された端末装置に接続する。その端末装置はインターネットを介してシステム運用管理装置３００に接続する。これにより、車載器とシステム運用管理装置３００とが通信できる。なお、車載器とサービス施設に設置された端末装置とは無線ＬＡＮで接続されてもよいし、記録メディアでデータをやりとりしてもよい。

本変形例では、更新されるべき新共通鍵テーブルは二つの経路でシステム運用管理装置３００から車載器に伝達される。第１の経路は外部端子１９１を経由する経路である。第２の経路は専用路側機２０ａ、無線部１４４を経由する経路である。

図２０（ａ）−（ｂ）は、変形例に係る共通鍵テーブルの更新手順を説明するための図である。図２０（ａ）は第１の経路による更新手順を示す。システム運用管理装置３００は端末装置１０と通信路が形成されると、端末装置１０にＩＤを要求する。端末装置１０のセキュリティ処理部１５は、自身の登録番号と機器ＩＤの結合データをシステム運用管理装置３００に送信する。なお、機器ＩＤが未設定の段階では、機器ＩＤの代わりにリザーブ番号（例えば、オール０またはオール１）が設定される。

システム運用管理装置３００は受信した登録番号と機器ＩＤの結合データと、図示しない上述のデータベースをもとに、送信先の端末装置１０を特定する。その際、特定した端末装置１０が機器ネガリストに登録されている端末装置である場合、システム運用管理装置３００は、共通鍵テーブルの更新を許可しない。

特定した端末装置１０が機器ネガリストに登録されていない端末装置である場合、システム運用管理装置３００は、特定した端末装置１０の登録鍵または更新鍵を用いて、共通鍵テーブルの更新データを含むセキュリティ情報を暗号化して、端末装置１０に送信する。端末装置１０のセキュリティ処理部１５に機器ＩＤが設定されていない段階では登録鍵を用いる。機器ＩＤが設定された後は登録鍵を用いてもよいし更新鍵を用いてもよい。当該セキュリティ情報はペイロードの管理データではなく、アプリケーションデータに格納される。

端末装置１０のセキュリティ処理部１５は、当該セキュリティ情報を自身の登録鍵または更新鍵で復号し、ペイロードの確からしさをメッセージ認証コード（ＭＡＣ）を検証して判定する。端末装置１０はその復号および検証が成功したか否かをシステム運用管理装置３００に応答する。

図２０（ｂ）は第２の経路による更新手順を示す。端末装置１０を搭載した車両が専用路側機２０ａの近傍に位置するとき、端末装置１０と専用路側機２０ａとの間で路車間通信が実行される。この路車間通信では端末装置１０から専用路側機２０ａに機器ＩＤが送信される。したがって、システム運用管理装置３００は図２０（ａ）に示すようにＩＤ要求をしなくても、専用路側機２０ａを介して端末装置１０の機器ＩＤを取得できる。

システム運用管理装置３００は受信した機器ＩＤと、図示しない上述のデータベースをもとに、送信先の端末装置１０を特定する。その際、特定した端末装置１０が機器ネガリストに登録されている端末装置である場合、システム運用管理装置３００は、共通鍵テーブルの更新を許可しない。

特定した端末装置１０が機器ネガリストに登録されていない端末装置である場合、システム運用管理装置３００は、特定した端末装置１０の更新鍵を用いて、共通鍵テーブルの更新データを含むセキュリティ情報を暗号化して、端末装置１０に送信する。

端末装置１０のセキュリティ処理部１５は、当該セキュリティ情報が格納されたアプリケーションデータを受信処理部１６１に渡す。受信処理部１６１は、当該アプリケーションデータに格納されたセキュリティ情報に含まれるセキュリティモジュールの登録番号を参照して、当該端末装置１０宛のセキュリティ情報であるか否かを判定する。受信処理部１６１は当該端末装置１０宛のセキュリティ情報である場合、当該セキュリティ情報を制御部１９に渡す。当該端末装置１０宛のセキュリティ情報でない場合、当該セキュリティ情報を破棄する。

制御部１９は当該セキュリティ情報をセキュリティ処理部１５に渡す。セキュリティ処理部１５は、当該セキュリティ情報を自身の更新鍵で復号し、ペイロードの確からしさをメッセージ認証コード（ＭＡＣ）を検証して判定する。端末装置１０はその復号および検証が成功したか否かをシステム運用管理装置３００に応答する。

図２１は、変形例に係る共通鍵テーブルのフォーマットを示す。共通鍵テーブルの「Ｆｉｅｌｄ」には、「Ｖｅｒｓｉｏｎ」、「ＴａｂｌｅＩＤ」、「ＫｅｙｌｉｓｔｆｏｒＲＶＣ」、および「ＫｅｙｌｉｓｔｆｏｒＩＶＣ」が設けられる。「Ｖｅｒｓｉｏｎ」にはテーブルのバージョンがセットされる。「ＴａｂｌｅＩＤ」にはテーブル識別子がセットされる。データのＭＳＢ（ＭｏｓｔＳｉｇｎｉｆｉｃａｎｔＢｉｔ）からａ（ａは自然数）ビット分がテーブル識別子に設定される。

「ＫｅｙｌｉｓｔｆｏｒＲＶＣ」は「ｋｅｙ０」〜「ｋｅｙＰ（Ｐは自然数）」を含み、「ｋｅｙ０」〜「ｋｅｙＰ」にはそれぞれ路車間用鍵番号０の鍵（例えば、ＡＥＳ鍵）〜路車間用鍵番号Ｐの鍵がセットされる。「ＫｅｙｌｉｓｔｆｏｒＩＶＣ」は「ｋｅｙ０」〜「ｋｅｙＱ（Ｑは自然数）」を含み、「ｋｅｙ０」〜「ｋｅｙＱ」にはそれぞれ車車間用鍵番号０の鍵〜車車間用鍵番号Ｑの鍵がセットされる。この共通鍵テーブルは、路車間通信と車車間通信とでセキュリティレベルが異なる通信方式を採用することを前提とし、路車間用の鍵と車車間用の鍵を別々に設けている。セキュリティレベルは路車間通信のほうを車車間通信より高くする。たとえば、前者では鍵と乱数を組み合わせて使用して暗号化し、後者では鍵をそのまま使用して暗号化する。

図２２は、変形例に係るセキュリティフレームの第１のフォーマットを示す。第１のフォーマットは、共通鍵テーブルをセキュリティモジュールに書き込む際に使用されるフォーマットである。当該フォーマットには「Ｆｉｅｌｄｆｌａｇｓ」、「Ｌｉｃｅｎｓｅｄｎｕｍｂｅｒ」、「Ｎｏｎｃｅ」、「Ｌｅｎｇｔｈ」、「Ｐａｙｌｏａｄ」、および「ＭＡＣ」が含まれる。「Ｐａｙｌｏａｄ」には「Ｌｉｃｅｎｓｅｄｎｕｍｂｅｒ」、「ＤｅｖｉｃｅＩＤ」、「Ｋｅｙｔａｂｌｅｓ」、および「Ｓｙｍｍｅｔｒｉｃｋｅｙ」が含まれる。「Ｋｅｙｔａｂｌｅｓ」には「ＡｃｔｉｖｅｔａｂｌｅＩＤ」、「Ｎｕｍｂｅｒｏｆｋｅｙｔａｂｌｅｓ」、および「ｋｅｙｔａｂｌｅ１」〜「ｋｅｙｔａｂｌｅＬ」が含まれる。

「Ｆｉｅｌｄｆｌａｇｓ」には鍵・暗号フィールドの有無を示すフラグがセットされる。第１のフォーマットではこのフラグが有意にセットされる。セキュリティモジュールはこのフラグを参照して、セキュリティ情報内のデータ構造を認識する。「Ｌｉｃｅｎｓｅｄｎｕｍｂｅｒ」には書込対象のセキュリティモジュールの登録番号がセットされる。「Ｎｏｎｃｅ」には乱数がセットされる。「Ｌｅｎｇｔｈ」にはペイロードのデータ長がセットされる。「Ｐａｙｌｏａｄ」において「Ｌｉｃｅｎｓｅｄｎｕｍｂｅｒ」には書込対象のセキュリティモジュールの登録番号がセットされる。この「Ｌｉｃｅｎｓｅｄｎｕｍｂｅｒ」は暗号化されるため、「Ｐａｙｌｏａｄ」の外にも「Ｌｉｃｅｎｓｅｄｎｕｍｂｅｒ」が配置される。「ＤｅｖｉｃｅＩＤ」には車載器の機器ＩＤがセットされる。

「ＡｃｔｉｖｅｔａｂｌｅＩＤ」には送信用鍵テーブルのテーブルＩＤがセットされる。後述するように送信用鍵テーブルには複数の鍵テーブルのうちの一つが指定される。「Ｎｕｍｂｅｒｏｆｋｅｙｔａｂｌｅｓ」には当該セキュリティ情報に含まれる鍵テーブルの数（＝Ｌ（Ｌは自然数））がセットされる。「ｋｅｙｔａｂｌｅ１」〜「ｋｅｙｔａｂｌｅＬ」にはそれぞれ鍵テーブル１〜鍵テーブルＬがセットされる。各鍵テーブルのフォーマットは図２１に示したフォーマットを用いる。「Ｓｙｍｍｅｔｒｉｃｋｅｙ」には更新鍵がセットされる。「Ｐａｙｌｏａｄ」の秘匿および認証を行うために、「ＭＡＣ」には、登録鍵または更新鍵によって求められた「Ｐａｙｌｏａｄ」に対するＭＡＣ値がセットされ、「Ｐａｙｌｏａｄ」は、登録鍵または更新鍵によって暗号化される。尚、ここでは認証・暗号化アルゴリズムとしてＡＥＳ−ＣＣＭモードを採用しているため、「Ｎｏｎｃｅ」、「Ｌｅｎｇｔｈ」、ＭＡＣのバイト数、および「Ｐａｙｌｏａｄ」に対するＭＡＣ値が「ＭＡＣ」にセットされる。そして、「Ｐａｙｌｏａｄ」と「ＭＡＣ」が暗号化される。

図２３は、変形例に係るセキュリティフレームの第２のフォーマットを示す。第２のフォーマットは、セキュリティモジュールから機器ＩＤを読み出す際に使用されるフォーマットである。第２のフォーマットは、第１のフォーマットの「Ｐａｙｌｏａｄ」から「Ｋｅｙｔａｂｌｅｓ」、および「Ｓｙｍｍｅｔｒｉｃｋｅｙ」が除かれた構成である。第２のフォーマットでは「Ｆｉｅｌｄｆｌａｇｓ」のフラグが非有意にセットされる。それ以外のデータ構造は第１のフォーマットのデータ構造と同じであるため説明を割愛する。

図２４は、変形例に係る共通鍵テーブルの運用方法を説明するための図である。端末装置１０は、保持している複数の共通鍵テーブルを順次切り替えて使用する。以下、端末装置１０は八つの共通鍵テーブルを格納可能な記憶領域（以下、格納領域という）を有し、五つの共通鍵テーブルを保持する例を説明する。当該変形例では、一つの共通鍵テーブルに保持される鍵の数は八つである。なお、端末装置１０に保持される共通鍵テーブルの数および一つの共通鍵テーブルに保持される鍵の数は複数であればよく、前述の数に限定されない。共通鍵テーブルの格納領域の数は、端末装置１０に保持される共通鍵テーブルの数以上であればよい。すなわち、テーブルＩＤにより識別する数と共通鍵テーブルの格納領域の数は一致している必要はない。

共通鍵テーブルの管理はバージョン及びテーブルＩＤにより行われる。バージョンの異なる同じテーブルＩＤで特定される共通鍵テーブルが同時に使用されることはない。必ず、バージョンが新しい（ここでは、値が大きい）方が使用される。テーブルＩＤは０〜Ｎ（Ｎは自然数）として表される。すなわちＮの剰余系として設定される。本変形例ではＮ＝８である。たとえば、１番目の共通鍵テーブルと９番目の共通鍵テーブルのテーブルＩＤは０となる。バージョンは同じテーブルＩＤの新しい共通鍵テーブルが生成される度にカウントアップしていく。したがって、前者では０、後者では１となる。

格納領域に保持される複数の共通鍵テーブルのうち、一つが送信用の共通鍵テーブル（以下、送信用鍵テーブルという）に指定され、複数が受信用の共通鍵テーブル（以下、受信用鍵テーブルという）に指定される。複数の受信用鍵テーブルは送信用鍵テーブルを含み、送信用鍵テーブルよりｎ（ｎは自然数）世代未来までの共通鍵テーブルを含む。ｎ世代未来のテーブルＩＤは、｛（送信用鍵テーブルのテーブルＩＤ＋ｎ）ｍｏｄＮ｝で算出される。なお、複数の受信用鍵テーブルはｍ（ｍは０または自然数）世代過去までの共通鍵テーブルを含んでもよい。同様に、｛（送信用鍵テーブルのテーブルＩＤ−ｍ））ｍｏｄＮ｝で表される。図２４に示す例は、ｎ＝ｍ＝１の場合で、テーブルＩＤ＝１の共通鍵テーブルが送信用鍵テーブルに指定され、テーブルＩＤ＝０、テーブルＩＤ＝１、テーブルＩＤ＝２の三つの共通鍵テーブルが受信用鍵テーブルに指定されている。テーブルＩＤ＝０の共通鍵テーブルが送信用鍵テーブルに指定される場合、テーブルＩＤ＝８、テーブルＩＤ＝０、テーブルＩＤ＝１の三つの共通鍵テーブルが受信用鍵テーブルに指定される。この時、テーブルＩＤ＝１の共通鍵テーブルのバージョンは、テーブルＩＤ＝０の共通鍵テーブルのバージョンと同じか、大きい、すなわち、同世代か、未来の世代のバージョンである。テーブルＩＤ＝８の共通鍵テーブルのバージョンは、必ず、テーブルＩＤ＝０の共通鍵テーブルのバージョンより１小さい、すなわち、１世代前のバージョンである。また、テーブルＩＤ＝８の共通鍵テーブルが送信用鍵テーブルに指定される場合、テーブルＩＤ＝７、テーブルＩＤ＝８、テーブルＩＤ＝０の三つの共通鍵テーブルが受信用鍵テーブルに指定される。この時、テーブルＩＤ＝７の共通鍵テーブルのバージョンは、テーブルＩＤ＝８の共通鍵テーブルのバージョンと同じか、１小さい、すなわち、同世代か、１世代前のバージョンである。テーブルＩＤ＝０の共通鍵テーブルのバージョンは、テーブルＩＤ＝８の共通鍵テーブルのバージョンより大きい、すなわち、未来の世代である。

システム運用管理装置３００が送信用鍵テーブルの切替を指示しても、全ての端末装置１０において送信用鍵テーブルが同時に切り替わるわけではない。端末装置１０間において送信用鍵テーブルが切り替わるタイミングに時間差が生じる。たとえば、長期間使用されていない車両１００に搭載された端末装置１０では、二つ以上過去の共通鍵テーブルが送信用鍵テーブルに設定されている可能性もある。この車両１００が使用されると別の車両１００に搭載された端末装置１０は、二世代過去の共通鍵テーブルで処理されたパケット信号を受信する。暗号化システムの運用上、受信用鍵テーブルの範囲が狭いほどセキュリティが高くなるが、正当な端末装置１０からの送信データを復号できないケースが多くなる。両者の要請を考慮して受信用鍵テーブルの範囲は設定される。

送信用鍵テーブルの切替周期が長い場合（たとえば、数年）、受信用鍵テーブルは、送信用鍵テーブルと次の共通鍵テーブル（ｎ＝１）で構成されるとよい。また、送信用鍵テーブルの切替周期が短い場合（たとえば、一年以内）、受信用鍵テーブルは、送信用鍵テーブルと、次の共通鍵テーブル（ｎ＝１）と、さらにそれ以降の共通鍵テーブル（ｎ＞１）とで構成されるとよい。切替期間が短いほどｎを大きくし、多くの共通鍵テーブルを受信用鍵テーブルに組み入れるとよい。切替期間が短い場合、複数の端末装置１０間で送信用鍵テーブルのばらつきが大きくなる。これに対し、受信用鍵テーブルに組み入れる共通鍵テーブルの数を増やすことにより、送信用鍵テーブルのミスマッチを減らすことができる。また、ｍは１または０が適当である。

複数の共通鍵テーブルは暗号化されて記憶部１８に保持される。図２４に示す例では五つの共通鍵テーブルが保持される。端末装置１０が起動する際、セキュリティ処理部１５は記憶部１８に保持された暗号化された共通鍵テーブルを読み出す。セキュリティ処理部１５は暗号化された共通鍵テーブルを復号して、図示しないＲＡＭで構成されるワークエリアに格納する。このワークエリアに保持される共通鍵テーブルは、送信用鍵テーブルおよび受信用鍵テーブルに指定された共通鍵テーブルである。図２４に示す例ではテーブルＩＤ＝０、テーブルＩＤ＝１、テーブルＩＤ＝２の三つの共通鍵テーブルがワークエリアに保持される。

端末装置１０が起動する際、セキュリティ処理部１５は共通鍵テーブルを記憶部１８から読み出すとともに、鍵ネガマップを生成する。この鍵ネガマップには送信用鍵テーブルおよび受信用鍵テーブルに指定された共通鍵テーブル以外の共通鍵テーブルに格納された鍵が登録される。たとえば、鍵ネガマップはビットマップ形式で生成される。セキュリティ処理部１５は、生成した鍵ネガマップもワークエリアに格納する。セキュリティ処理部１５は路車間通信または車車間通信でメッセージを受信する際、鍵ネガマップを参照して使用不可の鍵が使用されているか否か判定する。鍵ネガマップに登録されている鍵が使用されている場合、エラーと判定する。なお、端末装置１０からのメッセージの送信時には、セキュリティ処理部１５は送信用鍵テーブルに含まれるいずれかの鍵を使用するため、使用する鍵が鍵ネガマップに登録されているか否かを判定する必要はない。

以上説明したように本変形例によれば、セキュリティモジュールの登録鍵または更新鍵で更新用の共通鍵テーブルを暗号化して車載器に伝達することにより、共通鍵テーブルの更新処理を簡便化することができる。また、更新用の共通鍵テーブルをペイロードの管理データではなく、アプリケーションデータに格納することにより、柔軟性および拡張性に優れた更新システムを構築できる。

図２５は、図２２のセキュリティフレームの第１のフォーマットの変形例を示す図である。図２２の「Ｐａｙｌｏａｄ」の最後に「Ｓiｇｎａｔｕｒｅ」を加えた。「Ｓｉｇｎａｔｕｒｅ」には本フィールドを除くペイロードに対する署名がセットされる。セキュリティモジュールは、本セキュリティフレームを受け取ると、復号、ＭＡＣ認証後、署名検証を行う。署名検証を行うための認証鍵は事前にセキュリティモジュールに格納しておく。署名検証によって、共通鍵テーブルが正規の提供元から提供物されたことが確認できるようになり、システム全体のセキュリティを高めることができる。なお、図２５のセキュリティフレームにおいても、図２３のセキュリティフレームはそのまま使用する。

なお図１３、図１４に示した実施例に係る共通鍵テーブルの更新において、更新マスタ鍵の代わりに変形例に係る登録鍵または更新鍵を使用してもよい。即ち、共通鍵テーブルと別に送信されるテーブル更新鍵の暗号化および復号に登録鍵または更新鍵を使用する。登録鍵または更新鍵は端末装置ごとに異なるため、全ての端末装置で共通な更新マスタ鍵を使用する場合よりセキュリティを高めることができる。

１０端末装置、１１アンテナ、１２ＲＦ部、１３変復調部、１４ＭＡＣフレーム処理部、１１４無線部、１５セキュリティ処理部、１５１暗復号部、１５２復号部、１６１受信処理部、１６２通知部、１７データ生成部、１８記憶部、１９制御部、１９１外部端子、２０基地局装置、２１アンテナ、２２ＲＦ部、２３変復調部、２４ＭＡＣフレーム処理部、２５セキュリティ処理部、２６データ生成部、２５１暗復号部、２５２暗号部、２７ネットワーク通信部、２８記憶部、２９制御部、１００車両、２０２エリア、２０４エリア外、５００通信システム、３００システム運用管理装置、４００路車間サービス事業者端末装置。

本発明は、暗号鍵テーブルの更新処理の安全性を高める技術を提供する。

Claims

路側機からメッセージを含むパケット信号をブロードキャスト送信する路車間通信、および車載器からメッセージを含むパケット信号をブロードキャスト送信する車車間通信を用いる通信システム内における車載器であって、
前記通信システム内における路側機および他の車載器との通信に使用可能な複数の共通鍵を含む共通鍵テーブルを暗号化して記憶する記憶部と、
本車載器が起動する際に、前記記憶部から暗号化された共通鍵テーブルを復号して格納するワークエリア部と、
前記ワークエリア部に格納されている共通鍵テーブルから共通鍵を読み出して、メッセージの暗号処理または復号処理を行う処理部と、を備え、
前記処理部は、前記記憶部の複数の格納領域に記憶された複数の共通鍵テーブルのうち、指定された送信用の共通鍵テーブルと受信用の共通鍵テーブルを読み出して前記ワークエリア部に格納し、
各共通鍵テーブルには、路車間通信で用いる複数の共通鍵と、車車間通信で用いる複数の共通鍵とが別々にセットされていることを特徴とする車載器。
前記処理部は、読み出した前記共通鍵を用いて、メッセージを復号した後、メッセージに含まれるメッセージ認証コードを検証することを特徴とする請求項１に記載の車載器。
前記処理部は、路車間通信のメッセージの場合、路車間通信で用いる共通鍵と乱数の組み合わせを使用して暗号化し、車車間通信のメッセージの場合、車車間通信で用いる共通鍵をそのまま使用して暗号化することを特徴とする請求項１または２に記載の車載器。
前記処理部は、前記記憶部の複数の格納領域に記憶された複数の共通鍵テーブルのうち、システム運用管理装置から指定された送信用の共通鍵テーブルと、当該送信用の共通鍵テーブルを含む複数の受信用の共通鍵テーブルを読み出して前記ワークエリア部に格納することを特徴とする請求項１から３のいずれかに記載の車載器。