JP6273561B2 - 端末装置 - Google Patents

Description

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

交差点の出会い頭の衝突事故を防止するために、路車間通信の検討がなされている。路車間通信では、路側機と車載器との間において交差点の状況に関する情報が通信される。路車間通信では、路側機の設置が必要になり、手間と費用が大きくなる。これに対して、車車間通信、つまり車載器間で情報を通信する形態であれば、路側機の設置が不要になる。その場合、例えば、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）等によって現在の位置情報をリアルタイムに検出し、その位置情報を車載器同士で交換しあうことによって、自車両および他車両がそれぞれ交差点へ進入するどの道路に位置するかを判断する（例えば、特許文献１参照）。

無線通信は、有線通信に比較して通信の傍受が容易になるので、通信内容の秘匿性を確保することが困難になる。また、ネットワーク経由で機器の制御を行う場合、第三者のなりすましにより不正な通信による操作が行われるおそれがある。無線通信において、通信内容の秘匿性を確保するためには、通信データを暗号化し、かつ、暗号化の際に使用する鍵を定期的に更新する必要がある。例えば、ネットワーク装置のそれぞれは、暗号鍵の
更新の際、更新前に使用されている旧暗号鍵によって暗号化が行われたデータのみの送受信が可能な初期状態にある。この状態から、各装置は、旧暗号鍵および更新後の新暗号鍵によって暗号化が行われた双方のデータの送受信を行うことが可能で、新暗号鍵によって暗号化が行われたデータの送受信に関しては動作未確認の状態に移行する。さらに、各装置は、旧暗号鍵、新暗号鍵の双方で暗号化されたデータの送受信が可能であり、新暗号鍵で暗号化されたデータの送受信に関しても動作確認済みの状態に遷移する。最終的に、各装置は、鍵更新完了後の新暗号鍵によって暗号化されたデータのみの送受信が可能な状態に順次遷移する（例えば、特許文献２参照）。

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

ＩＥＥＥ８０２．１１等の規格に準拠した無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）では、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ ｗｉｔｈ Ｃｏｌｌｉｓｉｏｎ Ａｖｏｉｄａｎｃｅ）とよばれるアクセス制御機能が使用されている。そのため、当該無線ＬＡＮでは、複数の端末装置によって同一の無線チャネルが共有される。このようなＣＳＭＡ／ＣＡでは、端末装置間の距離や電波を減衰させる障害物の影響などによって、互いの無線信号が到達しない状況、つまりキャリア・センスが機能しない状況が発生する。キャリア・センスが機能しない場合、複数の端末装置から送信されたパケット信号が衝突する。

一方、無線ＬＡＮを車車間通信に適用する場合、不特定多数の端末装置へ情報を送信する必要があるために、信号はブロードキャストにて送信されることが望ましい。しかしながら、交差点などでは、車両数の増加、つまり端末装置数の増加がトラヒックを増加させることによって、パケット信号の衝突の増加が想定される。その結果、パケット信号に含まれたデータが他の端末装置へ伝送されなくなる。このような状態が、車車間通信において発生すれば、交差点の出会い頭の衝突事故を防止するという目的が達成されなくなる。さらに、車車間通信に加えて路車間通信が実行されれば、通信形態が多様になる。その際、車車間通信と路車間通信との間における相互の影響の低減が要求される。

また、暗号化のための鍵を更新する場合、これまではユニキャスト通信を前提としていたので、複数の状態を遷移させることが容易であった。ブロードキャスト通信を使用する場合、異なった状態の端末装置が存在すれば、共通した暗号鍵の使用が困難になる。通信の安全性を確保するために、暗号鍵の更新が望まれる。ここで、悪意あるユーザが多く存在する可能性が高いエリアでは、低いエリアよりも暗号鍵の更新周期を短くする必要がある。すべてのエリアにおいて暗号鍵の更新周期を短くすればよいが、新たな暗号鍵の配布のためにトラヒックが増加してしまう。一方、周波数利用効率の悪化を抑制することも要求される。

本発明はこうした状況に鑑みてなされたものであり、その目的は、エリアに応じて暗号鍵を効率的に配布する技術を提供することにある。

上記課題を解決するために、本発明のある態様の端末装置は、車両に搭載され、基地局装置との間での通信を行う端末装置であって、端末装置間の通信を制御する基地局装置から報知されたパケット信号であって、かつ共通鍵が複数種類示された第１の共通鍵テーブルを記憶するとともに、第１の共通鍵テーブルとは異なった第２の共通鍵テーブルを記憶した基地局装置において、記憶した第２の共通鍵テーブルに含まれた共通鍵を使用して生成されたパケット信号を受信する受信部と、基地局装置との間で共有される第２の共通鍵テーブルを記憶する記憶部と、受信部が受信したパケット信号を検証する検証部とを備える。受信部において受信したパケット信号の報知元になる基地局装置は、記憶した第１の共通鍵テーブルが格納されたパケット信号も生成しており、検証部は、受信部が受信したパケット信号に第１の共通鍵テーブルが含まれる場合、第１の共通鍵テーブルが本端末装置の記憶部に未記録であれば、当該第１の共通鍵テーブルを記憶部に記憶する。

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

本発明によれば、エリアに応じて暗号鍵を切り換えて使用することができるようになり、通信システムにおける鍵漏洩のリスクを低減することができる。

本発明の実施例に係る通信システムの構成を示す図である。 図１の基地局装置の構成を示す図である。 図１の通信システムにおいて規定されるパケット信号に格納されるＭＡＣフレームのフォーマットを示す図である。 図１の通信システムにおいて規定されるＭＡＣフレームに格納されるセキュアフレームのフォーマットを示す図である。 図２の記憶部に記憶される共通鍵テーブルのデータ構造を示す図である。 図１の通信システムにおける基地局装置の配置を示す図である。 図１の車両に搭載された端末装置の構成を示す図である。 図２の基地局装置におけるパケット信号の送信手順を示すフローチャートである。 図２の基地局装置におけるパケット信号の受信手順を示すフローチャートである。 図７の端末装置におけるパケット信号の受信手順を示すフローチャートである。 図７の端末装置におけるパケット信号の送信手順を示すフローチャートである。 本発明の変形例に係る通信システムにおいて規定されるＭＡＣフレームに格納されるセキュリティフレームのフォーマットを示す図である。 図１３（ａ）−（ｂ）は、図１２のセキュリティフレームに対する処理内容を示す図である。 図２の記憶部に記憶される共通鍵テーブルのデータ構造を示す図である。 図１の車両に搭載された端末装置の構成を示す図である。 図１６（ａ）−（ｃ）は、図１５の生成部による共通鍵テーブルの更新の概要を示す図である。 図１５の端末装置における共通鍵テーブルのメンテナンス手順を示すフローチャートである。 図１５の端末装置におけるパケット信号の受信手順を示すフローチャートである。 図１５の端末装置におけるパケット信号の送信手順を示すフローチャートである。

本発明を具体的に説明する前に、概要を述べる。本発明の実施例は、車両に搭載された端末装置間において車車間通信を実行するとともに、交差点等に設置された基地局装置から端末装置へ路車間通信も実行する通信システムに関する。車車間通信として、端末装置は、車両の速度や位置等の自車両情報を格納したパケット信号をブロードキャスト送信する（以下、ブロードキャストによりパケット信号の送信を「報知」という）。また、他の端末装置は、パケット信号を受信するとともに、データをもとに車両の接近等を認識する。また、路車間通信として、基地局装置は、交差点情報、渋滞情報、および、セキュリティ情報等が格納されたパケット信号を報知する。以下、説明を簡単にするために、車車間通信および路車間通信のパケット信号に含まれる情報の総称を「データ」という。

交差点情報には、交差点の位置、基地局装置が設置された交差点の撮影画像や、交差点内の車両の位置情報等の交差点の状況に関する情報が含まれる。端末装置は、この交差点情報をモニタに表示し、この交差点情報をもとに交差点車両の状況を認識して、出会い頭・右折・左折による衝突防止を目的とした他の車両や歩行者の存在等をユーザに伝達し、事故の防止を図る。また、渋滞情報には、基地局装置が設置された交差点近辺の走路の混雑状況、道路工事や事故に関する情報が含まれる。この情報を元に進行方向の渋滞をユーザに伝達し、あるいは、迂回路を提示する。セキュリティ情報では、共通鍵テーブルの提供等のデータを保護に関する情報が含まれる。詳細については、後述する。

また、このような通信においてなりすまし等を抑制するために、電子署名が使用される。電子署名を生成するためには、暗号鍵が使用される。本実施例に係る通信システムでは、処理の負荷を考慮し、暗号鍵として共通鍵を使用する。また、共通鍵の漏洩リスクを低減去るために複数の共通鍵を使用する。ひとつの共通鍵をひとつの共通鍵ＩＤとして管理し、複数の共通鍵を共通鍵テーブルにまとめる。また、共通鍵テーブルには、共通鍵テーブルＩＤが付与されることによって、複数種類の共通鍵テーブルが規定される。通信システムにおいて、使用可能なエリアが制限されている、すなわち、予め定められた所定のエリアのみで使用される第１の共通テーブル群と、使用可能なエリアの制限がない、すなわち、所定のエリア外で使用される第２の共通エリア群に分けられる。ここで、第１の共通鍵テーブル群は、使用可能なエリア内の基地局装置、あるいは、使用可能なエリアの周囲の基地局装置から報知されている。端末装置は、第１の共通鍵テーブル群に属する共通鍵テーブルを受信すると、それを内部に保持していない場合、内部に記録する。一方、第２の共通鍵テーブル群に属する共通鍵テーブルは、端末装置に予め記憶されている。

図１は、本発明の実施例に係る通信システム１００の構成を示す。これは、ひとつの交差点を上方から見た場合に相当する。通信システム１００は、基地局装置１０、車両１２と総称される第１車両１２ａ、第２車両１２ｂ、第３車両１２ｃ、第４車両１２ｄ、第５車両１２ｅ、第６車両１２ｆ、第７車両１２ｇ、第８車両１２ｈ、ネットワーク２０２を含む。なお、各車両１２には、図示しない端末装置が搭載されている。

図示のごとく、図面の水平方向、つまり左右の方向に向かう道路と、図面の垂直方向、つまり上下の方向に向かう道路とが中心部分で交差している。ここで、図面の上側が方角の「北」に相当し、左側が方角の「西」に相当し、下側が方角の「南」に相当し、右側が方角の「東」に相当する。また、ふたつの道路の交差部分が「交差点」である。第１車両１２ａ、第２車両１２ｂが、左から右へ向かって進んでおり、第３車両１２ｃ、第４車両１２ｄが、右から左へ向かって進んでいる。また、第５車両１２ｅ、第６車両１２ｆが、上から下へ向かって進んでおり、第７車両１２ｇ、第８車両１２ｈが、下から上へ向かって進んでいる。

ここで、通信システム１００では、通信においてなりすまし等を抑制するために、電子署名が添付されたパケット信号が報知される。電子署名とは、パケット信号に含まれたデータ等の電磁的記録に付与すべき電子的な署名である。これは、紙文書における印や署名に相当し、主に本人確認、偽造・かいざんの防止のために使用される。具体的に説明すると、ある文書についてその作成者として文書に記載されている者がある場合、その文書が本当にその作成名義人によって作成されたものであることは、紙の文書の場合、その文書に付されたその作成者の署名や印によって証明される。しかしながら、電子文書には直接印を押したり署名を付したりすることはできないので、これを証明するために、電子署名が使用される。電子署名を生成するためには、暗号が使用される。

電子署名として、公開鍵暗号方式に基づくデジタル署名が有力である。電子署名方式は、鍵生成アルゴリズム、署名アルゴリズム、検証アルゴリズムによって構成される。鍵生成アルゴリズムは電子署名の事前準備に相当する。鍵生成アルゴリズムは、ユーザの公開鍵および秘密鍵を出力する。鍵生成アルゴリズムが実行される度に異なる乱数が選ばれるので、ユーザごとに異なる公開鍵・秘密鍵ペアが割り振られる。各ユーザは、秘密鍵を保管し、公開鍵を公開する。

署名を作成したユーザは、その署名文に対する署名者とよばれる。署名者は、署名アルゴリズムによって署名文を作成する際、メッセージとともに自分の秘密鍵を入力する。署名者の秘密鍵を知っているのは署名者本人だけのはずなので、電子署名を付した電子文書の作成者を識別する根拠になる。メッセージと署名文を受け取ったユーザである検証者は、検証アルゴリズムを実行することによって、署名文が正しいか否かを検証する。その際、検証者は検証アルゴリズムに署名者の公開鍵を入力する。検証アルゴリズムは署名文が本当にそのユーザによって作成されたか否かを判定し、その結果を出力する。

このような公開鍵暗号方式の処理負荷は、一般的に大きい。例えば、交差点近傍では、例えば、１００ｍｓｅｃの間に５００台の端末装置１４からのパケット信号を処理しなければならなくなる。また、通信システム１００において車両１２に搭載された端末装置から報知されるパケット信号には、１００バイト程度のデータが格納される。これに対して、公開鍵暗号方式の公開鍵証明書と電子署名は、２００バイト程度になってしまい、伝送効率の低下が大きくなってしまう。また、公開鍵方式における電子署名の検証の演算処理は大きく、１００ｍｓｅｃの間に５００台の端末装置１４からのパケット信号を処理しようとすると、高機能の暗号演算装置あるいはコントローラを必要になってしまい、端末装置のコストが増加する。公開鍵暗号方式に基づく電子署名方式として、ＲＳＡ、ＤＳＡ、ＥＣＤＳＡ等が使用される。

これに対して、共通鍵暗号方式を用いた電子署名がある。共通鍵暗号方式では、暗号化に用いる鍵と同一、または暗号化鍵から容易に導出可能な値が復号鍵として使用される。受信側の端末装置にとって復号鍵が既知であり、鍵の証明書が不要になるので、公開鍵暗号方式と比較して伝送効率の悪化が抑制される。電子署名方式としてＣＢＣ−ＭＡＣがある。また、共通鍵暗号方式は、公開鍵暗号方式と比較して処理量が少ない。代表的な共通鍵暗号は、ＤＥＳ、ＡＥＳである。通信システム１００では、伝送負荷および処理負荷を考慮し、暗号方式として共通鍵暗号方式を採用する。

なお、通信システム１００で使用される共通鍵が１種類だけであれば、悪意あるユーザであっても、共通鍵の入手が容易になる。これに対応するため、通信システム１００では、複数の共通鍵を予め規定しており、各共通鍵は共通鍵ＩＤにて管理されている。また、複数の共通鍵が共通鍵テーブルにまとめられている。さらに、共通鍵テーブルは共通鍵テーブルＩＤにて管理されており、共通鍵テーブルＩＤを増加させることによって、複数の共通鍵テーブルが規定される。以下では、説明を明瞭にするために、端末装置１４は、第１の共通鍵テーブル群に含まれる第１の共通鍵テーブルと第２の共通鍵テーブル群に含まれる第２の共通鍵テーブルのふたつの共有鍵テーブルを使用するものとする。また、第１の共通鍵テーブルが使用できる所定のエリアは、基地局装置１０のキャリア信号を受信可能な範囲として規定されものとする。

第１の共通鍵テーブルは、予め選択された基地局装置１０が割当てられていて、割り当てられた基地局装置１０の周囲で使用可能であり、第２の共通鍵テーブルは、基地局装置１０の割当てがない共通鍵テーブルであって、第１の共通鍵テーブルを使用しないエリアで使用される。このように、第１の共通鍵テーブルを使用可能なエリアが制限されているので、端末装置１４は、第１の共通鍵テーブルを常に保持している必要がなく、使用可能なエリアの内、あるいは、使用可能なエリアの周辺の基地局装置１０から送信によって端末装置１４に提供される。第２の共通鍵テーブルは、エリアに関係なく使用されるので、端末装置１４は、第２の共通鍵テーブルを常に保持している。

図２は、基地局装置１０の構成を示す。基地局装置１０は、アンテナ２０、ＲＦ部２２、変復調部２４、ＭＡＣフレーム処理部２６、検証部４０、処理部２８、制御部３０、ネットワーク通信部３２、センサ通信部３４を含む。また、検証部４０は、暗号部４２と記憶部４４を含む。ＲＦ部２２は、受信処理として、図示しない端末装置や他の基地局装置１０からのパケット信号をアンテナ２０にて受信する。ＲＦ部２２は、受信した無線周波数のパケット信号に対して周波数変換を実行し、ベースバンドのパケット信号を生成する。さらに、ＲＦ部２２は、ベースバンドのパケット信号を変復調部２４に出力する。一般的に、ベースバンドのパケット信号は、同相成分と直交成分によって形成されるので、ふたつの信号線が示されるべきであるが、ここでは、図を明瞭にするためにひとつの信号線だけを示すものとする。ＲＦ部２２には、ＬＮＡ（Ｌｏｗ Ｎｏｉｓｅ Ａｍｐｌｉｆｉｅｒ）、ミキサ、ＡＧＣ、Ａ／Ｄ変換部も含まれる。

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

変復調部２４は、受信処理として、ＲＦ部２２からのベースバンドのパケット信号に対して、復調を実行する。さらに、変復調部２４は、復調した結果から、ＭＡＣフレームを取り出し、ＭＡＣフレーム処理部２６に出力する。また、変復調部２４は、送信処理として、ＭＡＣフレーム処理部２６からのＭＡＣフレームに対して、変調を実行する。さらに、変復調部２４は、変調した結果をベースバンドのパケット信号としてＲＦ部２２に出力する。ここで、通信システム１００は、ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）変調方式に対応するので、変復調部２４は、受信処理としてＦＦＴ（Ｆａｓｔ Ｆｏｕｒｉｅｒ Ｔｒａｎｓｆｏｒｍ）も実行し、送信処理としてＩＦＦＴ（Ｉｎｖｅｒｓｅ Ｆａｓｔ Ｆｏｕｒｉｅｒ Ｔｒａｎｓｆｏｒｍ）も実行する。

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

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

図４は、通信システム１００において規定されるセキュアフレームのフォーマットを示す。セキュアフレームは、「ペイロードヘッダ」、「ペイロード」、「署名」が配置される。さらに、ペイロードヘッダには、「メッセージバーション」、「メッセージタイプ」、「鍵ＩＤ」、「発信元種別」、「発信元ＩＤ」、「発信日時」および「ロケーション」が配置される。

メッセージバージョンは、セキュアフレームのフォーマットと規定する識別情報である。通信システム１００においては固定値となる。メッセージタイプは、ペイロードに対する暗号処理を規定する情報である。ここでは、平文データ（＝０）、署名付きデータ（＝１）、暗号化データ（＝２）を設定するものとする。鍵ＩＤは、電子署名あるいはペイロードの暗号化に使用した共通鍵を特定する識別情報で、共通鍵テーブルＩＤと共通鍵ＩＤを連結したものである。発信元種別ＩＤは、パケット信号の発信者の種類、すなわち、基地局装置１０（＝３）、救急車や消防車のような緊急車両（優先車両と呼ぶ）に搭載の端末装置（＝２）、その他の車両（一般車両とよぶ）に搭載の端末装置（＝１）および非車両搭載の端末装置（＝０）が設定するものとする。発信元ＩＤは、パケット信号を発信した基地局装置１０あるいは端末装置１４を、一意に特定できる装置ごとにユニークか識別情報である。発信元が基地局の場合、後述する基地局ＩＤが納められる。

ペイロードは、前述のデータを格納するフィールドであり、交差点情報や道路情報等の端末装置へ通知すべき情報に相当する。また、メッセージタイプが署名付きデータ（＝１）の時、ペイロードヘッダおよびペイロードに対する電子署名を格納するフィールドである。また、メッセージタイプが暗号化データ（＝１２）の時、無効としてもよいが、ここでは固定値、ペイロードヘッダの部分の写しなどの受信側特定可能な値、あるいは、ペイロードヘッダまたは／および暗号化前のペイロードに対するハッシュ値（ハッシュ関数による演算結果）、チェックサム、パリティなどの受信側で演算可能な値を格納するものとする。そして、ペイロードおよび署名をまとめて暗号化する。このようにすることで、復号によって得られた署名に格納された値と、受信側で特定した、あるいは、演算した値とが一致すれば、復号が正常の行われ、ペイロードに格納されているデータ、あるいはペイロードヘッダとペイロードに格納されているデータの正当性が確認できる。

各フィード長さは、例えば、ペイロードヘッダが３２バイト、ペイロードが１００バイト（端末装置が報知する場合）あるいは１Ｋバイト（基地局装置が報知する場合）。署名が１６バイト。通信システム１００では、暗号方式としてＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）暗号を使用する。そして、メッセージタイプが署名付きデータの場合には、電子署名は、ＣＢＣ−ＭＡＣ（Ｃｉｐｈｅｒ Ｂｌｏｃｋ Ｃｈａｉｎｉｎｇ−Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）によって求めたＭＡＣ値を署名に格納する。メッセージタイプが暗号化データの場合には、ペイロードヘッダに対するＭＡＣ値を署名に格納し、ペイロードおよび署名を、ＣＢＣ（Ｃｉｐｈｅｒ Ｂｌｏｃｋ Ｃｈａｉｎｉｎｇ）モードで暗号化する。図２に戻る。

検証部４０は、受信処理として、ＭＡＣフレーム処理部２６からのセキュアフレームを解釈し、データを処理部２８に出力する。また、検証部４０は、送信処理として、処理部２８からのデータを受け取り、セキュアフレームを生成し、ＭＡＣフレーム処理部２６に出力する。通信システム１００では、共通鍵暗号方式を使用しているため、暗号部４２は、共通鍵方式による暗号・復号処理を行う。具体的には、メッセージデータタイプが署名付きデータの場合、署名の作成を、メッセージデータタイプが暗号化データの場合、セキュアフレーム作成時に暗号処理を、セキュアフレーム解釈時には、データの復号処理を行う。

記憶部４４は、通信システム１００に使用可能な共通鍵が複数種類示された共通鍵テーブルを記憶する。前述のごとく、複数の共通鍵テーブルが規定されており、ここでは、それらを第１の共通鍵テーブルと第２の共通鍵テーブルとする。第１の共通鍵テーブルでは、制限されたエリアにおける通信に使用可能な複数の共通鍵が含まれている。第２の共通鍵テーブルでは、エリアに関係なく使用可能な複数の共通鍵が含まれている。これは、第１の共通鍵テーブルを使用可能でないエリアにおいて使用可能な複数の共通鍵が含まれているともいる。

図５は、記憶部４４に記憶される共通鍵テーブルのデータ構造を示す。第１の共通鍵テーブルおよび第２の共通鍵テーブルには、共通鍵テーブルＩＤが付与されている。図５において、第１テーブルは、共通鍵テーブルＩＤが「１２８」、第２テーブルは、共通鍵テーブルＩＤが「２」である。各共通鍵テーブルには、複数の共通鍵が含まれており、各共通鍵は共通鍵ＩＤで管理されている。図５において、共通鍵テーブルは、それぞれＮ個の共通鍵を含む。第１共通鍵は、共通鍵ＩＤが「１」である場合に相当し、第２共通鍵は、共通鍵ＩＤが「２」である場合に相当する。そのため、ひとつの共通鍵は、共通鍵テーブルＩＤと共通鍵ＩＤとの組合せによって特定される。また、第１の共通鍵テーブルには、制限されたエリアを示す、Ｍ（Ｍ≧１）個の基地局ＩＤが含まれている。第１の共通テーブルは、第１から第Ｍ基地局ＩＤにて特定される基地局装置１０からのキャリア信号を受信可能なエリアにおいて優先的に選択される。なお、キャリア信号を発信した基地局装置の特定は、セキュアフレームの発信元ＩＤに格納されている基地局ＩＤによって行うことができる。図２に戻る。

ここで、第１の共通鍵テーブルを使用可能なエリアについて説明する。説明を簡単にするために、第１の共通鍵テーブルには、基地局ＩＤが１つのみ含まれているものとする。図６は、通信システム１００における基地局装置１０の配置を示す。説明を簡易にするために、５つの基地局装置１０、つまり第１基地局装置１０ａ、第２基地局装置１０ｂ、第３基地局装置１０ｃ、第４基地局装置１０ｄ、第５基地局装置１０ｅが一元的に一列に並んで配置されている場合を想定する。各基地局装置１０の周りに示されている円は、各基地局のキャリア信号を受信可能なエリアに相当する。ここでは、第３基地局装置１０ｃが、前述の選択した基地局装置１０に相当し、第１の共通鍵テーブルには、第３基地局装置１０ｃの基地局ＩＤが含まれている。そのため、第３基地局装置１０ｃにて形成されたエリア内に進入し、第３基地局装置１０ｃからのパケット信号を受信した端末装置は、パケット信号の報知の際に、第１の共通鍵テーブルを使用する。

一方、第３基地局装置１０ｃにて形成されたエリアから出たことによって、第３基地局装置１０ｃからのパケット信号を一定期間受信しなくなった、あるいは、他の基地局装置からのキャリア信号を受信した端末装置は、パケット信号の報知の際に、第２の共通鍵テーブルを使用する。図６において第１基地局装置１０ａにて形成されたエリア、第２基地局装置１０ｂにて形成されたエリア、第４基地局装置１０ｄにて形成されたエリア、第５基地局装置１０ｅにて形成されたエリア内に存在する、あるいは、いずれのエリアにも存在しない端末装置は、パケット信号の報知の際に、第２の共通鍵テーブルを使用する。詳細は後述するが、端末装置は、第３基地局装置１０ｃからのパケット信号を受信している場合に、第１の共通鍵テーブルを使用し、第３基地局装置１０ｃからのパケット信号を受信していない場合に、第２の共通鍵テーブルを使用する。図２に戻る。

検証部４０は、セキュアフレームを生成する際、記憶部４４を参照して、共通鍵を抽出する。例えば、本基地局装置１０が、図６の第３基地局装置１０ｃに相当する場合、検証部４０は、第１の共通鍵テーブルの中から、ひとつの共通鍵をランダムに選択する。また、本基地局装置１０が、図６の第１基地局装置１０ａ、第２基地局装置１０ｂ、第４基地局装置１０ｄ、第５基地局装置１０ｅに相当する場合、検証部４０は、第２の共通鍵テーブルの中から、ひとつの共通鍵をランダムに選択する。検証部４０は、メッセージタイプが署名付きデータの場合には、選択した共通鍵を使用して暗号部４２にてペイロードヘッダとペイロードに対する電子署名を演算する。また、メッセージタイプが暗号化データの場合には、暗号部４２にてペイロードと署名を暗号化する。検証部４０は、メッセージタイプが平文データの場合には、生成したセキュアフレームを、そのままＭＡＣフレーム処理部２６へ出力する。

検証部４０は、セキュアフレームを解釈する際、ＭＡＣフレーム処理部２６から受け取ったセキュアフレームの鍵ＩＤを参照し、使用する共通鍵の鍵テーブルＩＤと共通鍵ＩＤを得る。次いで、記憶部４４を参照して、この鍵テーブルＩＤと共通鍵ＩＤにて特定される共通鍵を抽出する。さらに、検証部４０は、抽出した共通鍵を使用して、ＭＡＣフレーム処理部２６から受け取ったセキュアフレームのメッセージタイプが署名付きデータの場合には、署名の正当性を検証する。詳細には、暗号部４２にてペイロードヘッダとペイロードに対する電子署名を演算し、求めた値と、ＭＡＣフレーム処理部２６から受け取ったセキュアフレームの署名に格納された電子署名の値と比較する。２つの電子署名の値が一致すれば、電子署名が正当であり、このセキュアフレームに含まれる情報が正規の基地局装置１０、あるいは、端末装置１４からの情報であると判断し、処理部２８に出力する。２つの電子署名の値が不一致ならば電子署名が正当でないと判断し、データは破棄される。また、メッセージタイプが暗号化データの場合には、暗号部４２にてペイロードと署名の復号処理を実行する。そして、署名が予め定めた値であれば、セキュアフレームから取り出したデータが正常復号されたと判断し、セキュアフレームから取り出したデータを処理部２８に出力する。なお、予め定めた値でない場合、データは破棄される。なお、暗号化対象を署名としているのは、前述のごとく署名には既知の値を格納して暗号化の対象とすることで、復号時に復号が正常の行われたか否かをチェックする機能を持たせたためである。このようなチェック機能を持たせない場合には、署名を暗号化の対象とする必要はない。メッセージタイプが平文データの場合には、受け取ったセキュアフレームから取り出したデータを、無条件で処理部２８に出力する。

センサ通信部３４は、図示しない内部ネットワークに接続される。この内部ネットワークには、図示しない交差点の各所に設置されたカメラやレーザセンサなどの交差点の情報収集する機器が接続されている。センサ通信部３４に接続された交差点の情報を収集する機器の総称をセンサという。センサ通信部３４は、ネットワークを介して、交差点の各所に設置されたセンサの情報を受け取り、処理部２８へ出力する。ネットワーク通信部３２は、図示しないネットワークに接続される。

処理部２８は、検証部４０から受け取ったデータに対する処理を実行する。処理結果は、ネットワーク通信部３２を介して、図示しないネットワーク２０２へ出力されてもよいし、内部に蓄積して、定期的に図示しないネットワークへ出力されてもよい。また、処理部２８は、ネットワーク通信部３を介して、図示しないネットワークから受け取った道路情報（工事、渋滞など）や、センサ通信部３４を介して、図示しないセンサからの交差点の情報に基づいて、端末装置１４に送信するデータを生成する。制御部３０は、基地局装置１０全体の処理を制御する。

なお、本基地局装置１０が、図６の第３基地局装置１０ｃである場合、検証部４０は、第１の共通鍵テーブルを使用して、処理部２８から取得したデータを含むセキュリティパケットを生成し、変復調部２４、ＲＦ部２２、アンテナ２０を介して報知する。また、第１の共通鍵テーブルを使用して、記憶部４４において記憶した第１の共通鍵テーブル含むセキュリティパケットを生成し、報知する。つまり、第１の共通鍵テーブルを使用可能なエリアを形成している基地局装置１０の検証部４０は、第１の共通鍵テーブル自体も報知する。また、第１の共通鍵テーブルを使用可能なエリアを形成している基地局装置１０に隣接した基地局装置１０、例えば、図６の第２基地局装置１０ｂ、第４基地局装置１０ｄの検証部４０も、第３基地局装置１０ｃと同様に、第１の共通鍵テーブル自体を報知する。ここで、第１の共通鍵テーブルを使用可能なエリアを形成している基地局装置１０から所定の距離の基地局装置１０も、第１の共通鍵テーブル自体を報知してもよい。また、図６の第１基地局装置１０a、第２基地局装置１０ｂ、第４基地局装置１０ｄ、第５基地局装置１０ｅの検証部４０は、１の共通鍵テーブルを使用して、処理部２８から取得したデータを含むセキュリティパケットを生成して報知する。

この構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

図７は、車両１２に搭載された端末装置１４の構成を示す。端末装置１４は、アンテナ５０、ＲＦ部５２、変復調部５４、ＭＡＣフレーム処理部５６、受信処理部５８、データ生成部６０、検証部６２、通知部７０、制御部７２を含む。検証部６２は、暗号部６４と記憶部６６、判定部６８を含む。アンテナ５０、ＲＦ部５２、変復調部５４、ＭＡＣフレーム処理部５６、検証部６２、記憶部６６、暗号部６４は、図２のアンテナ２０、ＲＦ部２２、変復調部２４、ＭＡＣフレーム処理部２６、検証部４０、暗号部４２、記憶部４４と同様の処理を実行する。そのため、ここでは、同様の処理の説明を割愛し、差異を中心に説明する。

検証部６２は、検証部４０と同様に、セキュアフレームの生成および解釈を行う。また、受け取ったセキュアフレームのペイローロードが、セキュリティ情報の場合、すなわち、第１の共通鍵テーブルが含まれる時、その第１の共通鍵テーブルが記憶部６６に未記録の場合には、記憶部６６に受け取った第１の共通鍵テーブルを記憶させる。記憶部６６に空きがある場合、受け取った共通鍵テーブルをそのまま追記する。記憶部６６に、他のテーブルＩＤを含む第１の共通テーブルが記録されている場合、記憶部６６に記憶されている第１の共通鍵テーブルを書き換える。記憶部６６に、同じテーブルＩＤを含む第１の共通テーブルが記録されている場合、受け取った第１の共通テーブルを破棄する。

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

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

前述のごとく、基地局装置１０を識別するための情報は、セキュアフレームの「発信元ＩＤ」に基地局ＩＤが格納されている。判定部６８は、パケット信号の発信元が、基地局装置１０である場合、発信元ＩＤから基地局ＩＤを抽出して、パケット信号の報知元になる基地局装置１０を特定する。

また、前述のごとく記憶部６６に記録されている第１の共通鍵テーブルには、第１の共通鍵テーブルを使用可能なエリアを形成する基地局装置の基地局ＩＤのリストが含まれている。ここでは、図６の第３基地局装置１０ｃに相当した基地局装置１０の基地局ＩＤがリストに含まれている。判定部６８は、記憶部６６に記憶されたリスト中に、受けつけた基地局ＩＤが含まれているかを判定する。これは、第１の共通鍵テーブルを使用可能なエリア内に存在するかを判定することに相当する。判定部６８は、判定結果を保持する。検証部６２は、セキュリティフレームを生成する際、判定部６８の判定結果に従って、共通鍵テーブルを選択する。

データ生成部６０は、図示しないＧＰＳ受信機、ジャイロスコープ、車速センサ等を含んでおり、それらから供給される情報によって、図示しない自車両の情報、つまり端末装置１４が搭載された車両１２の存在位置、進行方向、移動速度等を取得する。なお、存在位置は、緯度・経度によって示される。これらの取得には公知の技術が使用されればよいので、ここでは説明を省略する。データ生成部６０は、取得した情報を元にデータを生成し、生成したデータを検証部６２に出力する。また、取得した情報を受信処理部５８に自車両情報として出力する。

以上の構成による通信システム１００のパケット信号の送受信に関わる動作を説明する。図８は、基地局装置１０におけるパケット信号の送信手順を示すフローチャートである。共通鍵テーブルを送信しない場合（Ｓ１０のＮ）、検証部４０は、処理部２８よりデータと、データを送信するメッセージタイプのデータ形式を受け取る。そして、受け取ったデータをペイロードに格納したセキュアフレームを生成する（Ｓ１２）。この時、鍵ＩＤおよび署名は、空であり、例えば、すべてに０を格納する。次いで、メッセージタイプのデータ形式が平文データの場合（Ｓ１４のＹ）、ＭＡＣフレーム処理部２６、変復調部２４、ＲＦ部２２、アンテナ２０を介して、そのままセキュアフレームを、パケット信号として報知する（Ｓ２２）。メッセージタイプのデータ形式が署名付きデータまたは暗号データの場合（Ｓ１４のＮ）、共通鍵を選択する（Ｓ１６）。共通鍵は最新の共通鍵テーブルよりランダムに選択される。共通鍵を選択するとセキュアフレームの鍵ＩＤには、最新の共通鍵テーブルのテーブルＩＤと選択された共通鍵ＩＤが格納される。再び、メッセージタイプのデータ形式を参照して、データ形式が署名付きデータの場合（Ｓ１８のＹ）、検証部４０は、暗号部４２にて、選択した共通鍵を用いてペイロードヘッダおよびペイロードに対する電子署名を演算し、その値をセキュアフレームの署名に格納する（Ｓ２０）。次いで、ＭＡＣフレーム処理部２６、変復調部２４、ＲＦ部２２、アンテナ２０を介して、署名を付けたセキュアフレームを、パケット信号として報知する（Ｓ２２）。メッセージタイプのデータ形式が暗号化データの場合（Ｓ１８のＮ）、検証部４０は、暗号部４２にて、ペイロートのＭＡＣ値を求め、セキュアフレームの署名に格納する（Ｓ２４）。次いで、選択した共通鍵を用いてペイロードヘッダおよび署名を暗号化する（Ｓ２６）。そして、ＭＡＣフレーム処理部２６、変復調部２４、ＲＦ部２２、アンテナ２０を介して、暗号化したセキュアフレームを、パケット信号として報知する（Ｓ２２）。

共通鍵テーブルを送信する場合（Ｓ１０のＹ）、検証部４０は、記憶部４４より報知する共通鍵テーブルを取得し、セキュアフレームを生成し（Ｓ２８）、共通鍵を選択する（Ｓ３０）。検証部４０は、暗号部４２にて、ペイロートのＭＡＣ値を求め、セキュアフレームの署名に格納する（Ｓ２４）。次いで、選択した共通鍵を用いてペイロードヘッダおよび署名を暗号化する（Ｓ２６）。そして、ＭＡＣフレーム処理部２６、変復調部２４、ＲＦ部２２、アンテナ２０を介して、暗号化したセキュアフレームを、パケット信号として報知する（Ｓ２２）。

図９は、基地局装置１０におけるパケット信号の受信手順を示すフローチャートである。アンテナ２０、ＲＦ部２２、変復調部２４は、パケット信号を受信する（Ｓ４０）。データ形式が署名付きあるいは暗号化であれば（Ｓ４２のＮ）、検証部４０は、鍵テーブルＩＤおよび共通鍵ＩＤを確認する（Ｓ４４）。記憶部４４は、鍵テーブルＩＤを蓄積する（Ｓ４６）。検証部４０は、記憶部４４から共通鍵を取得する（Ｓ４８）。データ形式が署名付きであり（Ｓ５０のＹ）、署名データが正当であれば（Ｓ５２のＹ）、検証部４０は、テーブルＩＤを計数する（Ｓ５８）。一方、データ形式が暗号化である場合（Ｓ５０のＮ）、検証部４０は、取得した暗号鍵にて復号する（Ｓ５４）。データが正当であれば（Ｓ５６のＹ）、検証部４０は、テーブルＩＤを計数する（Ｓ５８）。署名データが正当でない場合（Ｓ５２のＮ）、あるいはデータが正当でない場合（Ｓ５６のＮ）、検証部４０は、データを破棄する（Ｓ６２）。テーブルＩＤが計数された後、あるいはデータ形式が平文である場合（Ｓ４２のＹ）、検証部４０は、データを取り出す（Ｓ６０）。

図１０は、端末装置１４におけるパケット信号の受信手順を示すフローチャートである。アンテナ５０、ＲＦ部５２、変復調部５４は、パケット信号を受信する（Ｓ８０）。データ形式が署名付きあるいは暗号化であれば（Ｓ８２のＮ）、検証部６２は、鍵テーブルＩＤおよび共通鍵ＩＤを確認する（Ｓ８４）。記憶部６６が鍵テーブルを有していれば（Ｓ８６のＹ）、記憶部６６は、鍵テーブルＩＤを蓄積する（Ｓ８８）。検証部６２は、記憶部６６から共通鍵を取得する（Ｓ９０）。データ形式が署名付きであり（Ｓ９２のＹ）、署名データが正当であれば（Ｓ９４のＹ）、検証部６２は、データを抽出する（Ｓ１０４）。

一方、データ形式が暗号化である場合（Ｓ９２のＮ）、検証部６２は、取得した暗号鍵にて復号する（Ｓ９６）。データが正当であり（Ｓ９８のＹ）、データ種別がなければ（Ｓ１００のＮ）、検証部６２は、データを抽出する（Ｓ１０４）。データ形式が平文である場合（Ｓ８２のＹ）、検証部６２は、データを取り出す（Ｓ１０４）。記憶部６６が鍵テーブルを有していない場合（Ｓ８６のＮ）、あるいは署名データが正当でない場合（Ｓ９４のＮ）、あるいはデータが正当でない場合（Ｓ９８のＮ）、検証部６２は、データを破棄する（Ｓ１０６）。データ種別があり（Ｓ１００のＹ）、鍵テーブルがある場合（Ｓ１０２のＹ）、検証部６２は、データを破棄する（Ｓ１０６）。鍵テーブルがなければ（Ｓ１０２のＮ）、検証部６２は、記憶部６６に格納させる（Ｓ１０８）。

図１１は、端末装置１４におけるパケット信号の送信手順を示すフローチャートである。検証部６２は、データを取得し、セキュアフレームを生成する（Ｓ１２０）。メッセージタイプが署名付きあるいは暗号化であり（Ｓ１２２のＮ）、基地局装置受信エリアでなければ（Ｓ１２４のＮ）、検証部６２は、第２共通鍵テーブルから共通鍵を選択する（Ｓ１２８）。基地局装置受信エリアであり（Ｓ１２４のＹ）、基地局装置１０から受信したパケット信号に含まれる発信元ＩＤが第１の共通鍵テーブルの基地局ＩＤのリストに含まれていなくても（Ｓ１２６のＮ）、検証部６２は、第２共通鍵テーブルから共通鍵を選択する（Ｓ１２８）。

基地局装置１０から受信したパケット信号に含まれる発信元ＩＤが第１の共通鍵テーブルの基地局ＩＤのリストに含まれていれば（Ｓ１２６のＹ）、検証部６２は、第１共通鍵テーブルから共通鍵を選択する（Ｓ１３０）。メッセージタイプが署名付きであれば（Ｓ１３２のＹ）、検証部６２は、選択した共通鍵にて電子署名を演算し、署名データに格納し（Ｓ１３４）、変復調部５４、ＲＦ部５２、アンテナ５０は、パケット信号を報知する（Ｓ１４０）。メッセージタイプが暗号化であれば（Ｓ１３２のＮ）、検証部６２は、ペイロードヘッダのＭＡＣ値を演算し、署名データに格納する（Ｓ１３６）。検証部６２は、選択して暗号鍵にて暗号化し（Ｓ１３８）、変復調部５４、ＲＦ部５２、アンテナ５０は、パケット信号を報知する（Ｓ１４０）。メッセージタイプが平文であれば（Ｓ１２２のＹ）、変復調部５４、ＲＦ部５２、アンテナ５０は、パケット信号を報知する（Ｓ１４０）。

本発明の実施例によれば、所定のエリア内に存在すれば、第２の共通鍵テーブルとは別の第１の共通鍵テーブルを使用するので、エリアに応じて、少なくとも２種類の共通鍵テーブルを使用できる。また、エリアに応じて、少なくとも２種類の共通鍵テーブルが使用されるので、一方の共通鍵テーブルのみを更新できる。また、一方の共通鍵テーブルのみが更新されるので、エリアに応じて暗号鍵を効率的に配布できる。また、一方の共通鍵テーブルのみが更新されるので、危険性の高いエリアのみにおいて共通鍵テーブルを更新できる。また、所定のエリア内において、第１の共通鍵テーブルを記憶していなければ、第１の共通鍵テーブルに含まれた共通鍵によって生成された電子署名を正当と判定しないので、安全性を確保できる。

また、所定のエリア内において、第１の共通鍵テーブルを記憶していなくても、第１の共通鍵テーブルに含まれた共通鍵によって生成された電子署名を所定回数以上検出すれば、検証を省略するので、当該電子署名を添付したデータを取得できる。また、所定回数以上検出した場合だけデータを取得するので、電子署名を検証しなくても危険性を低減できる。また、データが取得されるので、他の車両の接近を認識できる。また、第１の共通鍵テーブルを使用していない基地局装置も第１の共通鍵テーブルを配布するので、第１の共通鍵テーブルを利用しやすくできる。また、第１の共通鍵テーブルを配布する基地局装置が制限されるので、伝送効率の悪化を抑制できる。

また、電子署名を生成するために共通鍵を使用するので、公開鍵を使用する場合と比較して処理量を低減できる。また、処理量が低減されるので、処理可能なパケット信号数を増加できる。また、電子署名を生成するために共通鍵を使用するので、公開鍵を使用する場合と比較して伝送効率を向上できる。また、位置情報等のデータに対しては暗号化を実行しないので、処理量を低減する。一方、共通鍵テーブルには暗号化を実行するので、安全性を向上できる。

次に本発明の変形例を説明する。セキュリティを向上させるためには、定期的な暗号鍵の更新が望まれる。複数の端末装置において共通した暗号鍵を使用させながら、暗号鍵を更新するためには、通信システム内に暗号鍵を管理させるための装置が接続されるべきである。しかしながら、端末装置が主に車両に搭載され、車両が移動している状況を想定すると、暗号鍵を管理させるための装置によって、暗号鍵が管理されないエリアも存在する。そのため、端末装置だけが存在する状況下においても、暗号鍵の自律的な更新が望まれる。変形例の目的は、暗号鍵を自律的に更新させる技術を提供することにある。

本発明の変形例では、ひとつの共通鍵をひとつの共通鍵ＩＤとして管理し、複数の共通鍵を共通鍵テーブルにまとめる。さらに、共通鍵テーブルのバージョンは、テーブルＩＤとして管理される。そのため、ひとつのテーブルＩＤには、複数の共通鍵ＩＤが含まれる。このような共通鍵テーブルは定期的に更新されることが望ましい。本通信システムが十分普及する前の段階や、交通量の少ないエリア等では、基地局装置の設置数が少ないことが想定される。そのような状況において、基地局装置が、新たな共通鍵テーブルを通知することによって、端末装置が、共通鍵テーブルを更新する場合、共通鍵テーブルを更新していない端末装置の数が増加しうる。これに対応するため、本変形例に係る端末装置は、共通鍵テーブルを更新するための非可逆変換関数を予め記憶し、既に使用している共通鍵テーブルを非可逆変換関数によって更新することによって、新たな共通鍵テーブルを生成する。つまり、端末装置は、共通鍵テーブルを自律的にかつ定期的に更新する。

変形例に係る通信システム１００は、図１と同様のタイプである。電子署名として、公開鍵暗号方式に基づくデジタル署名が有力である。公開鍵暗号方式に基づく方式として、具体的には、ＲＳＡ、ＤＳＡ、ＥＣＤＳＡ等が使用される。電子署名方式は、鍵生成アルゴリズム、署名アルゴリズム、検証アルゴリズムによって構成される。鍵生成アルゴリズムは電子署名の事前準備に相当する。鍵生成アルゴリズムは、ユーザの公開鍵および秘密鍵を出力する。鍵生成アルゴリズムが実行される度に異なる乱数が選ばれるので、ユーザごとに異なる公開鍵・秘密鍵ペアが割り振られる。各ユーザは、秘密鍵を保管し、公開鍵を公開する。共通鍵テーブルはテーブルＩＤにて管理されており、テーブルＩＤを増加させることによって、共通鍵テーブルはバージョンアップに対応する。共通鍵テーブルのバージョンアップは、基地局装置１０および端末装置１４のそれぞれになされる。

端末装置１４は、非可逆変換関数を予め記憶し、既に使用している共通鍵テーブルを非可逆変換関数にて変換することによって、新たな共通鍵テーブルを生成する。そのため、端末装置１４における共通鍵テーブルのバージョンアップは自律的になされる。ここで、バージョンアップのタイミングは、例えば、現在の共通鍵テーブルを使用開始してから所定の期間経過したときであればよい。また、端末装置１４は、他の端末装置１４からのパケット信号を受信し、当該パケット信号にて使用されている共通鍵を含んだ共通鍵テーブルのバージョンが新しいことを検出したときが、バージョンアップのタイミングであってもよい。一方、基地局装置１０は、端末装置１４と同様に、共通鍵テーブルのバージョンアップを実行してもよく、ネットワーク２０２から新たな共通鍵テーブルを受けつけてることによって、バージョンアップを実行してもよい。

変形例に係る基地局装置１０は、図２と同様のタイプである。図１２は、通信システム１００において規定されるＭＡＣフレームに格納されるセキュリティフレームのフォーマットを示す。セキュリティフレームは、「セキュリティヘッダ」、「ペイロード」、「署名」が配置される。さらに、セキュリティヘッダには、「プロトコルバーション」、「メッセージタイプ」、「テーブルＩＤ」、「鍵ＩＤ」、「発信元種別」、「発信元ＩＤ」、「発信日時」、「ロケーション」、「ペイロード長」が配置される。プロトコルバーションは、セキュリティフレームのフォーマットを規定するための識別情報である。通信システム１００においては固定値となる。メッセージタイプには、「データ種別」と「データ形式」とリザーブが含まれる。データ種別には、ペイロードに格納されるデータがアプリケーションデータ（＝０）、すなわち、後続のＭＡＣフレーム処理部２６へ出力されるデータであるか、メンテナンスデータ（＝１）、すなわち、検証部４０の内部で処理されるセキュリティ情報であるかを識別するためのフラグ情報が設定される。

データ形式は、ペイロードに格納されるデータのセキュリティに関わる形式、つまり、ペイロードに対する暗号処理を規定するためのフラグである。ここでは、平文データ（＝０）、署名付きデータ（＝１）、暗号化データ（＝２）が設定される。なお、リザーブは将来に対する予備であり、通信システム１００では使用しない。テーブルＩＤは、電子署名あるいはペイロードの暗号化に使用した共通鍵が含まれた共通鍵テーブルの識別情報である。鍵ＩＤは、電子署名あるいはペイロードの暗号化に使用した共通鍵を特定するための識別情報であり、前述の共通鍵ＩＤに相当する。発信元種別ＩＤは、パケット信号の発信者の種類、すなわち、基地局装置１０（＝３）、救急車や消防車のような緊急車両（優先車両とよぶ）に搭載の端末装置（＝２）、その他の車両（一般車両とよぶ）に搭載の端末装置（＝１）および非車両搭載の端末装置（＝０）が設定される。発信元ＩＤは、パケット信号を発信した基地局装置１０あるいは端末装置１４を一意に特定するための識別情報であり、これは装置ごとにユニークに規定される。

ペイロードは、前述のデータを格納するためのフィールドであり、交差点情報や道路情報等の端末装置へ通知すべき情報に相当する。また、メッセージタイプのデータ形式が署名付きデータ(＝１)のとき、セキュリティヘッダおよびペイロードに対する電子署名が生成される。また、メッセージタイプのデータ形式が暗号化データ(＝２)のとき、無効としてもよいが、ここでは固定値、セキュリティヘッダの部分の写しなどの受信側特定可能な値、あるいは、セキュリティヘッダまたは／および暗号化前のペイロードに対するハッシュ値（ハッシュ関数による演算結果）、チェックサム、パリティなどの受信側で演算可能な値を格納するものとする。そして、ペイロードが暗号化される。このようにすることで、復号によって得られた署名に格納された値と、受信側で特定した、あるいは、演算した値とが一致すれば、復号が正常の行われ、ペイロードに格納されているデータ、あるいはセキュリティヘッダとペイロードに格納されているデータの正当性が確認できる。各フィード長さは、例えば、セキュリティヘッダが３２バイト、ペイロードが１００バイト（端末装置が報知する場合）あるいは１Ｋバイト（基地局装置が報知する場合）であり、署名が１６バイトである。

通信システム１００では、暗号方式としてＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）暗号を使用する。図１３（ａ）−（ｂ）は、セキュリティフレームに対する処理内容を示す。図１３（ａ）、はメッセージタイプのデータ形式が署名付きデータの場合を示す。電子署名は、セキュリティヘッダの一部、ここでは、発信元種別、発信元ＩＤ、発信日時、ローケーション、ペイロード長と、ペイロードに対して演算され、その値は、セキュリティフッダにある署名に格納される。電子署名の演算対象に、発信元種別、発信元ＩＤを含めているのは、発信元となる車載器あるいは路側機の素性を証明するためである。また、発信日時、ローケーションを含めているのは、発信日時、ローケーションの改ざんを防止し、パケット信号を傍受して、そのパケット信号を再送信することによる妨害を防ぐためである。図１３（ｂ）は、メッセージタイプのデータ形式が暗号化データの場合を示す。電子署名は、セキュリティヘッダの一部、ここでは、発信元種別、発信元ＩＤ、発信日時、ローケーション、ペイロード長に対して演算され、その値は、セキュリティフッダにある署名に格納される。ペイロードは、ＣＢＣ（Ｃｉｐｈｅｒ Ｂｌｏｃｋ Ｃｈａｉｎｉｎｇ）モードで暗号化される。ＣＢＣモードでは、最初のブロックを暗号化する場合に、初期ベクトル（Ｉｎｉｔａｌ Ｖｅｃｔｏｒ、以下では、「ＩＶ」という。）が使用される。ＩＶの値は、通常いかなる値を用いてもよいが、通信システム１００では、ペイロードに格納されたデータを、情報の発信元に対して紐付けして暗号化することですることで、データの信頼性を向上させる。ここでは、発信元種別、発信元ＩＤ、発信日時、ローケーション、ペイロード長を元にして演算して、ＩＶを決定する。具体的には、先に求めたセキュリティヘッダに一部に対する電子署名の値を、ＩＶとして用いるものとする。図２に戻る。

記憶部４４は、通信システム１００に使用可能な共通鍵が含まれた複数の共通鍵テーブルを記憶する。図１４は、記憶部４４に記憶される共通鍵テーブルのデータ構造を示す。共通鍵テーブルには、複数のバージョンが存在してもよく、それらは、テーブルＩＤとして管理される。図１４において、第１テーブル２２０は、テーブルＩＤが「Ｎ−１」である場合に相当し、第２テーブル２２２は、テーブルＩＤが「Ｎ」である場合に相当する。第２テーブル２２２が第１テーブル２２０よりも新しいバージョンである。ここでは、ふたつの共通鍵テーブルを示しているが、記憶部４４には、３つ以上の共通鍵テーブルが記憶されていてもよい。各共通鍵テーブルには、複数の共通鍵が含まれており、各共通鍵は共通鍵ＩＤで管理されている。図１４において、第１共通鍵は、共通鍵ＩＤが「１」である場合に相当し、第２共通鍵は、共通鍵ＩＤが「２」である場合に相当する。そのため、ひとつの共通鍵は、テーブルＩＤと共通鍵ＩＤとの組合せによって特定される。また、各共通鍵テーブルに、更新日時に関する情報が含まれている。第１テーブル２２０の更新日時が「２０１０．１．１」であり、第２テーブル２２２の更新日時が「２０１０．３．１」である。なお、記憶部４４は、共通鍵テーブルの更新が、基地局装置および端末装置に普及するまでの期間を補償するために、少なくとの１つ過去の共通鍵テーブルを保持する。図２に戻る。

検証部４０は、セキュリティフレームを生成する際、記憶部４４を参照して、共通鍵を抽出する。例えば、各共通鍵テーブルには、更新日時が規定されており、検証部４０は、現在の時刻をもとに、ひとつの共通鍵テーブルを選択する。検証部４０は、運用中の共通鍵テーブルの中から、最新の更新日時の共通鍵テーブルを選択する。さらに、検証部４０は、選択した共通鍵テーブルの中から、ひとつの共通鍵を選択する。この選択は、ランダムになされてもよいし、基地局装置１０に付与された識別番号にしたがってなされてもよい。

検証部４０は、メッセージタイプのデータ形式が署名付きデータの場合に、選択した共通鍵を使用して暗号部４２にてセキュリティヘッダとペイロードに対する電子署名を演算させる。また、メッセージタイプのデータ形式が暗号化データの場合には、暗号部４２にてペイロードを暗号化させる。検証部４０は、メッセージタイプのデータ形式が平文データの場合に、生成したセキュリティフレームをＭＡＣフレーム処理部２６へそのまま出力する。なお、ＭＡＣフレーム処理部２６から受け取ったデータを用いてセキュリティフレームを生成する場合、検証部４０は、メッセージタイプのデータ種別をアプリケーションデータ（＝０）にする。

検証部４０は、セキュリティフレームを解釈する際、ＭＡＣフレーム処理部２６から受け取ったセキュリティフレームのテーブルＩＤと共通鍵ＩＤとを取得する。次いで、検証部４０は、記憶部４４を参照して、このテーブルＩＤと共通鍵ＩＤにて特定される共通鍵を抽出する。さらに、検証部４０は、ＭＡＣフレーム処理部２６から受け取ったセキュリティフレームのメッセージタイプのデータ形式が署名付きデータの場合に、抽出した共通鍵を使用して署名の正当性を検証する。詳細には、暗号部４２がセキュリティヘッダとペイロードに対する電子署名を演算し、求めた値と、ＭＡＣフレーム処理部２６から受け取ったセキュリティフレームの署名に格納された電子署名の値と比較する。ふたつの電子署名の値が一致すれば、電子署名が正当であり、このセキュリティフレームに含まれる情報が正規の基地局装置１０、あるいは、端末装置１４からの情報であると判断し、ＭＡＣフレーム処理部２６に出力する。ふたつの電子署名の値が不一致ならば電子署名が正当でないと判断し、データは破棄される。

また、メッセージタイプのデータ形式が暗号化データの場合に、暗号部４２がペイロードと署名の復号処理を実行する。そして、署名が予め定めた値であれば、セキュリティフレームから取り出したデータが正常復号されたと判断し、セキュリティフレームから取り出したデータをＭＡＣフレーム処理部２６に出力する。なお、予め定めた値でない場合、データは破棄される。メッセージタイプのデータ形式が平文データの場合に、検証部４０は、受け取ったセキュリティフレームから取り出したデータを、無条件でＭＡＣフレーム処理部２６に出力する。

処理部２８は、検証部４０から受け取ったデータに対する処理を実行する。処理結果は、ネットワーク通信部３２を介して、直接、図示しないネットワークへ出力されてもよし、内部に蓄積して、定期的に図示しないネットワークへ出力されてもよい。また、処理部２８は、ネットワーク通信部３２を介して、図示しないネットワークから道路情報（工事、渋滞など）を受け取ったり、センサ通信部３４を介して、図示しないセンサからの交差点の情報を受け取ったりする。処理部２８は、これらの情報にもとづいて、端末装置１４に送信すべきデータを生成する。また、処理部２８は、ネットワーク通信部３２を介して図示しないサーバ装置から、新たな共通鍵テーブルを受け取ると、検証部４０の記憶部４４に書き込む。制御部３０は、基地局装置１０全体の処理を制御する。

この構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

図１５は、車両１２に搭載された端末装置１４の構成を示す。端末装置１４は、アンテナ５０、ＲＦ部５２、変復調部５４、ＭＡＣフレーム処理部５６、受信処理部５８、データ生成部６０、検証部６２、通知部７０、制御部７２を含む。検証部６２は、暗号部１０６４、記憶部１０６６、生成部１０７６、判定部１０７４を含む。アンテナ５０、ＲＦ部５２、変復調部５４、ＭＡＣフレーム処理部５６、検証部６２、記憶部１０６６、暗号部１０６４は、図２のアンテナ２０、ＲＦ部２２、変復調部２４、ＭＡＣフレーム処理部２６、検証部４０、暗号部４２、記憶部４４と同様の処理を実行する。そのため、ここでは、同様の処理の説明を割愛し、差異を中心に説明する。

検証部６２は、検証部４０と同様に、セキュリティフレームの生成および解釈を行う。つまり、記憶部１０６６は、ＲＦ部５２等におけるパケット信号の送受信に使用可能な共通鍵が複数種類示された共通鍵テーブルを記憶しており、検証部６２は、検証部４０と同様に、記憶部１０６６において記憶した共通鍵テーブルから、いずれかの共通鍵を選択する。また、検証部６２は、選択した共通鍵を使用して、ＲＦ部５２等において受信したパケット信号に添付された電子署名を検証するか、あるいはＲＦ部５２等から送信すべきパケット信号に添付される電子署名を生成する。なお、検証部６２は、暗号化や復号に共通鍵を使用してもよい。

判定部１０７４は、記憶部１０６６に記憶した共通鍵テーブルを更新すべきタイミングを判定する。判定部１０７４は、共通鍵テーブルを更新すべき日時を予め保持しており、内部に含んだ図示しない時計によって取得した日時、予め設定した日時になったとき、生成部１０７６に対して共通鍵テーブル更新を指示する。ここで、共通鍵テーブルを更新すべき日時が定期的に定められることによって、共通鍵テーブルは、定期的に更新される。なお、他の端末装置と日時が大幅にずれることを防ぐために、データ生成部６０に含まれる、ＧＰＳ受信機によって取得される日時情報、あるいは、ＭＡＣフレーム処理部５６から受け取ったパケット信号に含まれる日時情報によって、内部に時計をアジャストする。ここでは、判定部１０７４は、内部に時計を含むように示したが、必ずしも、内部に時計を含む必要はない。データ生成部６０に含まれる、ＧＰＳ受信機によって取得される日時情報を取得して判定を行ってもよい。

生成部１０７６は、判定部１０７４から更新指示を受けた場合、記憶部１０６６に記憶した共通鍵テーブルに対して非可逆変換関数による演算を実行することによって、共通鍵テーブルを更新する。共通鍵テーブルを更新することは、共通鍵テーブルに含まれた複数の共通鍵をそれぞれ更新することに相当する。なお、非可逆変換関数は、予め定められているとする。図１６（ａ）−（ｃ）は、生成部１０７６による共通鍵テーブルの更新の概要を示す。ここで、テーブルＩＤによって管理できる最大数をＭ（Ｍは、自然数）とすると、テーブルＩＤは、Ｍを法とした剰余系に値であり、Ｎ−１、Ｎ、Ｎ＋１はＭを法とした剰余値である。図１６（ａ）では、記憶部１０６６に記憶された最新の共通鍵テーブル、つまりテーブルＩＤがＮの共通鍵テーブル対して、非可逆変換関数ｆ１を使用することによって、新たな共通鍵テーブルを生成することが示される。新たな共通鍵テーブルのテーブルＩＤはＮ＋１である。

また、図１６（ｂ）では、記憶部１０６６に記憶された過去の共通テーブル、つまりテーブルＩＤがＮ−１の共通鍵テーブル対して、非可逆変換関数ｆ２を使用することによって、新たな共通鍵テーブルを生成することが示される。さらに、図１６（ｃ）では、記憶部１０６６に記憶された最新の共通鍵テーブルと過去の共通鍵テーブル、つまりテーブルＩＤがＮとテーブルＩＤがＮ−１の共通鍵テーブル対して、非可逆変換関数ｆ３を使用することによって、新たな共通鍵テーブルを生成することが示される。この場合、ふたつの共通鍵テーブルを使用して、ひとつの共通鍵テーブルが生成される。新たな共通鍵テーブルは、記憶部１０６６に記録される。このとき、記憶部１０６６の新しい領域に記憶してもよいし、最も古い共通鍵テーブルに上書き記録してもよい。記憶部１０６６が、図１４のごとく、２つの共通鍵テーブルしか記録できない場合、新たな共通鍵テーブル（テーブルＩＤ＝Ｎ＋１）は、最も古い共通鍵テーブル（テーブルＩＤ＝Ｎ＋１）と置き換えられる。また、２つの共通鍵テーブルを記憶していることを前提として、共通鍵テーブルの更新の概念を述べたが、新たな共通鍵テーブルを生成するもととなる以前の共通鍵テーブルを限定するものではない。更新以前の１つあるいは複数の共通鍵テーブルを元として新たな共通鍵テーブルを生成するように構成できる。この場合、記憶部１０６６は、新たな共通鍵テーブルを生成の元となる共通鍵テーブルを記憶していなければならない。図１５に戻る。

判定部１０７４は、ＭＡＣフレーム処理部５６から受け取ったパケット信号に含まれたテーブルＩＤをもとに、共通鍵テーブルを更新すべきタイミングを取得してもよい。具体的には説明すると、検証部６２は、メッセージタイプデータのデータ形式が署名付きデータあるいは暗号化データであって、テーブルＩＤの共通鍵テーブルが記憶部１０６６に記憶されていない場合、生成部１０７６にて、パケット信号に含まれたテーブルＩＤと共通鍵ＩＤに対応した共通鍵を生成する。そして、検証部６２は、メッセージタイプデータのデータ形式が署名付きデータの場合に、生成部１０７６において生成した共通鍵を使用して、暗号部１０６４にてセキュリティヘッダとペイロードに対する電子署名を演算する。また、検証部６２は、メッセージタイプが暗号データの場合に、生成部１０７６において生成した共通鍵を使用して、暗号部４２にてセキュリティヘッダに対する電子署名を演算し、ペイロードを復号する。これらの処理が正常になされた場合、判定部１０７４は、生成した共通鍵が正しいと判断する。生成した共通鍵が正しい場合、判定部１０７４は、生成部１０７６に対して、先のテーブルＩＤの共通鍵テーブルへの更新を指示する。制御部７２は、端末装置１４全体の動作を制御する。

以上の構成による通信システム１００のパケット信号の送受信に関わる動作を説明する。図１７は、端末装置１４における共通鍵テーブルのメンテナンス手順を示すフローチャートである。判定部１０７４は、現在の日時と、記憶部１０６６に記憶されている最新の共通鍵テーブルのテーブルＩＤ、更新日時により導かれる更新予定日時を共通鍵テーブルの更新タイミングを判断する（Ｓ１０１０）。判定部１０７４は、更新タイミングだと判断した場合（Ｓ１０１０のＹ）、生成部１０７６は、共通鍵テーブルを更新する（Ｓ１０１４）。判定部１０７４は、更新タイミングでないと判断した場合（Ｓ１０１０のＮ）、受信処理からの更新要求を確認する（Ｓ１０１２）。これは、ＭＡＣフレーム処理部５６から受け取ったパケット信号に含まれたテーブルＩＤをもとに、共通鍵テーブルを更新すべきかどうかの判断である。パケット信号に含まれたテーブルＩＤによって、共通鍵テーブルの更新要求を受け取っていると、更新のタイミングであると判断し（Ｓ１０１２のＹ）、つまりパケット信号に記憶していないテーブルＩＤで指定されたテーブルに含まれる共有鍵で署名、あるいは、暗号化されたデータを検出すれば、生成部１０７６は、共通鍵テーブルを更新する（Ｓ１０１４）。判定部１０７４は、受信処理からの更新要求を受けつけなければ、更新タイミングでないと判断し（Ｓ１０１２のＮ）、処理を終了する。

図１８は、端末装置１４におけるパケット信号の受信手順を示すフローチャートである。アンテナ５０、ＲＦ部５２、変復調部５４は、パケット信号を受信する（Ｓ１０３０）。データ形式が署名付きあるいは暗号文であれば（Ｓ１０３２のＮ）、検証部６２は、テーブルＩＤおよび共通鍵ＩＤが記憶部１０６６に記憶されているかを確認する（Ｓ１０３４）。記憶部１０６６が鍵テーブルを有していれば（Ｓ１０３４のＹ）、検証部６２は、記憶部１０６６から共通鍵を取得する（Ｓ１０３８）。記憶部１０６６が鍵テーブルを有していなければ（Ｓ１０３４のＮ）、生成部１０７６は、記憶部１０６６の共通鍵テーブルから鍵を演算する（Ｓ１０３６）。

データ形式が署名付きであれば（Ｓ１０４０のＹ）、検証部６２は、取得した共通鍵にて、セキュリティヘッダの一部とペイロードに対する電子署名を演算する（Ｓ１０４２）。一方、データ形式が暗号文である場合（Ｓ１０４０のＮ）、検証部６２は、取得した共通鍵にて復号する（Ｓ１０４４）。データの復号には、セキュリティヘッダの一部に対する電子署名の演算と、その値をＩＶとした暗号化されているペイロードの復号が含まれる。演算した電子署名の値と、セキュリティフッダの署名の値を比較して、両者が一致すればデータが正当であると判断する（Ｓ１０４６のＹ）。正当である場合、演算した共通鍵であれば（Ｓ１０４８のＹ）、判定部１０７４に対して、共通鍵テーブルの更新要求する（Ｓ１０５０）。演算した共通鍵でなければ（Ｓ１０４８のＮ）、ステップ１０５０はスキップされる。

データ形式が平文である場合（Ｓ１０３２のＹ）、ステップ１０３４からステップ１０５０はスキップされる。データ種別がメンテナンスデータである場合（Ｓ１０５２のＹ）、検証部４０は、データを抽出する（Ｓ１０５４）。データ種別がアプリケーションデータである場合（Ｓ１０５２のＮ）、検証部４０は、受信処理部５８へデータを出力する（Ｓ１０５６）。データが正当でない場合（Ｓ１０４６のＮ）、検証部４０は、データを破棄する（Ｓ１０５８）。

図１９は、端末装置１４におけるパケット信号の送信手順を示すフローチャートである。検証部６２は、データを取得し、セキュアフレームを生成する（Ｓ１０７０）。メッセージタイプが署名付きあるいは暗号文である場合（Ｓ１０７２のＮ）、検証部６２は、共通鍵を選択する（Ｓ１０７４）。メッセージタイプが署名付きであれば（Ｓ１０７６のＹ）、検証部６２は、選択した共通鍵にて電子署名を演算する（Ｓ１０７８）。メッセージタイプが暗号文であれば（Ｓ１０７６のＮ）、検証部６２は、選択した共通鍵にて暗号化を実行する（Ｓ１０８０）。メッセージタイプが平文であれば（Ｓ１０７２のＹ）、ステップ１０７４からステップ１０８０までの処理はスキップされる。変復調部５４、ＲＦ部５２、アンテナ５０は、パケット信号を報知する（Ｓ１０８２）。

本発明の変形例において、共通鍵テーブルの更新タイミングの判断おいて、予約された日時による判断と、受信したパケット信号に含まれるテーブルＩＤに基づく２つの判断を併用するよう説明したが、いずれか、一方の判断によって共通鍵テーブルの更新タイミングを判断してもよい。前者のみの場合は、すべての端末装置１４が、時計あるいはＧＰＳ等から日時情報を取得する手段を備えなければならない。また、後者の場合、基地局装置１０、あるいは、新たに市場に投入された車両１２に搭載された端末装置の記憶部１０６６に記憶されている最新の共通鍵テーブルが、共通鍵テーブル更新のきっかけとなり、すべての端末装置に普及する。また、端末装置１４に付いて述べてきたが、基地局装置１０に適用してもよい。特に、図２におけるネットワーク通信部３２を備えない基地局に対して有効である。

本発明の変形例において、発信元種別に無関係に共通鍵テーブルを選択するように示したが、発信元種別毎の共通鍵テーブルを記憶部１０６６に格納し、パケット信号を報知する際に、自身の発信者種別にあった共通鍵テーブルを選択するようにしてもよい。パケット信号の受信時は、発信元種別とテーブルＩＤによって、共通鍵テーブルを選択する。共通鍵テーブルの更新タイミングは、それぞれ、独立して行ってもよいし、同じとしてもよい。共通鍵テーブルの更新タイミングが同じ場合には、共通鍵テーブルを更新する非可逆演算関数は、相互に共通鍵テーブルを引数とするようにしてもよい。また、発信元毎に、共通鍵テーブルを持つのではなく、記憶部１０６６に記憶されている共通鍵テーブルに含まれる共通鍵と、発信元種別とから、署名あるいは暗号化のための共通鍵を算出するようにしても同様な効果が得られる。これらの場合、署名あるいは暗号化に使用する共通鍵は、すでに、発信元種別に紐付けされているので、発信元種別を電子署名の演算対象から外しても構わない。このようにすることで、同時に運用する鍵の総数が増加する、共通鍵の解読に要されるサンプルデータ数が減る。とりわけ、救急車や消防車等の優先車両のサンプルデータ数が激減し、通信路からの共通鍵漏洩の危険性が低下する。

本発明の変形例において、生成部１０７６は、非可逆変換関数を予め保持する。しかしながらこれに限らず例えば、非可逆変換関数は基地局装置１０から奉仕されてもよい。その場合、非可逆変換関数が含まれたパケット信号には、暗号化がなされる。本変形例によれば、非可逆変換関数を変更できる。

本発明の変形例によれば、端末装置が自律的に共通鍵テーブルを更新するので、基地局装置が共通鍵テーブルを配信しない場合であっても、安全性を向上できる。また、既に記憶した共通鍵テーブルに対して非可逆変換関数を演算させるので、基地局装置が共通鍵テーブルを配信しない場合であっても、自律的に共通鍵テーブルを更新できる。また、基地局装置による共通鍵テーブルの配信が不要になるので、周波数利用効率を改善できる。また、共通鍵テーブルの更新タイミングを定期的に判定することで、共通鍵テーブルを定期的に更新できる。また、受信したパケット信号から共通鍵テーブルの更新タイミングを判定するので、周囲の端末装置に合わせるように共通鍵テーブルを更新できる。

また、電子署名を生成するために共通鍵を使用するので、公開鍵を使用する場合と比較して処理量を低減できる。また、処理量が低減されるので、処理可能なパケット信号数を増加できる。また、電子署名を生成するために共通鍵を使用するので、公開鍵を使用する場合と比較して伝送効率を向上できる。また、位置情報等のデータに対しては暗号化を実行しないので、処理量を低減する。

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

本発明の実施例では、第１の共通鍵テーブルを受信可能なエリアを、基地局装置からのパケット信号を受信範囲とし、第１の共通鍵テーブルには、基地局装置ＩＤのリストが含まれる旨示したが、第１の共通鍵テーブル使用エリアを座標によって表現してもよい。ここで、座標とは、複数の地球上の座標点、すなわち、経度と緯度で表される点をいい、例えば、利用可能エリアはリストに複数の座標に囲まれた内側の地域とすることができる。この場合、第１の共通鍵テーブルには、使用可能なエリアを指定する複数の座標をリストに含む。また、１つの座標点から同一距離にある地域とすることもできる。この場合、第１の共通鍵テーブルには、使用可能なエリアを指定する情報として、座標と距離の組みを１あるいは複数含む。なお、第１の共通鍵テーブルは、使用可能なエリアを指定する情報のリストを含むように記したが、必ずしもいったとなっている必要はない。第１の共通鍵テーブルと別に、第１の共通鍵テーブルの使用可能なエリアを指定する情報のリストを持っても良い。この場合、両者は紐付けされている。

本発明の実施例において、通信システム１００は、２種類の共通鍵テーブルを規定する。しかしながらこれに限らず例えば、通信システム１００は、３種類以上の共通鍵テーブルを規定してもよい。その際、第１の共通鍵テーブルが複数種類規定される。所定の基地局装置１０の周囲では、所定の第１の共通鍵テーブルが使用され、別の基地局装置１０の周囲では、別の第１の共通鍵テーブルが使用される。本変形例によれば、更新すべき共通鍵テーブルが使用されるエリアをさらに限定できる。

本発明の変形例において、判定部６８は、パケット信号に含まれた基地局装置１０の識別情報をもとに、第１の共通鍵テーブルを使用可能なエリアに存在するかを判定している。しかしながらこれに限らず例えば、判定部６８は、ＧＰＳ等によって取得した位置情報をもとに、第１の共通鍵テーブルを使用可能なエリアに存在するかを判定してもよい。本変形例によれば、第１の共通鍵テーブルを使用可能なエリアを位置情報に対応づけて規定できる。

本実施例は、次の項目によって特徴付けられてもよい。
（項目１）
共通鍵暗号方式における共通鍵によって生成した電子署名が添付されたパケット信号を送受信する通信部と、
前記通信部におけるパケット信号の送受信に使用可能な共通鍵が複数種類示された共通鍵テーブルを記憶する記憶部と、
前記記憶部において記憶した共通鍵テーブルから、いずれかの共通鍵を選択する選択部と、
前記選択部において選択した共通鍵を使用して、前記通信部において受信したパケット信号に添付された電子署名を検証するか、あるいは前記通信部から送信すべきパケット信号に添付される電子署名を生成する処理部とを備え、
前記処理部は、前記記憶部に記憶した共通鍵テーブルに対して、変換関数による演算を実行することによって、共通鍵テーブルを更新することを特徴とする無線装置。
この場合、暗号鍵を自律的に更新できる。

１０ 基地局装置、 １２ 車両、 １４ 端末装置、 ２０ アンテナ、 ２２ ＲＦ部、 ２４ 変復調部、 ２６ ＭＡＣフレーム処理部、 ２８ 処理部、 ３０ 制御部、 ３２ ネットワーク通信部、 ３４ センサ通信部、 ４０ 検証部、 ４２ 暗号部、 ４４ 記憶部、 ５０ アンテナ、 ５２ ＲＦ部、 ５４ 変復調部、 ５６ ＭＡＣフレーム処理部、 ５８ 受信処理部、 ６０ データ生成部、 ６２ 検証部、 ６４ 暗号部、 ６６ 記憶部、 ６８ 判定部、 ７０ 通知部、 ７２ 制御部、 １００ 通信システム。

Claims (2)

1. 車両に搭載され、基地局装置との間での通信を行う端末装置であって、
   前記基地局装置から報知されたパケット信号を受信する受信部と、
   共通鍵が複数種類示された共通鍵テーブルであって、前記基地局装置との間で共有される共通鍵テーブルを記憶する記憶部と、
   前記受信部が受信したパケット信号を検証する検証部と、
   を備え、
   前記検証部は、前記受信部が受信したパケット信号に、前記記憶部に記憶した共通鍵テーブルとは異なる共通鍵テーブルが含まれている場合、パケット信号に含まれる当該共通鍵テーブルを前記記憶部に記憶することを特徴とする端末装置。
2. パケット信号に含まれる共通鍵テーブルを前記記憶部に記憶した場合、当該共通鍵テーブルに含まれる共通鍵を使用してパケット信号を生成する生成部と、
   前記生成部において生成したパケット信号を、アンテナから報知させるためにアンテナに出力する変調部とをさらに備えることを特徴とする請求項１に記載の端末装置。

Images