JP5341273B1

JP5341273B1 - 車載器

Info

Publication number: JP5341273B1
Application number: JP2013116768A
Authority: JP
Inventors: 真琴永井; 吉宏堀
Original assignee: Sanyo Electric Co Ltd
Current assignee: Sanyo Electric Co Ltd
Priority date: 2010-05-19
Filing date: 2013-06-03
Publication date: 2013-11-13
Anticipated expiration: 2031-05-19
Also published as: JP2015111913A; JP2017085561A; JP5301034B2; WO2011145353A1; JP5362928B2; JP2013219804A; JP2014003686A; JP5732626B2; JP2016040949A; JP2013243676A; JP5891384B2; CN102484791A; JP2013232909A; JP6037153B2; JP5341274B1; JP6273658B2; JPWO2011145353A1; US20130195272A1

Abstract

記憶部４４は、端末装置間の通信に使用可能な共通鍵が複数種類示された共通鍵テーブルを記憶する。ＭＡＣフレーム処理部２６は、端末装置から報知されたパケット信号を受信する。確認部は、受信したパケット信号に添付された電子署名を生成するための共通鍵が含まれた共通鍵テーブルのバージョンを確認する。検出部４６は、確認した共通鍵テーブルのバージョンが、記憶部４４に記憶した共通鍵テーブルのバージョンよりも前であることを検出する。ＭＡＣフレーム処理部２６は、検出数が単位期間において所定回数以上であれば、記憶部４４において記憶した共通鍵テーブルが格納されたパケット信号を生成する。ＭＡＣフレーム処理部２６は、生成したパケット信号を報知する。
【選択図】図２

Description

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

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

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

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

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

また、暗号化のための鍵を更新する場合、これまではユニキャスト通信を前提としていたので、複数の状態を遷移させることが容易であった。ブロードキャスト通信を使用する場合、異なった状態の端末装置が存在すれば、共通した暗号鍵の使用が困難になる。また、新たな暗号鍵の配布のためにトラヒックが増加するが、周波数利用効率の悪化を抑制させたい。また、新たな暗号鍵を使用可能な端末装置が存在すれば、新たな暗号鍵を使用不可能な端末装置も存在する。その結果、すべての端末装置に対して、新たな暗号鍵を使用させることは困難である。一方、通信システムの安全性を向上させるためには、新たな暗号鍵の使用が好ましい。

本発明はこうした状況に鑑みてなされたものであり、その目的は、ブロードキャスト通信に適した暗号鍵の使用技術を提供することにある。

上記課題を解決するために、本発明のある態様の基地局装置は、共通鍵暗号方式における共通鍵によって生成した電子署名が添付されたパケット信号を報知すべき端末装置間の通信を制御する基地局装置であって、端末装置間の通信に使用可能な共通鍵が複数種類示された共通鍵テーブルを記憶する記憶部と、端末装置から報知されたパケット信号を受信する受信部と、受信部において受信したパケット信号に添付された電子署名を生成するための共通鍵が含まれた共通鍵テーブルのバージョンを確認する確認部と、確認部において確認した共通鍵テーブルのバージョンが、記憶部に記憶した共通鍵テーブルのバージョンよりも前であることを検出する検出部と、検出部における検出数が単位期間において所定回数以上であれば、記憶部において記憶した共通鍵テーブルが格納されたパケット信号を生成する生成部と、生成部において生成したパケット信号を報知する報知部と、を備える。

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

本発明によれば、ブロードキャスト通信に適した暗号鍵の使用技術を提供できる。

本発明の実施例に係る通信システムの構成を示す図である。図１の基地局装置の構成を示す図である。図１の通信システムにおいて規定されるパケット信号に格納されるＭＡＣフレームのフォーマットを示す図である。図１の通信システムにおいて規定されるＭＡＣフレームに格納されるセキュアフレームのフォーマットを示す図である。図２の記憶部に記憶される共通鍵テーブルのデータ構造を示す図である。図１の車両に搭載された端末装置の構成を示す図である。図２の基地局装置におけるパケット信号の送信手順を示すフローチャートである。図２の基地局装置における共通鍵の選択手順を示すフローチャートである。図２の基地局装置における共通鍵テーブルの送信の手順を示すフローチャートである。図２の基地局装置におけるパケット信号の受信手順を示すフローチャートである。図６の端末装置におけるパケット信号の受信手順を示すフローチャートである。本発明の変形例に係る通信システムの構成を示す図である。図１２の基地局装置の構成を示す図である。図１２の通信システムにおいて規定されるパケット信号に格納されるＭＡＣフレームのフォーマットを示す図である。図１２の通信システムにおいて規定されるＭＡＣフレームに格納されるセキュアフレームのフォーマットを示す図である。図１３の記憶部に記憶される共通鍵テーブルのデータ構造を示す図である。図１２の車両に搭載された端末装置の構成を示す図である。図１３の基地局装置におけるパケット信号の送信手順を示すフローチャートである。図１３の基地局装置における共通鍵の選択手順を示すフローチャートである。図１３の基地局装置におけるパケット信号の受信手順を示すフローチャートである。図１７の端末装置におけるパケット信号の受信手順を示すフローチャートである。図１７の端末装置におけるパケット信号の送信手順を示すフローチャートである。図１７の端末装置における共通鍵の選択手順を示すフローチャートである。図２０の基地局装置におけるパケット信号の別の送信手順を示すフローチャートである。図１７の端末装置におけるパケット信号の別の受信手順を示すフローチャートである。

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

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

また、このような通信においてなりすまし等を抑制するために、電子署名が使用される。電子署名を生成するためには、暗号鍵が使用される。本実施例に係る通信システムでは、処理の負荷を考慮し、暗号鍵として共通鍵を使用する。また、共通鍵の漏洩リスクを低減去るために複数の共通鍵を使用する。ひとつの共通鍵をひとつの鍵ＩＤとして管理する。複数の共通鍵を共通鍵テーブルにまとめ、共通鍵テーブルのバージョンは、テーブルＩＤとして管理される。さらに、鍵テーブル内の個々の共通鍵は、共通鍵ＩＤとして管理される。そのため、鍵ＩＤには、テーブルＩＤと、共通鍵ＩＤが含まれる。このように規定されることによって、なりすましが防止されるとともに、処理量の増加および周波数利用効率の悪化が抑制される。

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

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

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

電子署名として、公開鍵暗号方式に基づくデジタル署名が有力である。公開鍵暗号方式に基づく方式として、具体的には、ＲＳＡ、ＤＳＡ、ＥＣＤＳＡ等が使用される。電子署名方式は、鍵生成アルゴリズム、署名アルゴリズム、検証アルゴリズムによって構成される。鍵生成アルゴリズムは電子署名の事前準備に相当する。鍵生成アルゴリズムは、ユーザの公開鍵および秘密鍵を出力する。鍵生成アルゴリズムが実行される度に異なる乱数が選ばれるので、ユーザごとに異なる公開鍵・秘密鍵ペアが割り振られる。各ユーザは、秘密鍵を保管し、公開鍵を公開する。公開鍵は第三者機関である認証局（図せず。）にてデジタル署名を付けた公開鍵証明書の形式で公開される。

署名を作成したユーザは、その署名文に対する署名者とよばれる。署名者は、署名アルゴリズムによって署名文を作成する際、メッセージとともに自分の秘密鍵を入力する。署名者の秘密鍵を知っているのは署名者本人だけのはずなので、電子署名を付したメッセージの作成者を識別する根拠になる。公開鍵証明書と電子署名を付したメッセージを受け取ったユーザである検証者は、検証アルゴリズムを実行することによって、電子署名が正しいか否かを検証する。その際、検証者は検証アルゴリズムに受け取った公開鍵証明書と認証局の公開鍵を入力して署名者の公開鍵の検証を行う。検証アルゴリズムは署名者の公開鍵の正当性の判断を行う。そして正当であると判断されると、検証者は検証アルゴリズムに受け取った電子署名を付したメッセージと署名者の公開鍵を入力する。検証アルゴリズムはメッセージが本当にそのユーザによって作成されたか否かを判定し、その結果を出力する。このような公開の仕組みはＰＫＩ（ＰｕｂｌｉｃｋＫｅｙＩｎｆｒａｓｔｒｕｃｔｕｒｅ）と呼ばれる。

このような公開鍵暗号方式の処理負荷は、一般的に大きい。例えば、交差点近傍では、例えば、１００ｍｓｅｃの間に５００台の端末装置１４からのパケット信号を処理しなければならなくなる。また、通信システム１００において車両１２に搭載された端末装置から報知されるパケット信号には、１００バイト程度のデータが格納される。これに対して、公開鍵暗号方式の公開鍵証明書と電子署名は、２００バイト程度になってしまい、伝送効率の低下が大きくなってしまう。また、公開鍵方式における電子署名の検証の演算処理は大きく、１００ｍｓｅｃの間に５００台の端末装置１４からのパケット信号を処理しようとすると、高機能の暗号演算装置あるいはコントローラを必要になってしまい、端末装置のコストが増加する。これに対して、共通鍵暗号方式を用いた電子署名がある。共通鍵暗号方式では、暗号化に用いる鍵と同じ鍵が復号鍵として使用される。共通鍵方式では、送信側と受信側との間で事前に鍵の共有が必要となる。よって受信側の端末装置にとって復号鍵が既知であり、鍵の証明書が不要になるので、公開鍵暗号方式と比較して伝送効率の悪化が抑制される。また、共通鍵暗号方式は、公開鍵暗号方式と比較して処理量が少ない。代表的な共通鍵暗号方式は、ＤＥＳ、ＡＥＳ（ＡｄｖａｎｃｅｄＥｎｃｒｙｐｔｉｏｎＳｔａｎｄａｒｄ）である。通信システム１００では、伝送負荷および処理負荷を考慮し、暗号方式として共通鍵暗号方式を採用する。なお、公開鍵暗号方式のデジタル署名に対して、共通鍵暗号方式はメッセージ認証と呼ばれる。その際、署名の代わりにＭＡＣ（ＭｅｓｓａｇｅＡｕｔｈｅｎｔｉｃａｔｉｏｎＣｏｄｅ）がメッセージに添付される。このＭＡＣの代表的な方式が、ＣＢＣ−ＭＡＣ（ＣｉｐｈｅｒＢｌｏｃｋＣｈａｉｎｉｎｇＭＡＣ）である。

前述のように共通鍵の漏洩リスクを低減去るために複数の共通鍵を使用する。通信システム１００は、共通鍵はテーブルＩＤで管理される共通鍵テーブルのバージョンアップに対応する。共通鍵テーブルのバージョンアップは、基地局装置１０が、新たな共通鍵テーブルをパケット信号に格納して報知することによってなされる。共通鍵テーブルには、運用開始日時と有効期限が規定されているので、運用開始日時より前に、共通鍵テーブルの報知がなされる。

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

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

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

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

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

図４は、通信システム１００において規定されるセキュアフレームのフォーマットを示す。セキュアフレームは、「ペイロードヘッダ」、「ペイロード」、「署名」が配置される。さらに、ペイロードヘッダには、「メッセージバーション」、「メッセージタイプ」、「鍵ＩＤ」、「発信元種別」、「発信元ＩＤ」、「発信日時」および「ロケーション」が配置される。メッセージバージョンは、セキュアフレームのフォーマットと規定する識別情報である。通信システム１００においては固定値となる。メッセージタイプは、「データ種別」と「データ形式」とリザーブが含まれる。データ種別は、ペイロードに格納されるデータがアプリケーションデータ（＝０）、すなわち、後続のＭＡＣフレーム処理部２６へ出力されるデータであるか、メンテナンスデータ（＝１）、すなわち、検証部４０の内部で処理されるセキュリティ情報であるかを識別するフラグ情報を設定するものとする。
通信システム１００において、メンテナンスデータは、共通鍵テーブルである。データ形式は、ペイロードに格納されるデータのセキュリティに関わる形式、つまり、ペイロードに対する暗号処理を規定するフラグである。ここでは、平文データ（＝０）、署名付きデータ（＝１）、暗号化データ（＝２）を設定するものとする。なお、リザーブは将来に対する予備であり、通信システム１００では使用しない。鍵ＩＤは、電子署名あるいはペイロードの暗号化に使用した共通鍵を特定する識別情報で、テーブルＩＤと共通鍵ＩＤを連結したものである。発信元種別ＩＤは、パケット信号の発信者の種類、すなわち、基地局装置１０（＝３）、救急車や消防車のような緊急車両（優先車両と呼ぶ）に搭載の端末装置（＝２）、その他の車両（一般車両とよぶ）に搭載の端末装置（＝１）および非車両搭載の端末装置（＝０）が設定するものとする。発信元ＩＤは、パケット信号を発信した基地局装置１０あるいは端末装置１４を、一意に特定できる装置毎にユニークな識別情報である。ペイロードは、前述のデータを格納するフィールドであり、交差点情報や道路情報等の端末装置へ通知すべき情報に相当する。また、メッセージタイプのデータ形式が署名付きデータ(＝１)の時、ペイロードヘッダおよびペイロードに対する電子署名、すなわちＭＡＣ値を格納するフィールドである。また、メッセージタイプのデータ形式が暗号化データ(＝２)の時、無効としても良いが、ここでは固定値、ペイロードヘッダの部分の写しなどの受信側特定可能な値、あるいは、ペイロードヘッダまたは／および暗号化前のペイロードに対するハッシュ値（ハッシュ関数による演算結果）、チェックサム、パリティなどの受信側で演算可能な値、あるいは、署名付きデータ(＝１)の時と同様に電子署名を格納するものとする。そして、ペイロードおよび署名をまとめて暗号化する。このようにすることで、復号によって得られた署名に格納された値と、受信側で特定した、あるいは、演算した値とが一致すれば、復号が正常に行われ、ペイロードに格納されているデータ、あるいはペイロードヘッダとペイロードに格納されているデータの正当性が確認できる。各フィード長さは、例えば、ペイロードヘッダが３２バイト、ペイロードが１００バイト（端末装置が報知する場合）あるいは１Ｋバイト（基地局装置が報知する場合）、署名が１６バイトである。通信システム１００では、暗号方式としてＡＥＳ暗号を使用する。そして、メッセージタイプのデータ形式が署名付きデータの場合には、電子署名は、ＣＢＣ−ＭＡＣによって求めたＭＡＣ値を署名に格納する。メッセージタイプのデータ形式が暗号化データの場合には、ペイロードヘッダに対するＭＡＣ値を署名に格納し、ペイロードおよび署名を、ＣＢＣモードで暗号化する。なお、署名にＭＡＣ値を格納する場合は、他の暗号化モード、例えばカウンタモードで暗号化を行うようにしてもよい。図２に戻る。

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

記憶部４４は、通信システム１００に使用可能な共通鍵が複数の共通鍵テーブルを記憶する。図５は、記憶部４４に記憶される共通鍵テーブルのデータ構造を示す。共通鍵テーブルには、複数のバージョンが存在してもよく、それらは、テーブルＩＤとして管理される。図５において、第１テーブルは、テーブルＩＤが「１」である場合に相当し、第２テーブルは、テーブルＩＤが「２」、第Ｍテーブルは、テーブルＩＤが「Ｍ」である。各共通鍵テーブルには、複数の共通鍵が含まれており、各共通鍵は共通鍵ＩＤで管理されている。図５において、第１共通鍵は、共通鍵ＩＤが「１」である場合に相当し、第２共通鍵は、共通鍵ＩＤが「２」である場合に相当する。そのため、ひとつの共通鍵は、テーブルＩＤと共通鍵ＩＤとの組合せによって特定される。また、各共通鍵テーブルに、運用開始日時を設置するＮｏｔＢｅｆｏｒｅが設けられている。第１テーブルの運用開始日時が「２００９．１．１」であり、第２テーブルは、テーブルＩＤが「２００９．３．１」、第Ｍテーブルは、テーブルＩＤが「２０１０．６．１」である。今が、２０１０．５．１であるとすると、第Ｍテーブルは使用することができない。尚、テーブルＩＤは、連続している必要はない。なお、共通鍵テーブルに、ＮｏｔＡｆｔｅｒ（運用終了日時あるいは有効期限）が含まれていてもよい。図２に戻る。

検証部４０は、セキュアフレームを生成する際、記憶部４４を参照して、共通鍵を抽出する。例えば、各共通鍵テーブルには、ＮｏｔＢｅｆｏｒｅとして運用開始日時が規定されており、ＭＡＣフレーム処理部２６は、現在の時刻をもとに、ひとつの共通鍵テーブルを選択する。検証部４０は、運用中の共通鍵テーブルの中から、ＮｏｔＢｅｆｏｒｅに記載される運用開始日時が最も遅い最新の共通鍵テーブルを選択する。さらに、検証部４０は、選択した共通鍵テーブルの中から、ひとつの共通鍵を選択する。この選択は、ランダムになされてもよいし、基地局装置１０に付与された識別番号にしたがってなされてもよい。検証部４０は、メッセージタイプのデータ形式が署名付きデータの場合には、選択した共通鍵を使用して暗号部４２にてペイロードヘッダとペイロードに対する電子署名を演算する。また、メッセージタイプのデータ形式が暗号化データの場合には、暗号部４２にてペイロードと署名を暗号化する。検証部４０は、メッセージタイプのデータ形式が平文データの場合には、生成したセキュアフレームを、そのままＭＡＣフレーム処理部２６へ出力する。なお、ＭＡＣフレーム処理部２６から受け取ったデータを用いてセキュアフレームを生成する場合、メッセージタイプのデータ種別は、アプリケーションデータ（＝０）とする。

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

さらに、検証部４０は、記憶部４４に記憶された共通鍵テーブルを含んだセキュアフレームを生成する。この時、メッセージタイプのデータ種別はメンテナンスデータ（＝１）とする。記憶部４４に記憶された共通鍵テーブルは、運用開始日時前から報知の対象になり運用開始後も報知される。検証部４０は、報知の対象のテーブルＩＤが付与された共通鍵テーブルを選択し、選択した共通鍵テーブルが格納されたセキュアフレームを生成する。その際、メッセージタイプのデータ形式を暗号化データとする。生成したセキュアフレームを、そのままＭＡＣフレーム処理部２６へ出力する。

検出部４６は、検証部４０において正当であると判定された電子署名あるいは暗号化に使用された共通鍵テーブルのテーブルＩＤを受けつける。これは、受信したパケット信号で使用されていた共通鍵が含まれた共通鍵テーブルのバージョンを確認することに相当する。また、検出部４６は、当該パケット信号の送信元になる端末装置の識別番号を取得してもよい。

検出部４６は、受け付けたテーブルＩＤと、記憶部４４に記憶された最新の共通鍵テーブルのテーブルＩＤとを比較する。検出部４６は、前者のテーブルＩＤが、後者のテーブルＩＤと一致しないことを検出した場合、テーブルＩＤごとに検出数を計数する。検出部４６は、いずれかの検出数が単位期間において所定回数以上であれば、最新の共通鍵テーブルの報知を決定する。ここで、検出数として、端末装置の識別番号の数も計数されてもよい。同一の端末装置から複数のパケット信号を受信することを加味して、単位時間あたりの検出回数を補正するためである。また、所定時間内の検出割合を加味して判断するようにしても良い。

報知が決定すると、検証部４０は報知の対象となる共通鍵テーブル、すなわち、運用中の最新の共通鍵テーブルを、報知を決定した計数の対象となったテーブルＩＤで特定される共通鍵テーブルの共通鍵で暗号化したセキュアフレームを生成して、パケット信号として報知する。

なお、共通鍵テーブルの報知に、記憶部４４に記録されている運用中の共通鍵テーブルの共通鍵を使用するとしたが、共通鍵テーブル報知用に用意された別の共通鍵あるいは共通鍵テーブルを使用してもよい。これは、テーブルマスタ鍵を使用することに相当する。また、端末装置１４から送信された共通鍵あるいは公開鍵によって暗号化しても良い。この場合、共通鍵テーブルを受信できる端末装置１４は、暗号化に用いた鍵を送信した端末装置１４に限られる。さらに、共通鍵テーブルを送信すべき端末装置を限定してもよい。例えば、端末装置が使用している共通鍵テーブルの鍵、あるいはテーブルマスタ鍵に加えて、端末装置を識別するための端末ＩＤによって、共通鍵テーブルが暗号化される。また、別の例では、端末装置が使用している共通鍵テーブルの鍵、あるいはテーブルマスタ鍵に加えて、端末装置を識別するための端末ＩＤによって送信鍵が暗号化されるとともに、送信鍵によって共通鍵テーブルが暗号化される。その結果、送信鍵と、送信鍵によって暗号化された共通鍵テーブルが報知される。これによって、個別に共通鍵テーブルを送信する場合であっても、通信コストや処理負担を軽減できる。

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

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

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

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

検証部６２は、検証部４０と同様に、セキュアフレームの生成および解釈を行う。また、受け取ったセキュアフレームのペイローロードが、セキュリティ情報の場合、すなわち、共通鍵テーブルが含まれる時、その共通鍵テーブルが記憶部６６に未記録の場合には、記憶部６６に受け取った共通鍵テーブルを記憶させる。記憶部６６に空きがある場合、受け取った共通鍵テーブルをそのまま追記する。記憶部６６に空きがない場合、記憶部６６に記憶されている共通鍵テーブルの内、運用開始日時が最も古いものを書き換える。なお。検証部６２は、記憶部６６に記憶されている共通鍵テーブルを送信することはない。

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

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

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

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

一方、共通鍵テーブルを送信する場合（Ｓ１０のＹ）、検証部４０は、記憶部４４より送信する共通鍵テーブルを読み出し、検出部読み出した共通鍵テーブルをペイロードに格納したセキュアフレームを生成する（Ｓ２８）。そして、送信する共通鍵テーブルに対応した共通鍵テーブルから、ランダムに共通鍵を１つ選択する（Ｓ３０）。共通鍵を選択するとセキュアフレームの鍵ＩＤには、対象の共通鍵テーブルのテーブルＩＤと選択された共通鍵ＩＤが格納される。以降、ステップＳ２４、ステップＳ２６を経て、暗号化した共通鍵テーブルを含むセキュアフレームを、パケット信号として報知する（Ｓ２２）。

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

図９は、基地局装置１０の検出部４６における共通鍵テーブルの報知決定手順を示すフローチャートである。テーブルＩＤが最新でなければ（Ｓ７０のＮ）、検出部４６は、該当テーブルＩＤを計数する（Ｓ７２）。単位時間の回数がＬ以上であれば（Ｓ７４のＹ）、検出部４６は、共通鍵テーブルの送信を決定する（Ｓ７６）。テーブルＩＤが最新である場合（Ｓ７０のＹ）、あるいは単位時間の回数がＬ以上でない場合（Ｓ７４のＮ）、処理は終了される。

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

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

図１１は、端末装置１４におけるパケット信号の送信手順を示すフローチャートである。検証部６２は、処理部よりデータを取得し、セキュアフレームを生成する（Ｓ１３０）。メッセージタイプが平文でない場合（Ｓ１３２のＮ）、つまりメッセージタイプが署名付きあるいは暗号化である場合、検証部６２は、共通鍵を選択する（Ｓ１３４）。メッセージタイプが署名付きである場合（Ｓ１３６のＹ）、検証部６２は、選択した共通鍵にて電子署名を演算し、署名データに格納する（Ｓ１３８）。変復調部５４、ＲＦ部５２は、パケット信号を報知する（Ｓ１４４）。メッセージタイプが署名付きでない場合（Ｓ１３６のＮ）、つまりメッセージタイプが暗号化である場合、検証部６２は、ペイロードヘッダのＭＡＣ値を演算し、署名データに格納する（Ｓ１４０）とともに、選択した暗号鍵にて暗号化を実行する（Ｓ１４２）。変復調部５４、ＲＦ部５２は、パケット信号を報知する（Ｓ１４４）。メッセージタイプが平文である場合（Ｓ１３２のＹ）、変復調部５４、ＲＦ部５２は、パケット信号を報知する（Ｓ１４４）。

本発明の実施例によれば、端末装置にて使用されている共通鍵テーブルが旧バージョンであることを検出し、かつ検出数が所定回数以上である場合に、新たな共通鍵テーブルを送信するので、送信回数を制限できる。また、送信回数が制限されるので、トラヒックの増加を抑制できる。また、トラヒックの増加が抑制されるので、ブロードキャスト通信において共通鍵を効率的に配布できる。また、旧バージョンの共通鍵を使用している端末装置数が増加すれば、最新バージョンの共通鍵テーブルを報知するので、共通鍵テーブルを更新できる。また、最新バージョンの共通鍵が使用されるので、安全性を向上できる。

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

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

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

図１２は、本発明の変形例に係る通信システム１１００の構成を示す。これは、ひとつの交差点を上方から見た場合に相当する。通信システム１１００は、基地局装置１０１０、車両１０１２と総称される第１車両１０１２ａ、第２車両１０１２ｂ、第３車両１０１２ｃ、第４車両１０１２ｄ、第５車両１０１２ｅ、第６車両１０１２ｆ、第７車両１０１２ｇ、第８車両１０１２ｈ、ネットワーク１２０２を含む。通信システム１１００、基地局装置１０１０、車両１０１２、ネットワーク１２０２は、図１の通信システム１００、基地局装置１０、車両１２、ネットワーク２０２に対応する。ここでは、差異を中心に説明する。通信システム１１００では、通信においてなりすまし等を抑制するために、電子署名が使用される。

通信システム１１００で使用される共通鍵が１種類だけであれば、悪意あるユーザであっても、共通鍵の入手が容易になる。これに対応し、鍵の漏えいリスクを低減するために複数の共通鍵を使用するため、通信システム１１００では、予め定めた数の共通鍵を１つの共通鍵テーブルにまとめる。また、共通鍵テーブルを複数備えて、必要に応じて切り換えて使用する。ひとつの共通鍵は、共通鍵テーブルを識別するテーブルＩＤと、テーブル内の共通鍵を識別する共通鍵ＩＤによって特定される。共通鍵テーブルには、運用開始日時（ＮｏｔＢｅｆｏｒｅ）が規定されている。したがって、新たに運用を開始する共通鍵テーブルは、運用開始日時より前に、基地局装置１０１０から路車間通信により報知したり、事前に端末装置に記録しておくことで端末装置間、あるいは、基地局装置１０１０と端末装置間で共有が図られる。なお、共通鍵テーブルは、セキュリティ情報に含まれる。

通信システム１１００では、データの正当性が要求されるデータ、すなわち車車間通信における自車両情報、路車間通信における交差点情報や渋滞情報などのデータは、データ自体の暗号化を行わず、共通鍵を使用して電子署名を生成し、データに電子署名を添付させたパケット信号を報知する。パケット信号には、電子署名の生成のために使用されたテーブルＩＤと共通鍵ＩＤとが含まれる。このように規定されることによって、なりすましが防止される。また、情報の秘匿性を要求されるデータ、すなわち路車間通信におけるセキュリティ情報などのデータは、データ自身を暗号化したパケット信号を報知する。パケット信号には、暗号化のために使用されたテーブルＩＤと共通鍵ＩＤとが含まれる。このようにすることで、データの信頼性・安全性を補償するとともに、処理量の増加および伝送負荷の悪化が抑制される。

図１３は、基地局装置１０１０の構成を示す。基地局装置１０１０は、アンテナ１０２０、ＲＦ部１０２２、変復調部１０２４、ＭＡＣフレーム処理部１０２６、検証部１０４２、処理部１０２８、制御部１０３０、ネットワーク通信部１０３２、センサ通信部１０３４を含む。検証部１０４２は、暗号部１０４４と記憶部１０４６を含む。アンテナ１０２０、ＲＦ部１０２２、変復調部１０２４、ＭＡＣフレーム処理部１０２６、検証部１０４２、処理部１０２８、制御部１０３０、ネットワーク通信部１０３２、センサ通信部１０３４は、図２のアンテナ２０、ＲＦ部２２、変復調部２４、ＭＡＣフレーム処理部２６、検証部４０、処理部２８、制御部３０、ネットワーク通信部３２、センサ通信部３４に対応する。ここでは、差異を中心に説明する。

図１４は、通信システム１１００において規定されるパケット信号に格納されるＭＡＣフレームのフォーマットを示す。これは、図３と同様であるので、説明を省略する。図１５は、通信システム１１００において規定されるセキュアフレームのフォーマットを示す。これは、図４と同様であるので、説明を省略する。図１６は、記憶部１０４６に記憶される共通鍵テーブルのデータ構造を示す。ここで、ＮｅｔＢｅｆｏｒｅがなくてもよい。これは、図５と同様であるので、説明を省略する。

記憶部１０４６は、さらに受信したパケット信号に使用されていた共通鍵テーブルのテーブルＩＤを記録する。記録するテーブルＩＤは、単位時間毎に受信したパケット信号で使用されていたテーブルＩＤの最も頻度の高いものを特定するために使用する。したがって、時間経過あるいは記憶部１０４６の記憶可能な鍵テーブルの数の制限によって自動的に破棄される構成でよい。

検証部１０４２は、セキュアフレームを生成する際、記憶部１０４６を参照して、共通鍵を抽出する。各共通鍵テーブルには、ＮｏｔＢｅｆｏｒｅが規定されており、検証部１０４２は、現在の日時をもとに、すでに運用が開始されている共通鍵テーブルのひとつを選択する。複数の共通鍵テーブルの運用が開始されている場合、検証部１０４２は、ＮｏｔＢｅｆｏｒｅが最も大きな値の共通鍵テーブル、すなわち最も運用開始日時が新しい共通鍵テーブルを選択する。検証部１０４２は、所定期間において所定回数以上、共通鍵テーブルのテーブルＩＤが運用開始日時の古い共通鍵テーブルに対応する場合、電子署名を生成するために、最も運用開始日時が新しい共通鍵テーブルの代わりに運用開始日時の古い共通鍵テーブルを使用する。なお、ＮｅｔＢｅｆｏｒｅがない場合には、最も新しく格納された共通鍵テーブルを使用するものとすればよい。

さらに、検証部１０４２は、記憶部１０４６に記憶された共通鍵テーブルを含んだセキュアフレームを生成する。記憶部１０４６に記憶された共通鍵テーブルは、運用開始日時前から報知の対象になり運用開始後も報知される。そして、さらに未来に運用を開始するように運用開始日時が設定され共通鍵テーブルの報知が開始されると報知の対象から除外される。検証部１０４２は、記憶部１０４６に記憶された共通鍵テーブルのそれぞれに対して、報知の対象になっているかを管理する。検証部１０４２は、報知の対象のテーブルＩＤが付与された共通鍵テーブルを選択し、選択した共通鍵テーブルが格納されたセキュアフレームを生成する。その際、メッセージタイプを暗号化データとする。暗号化に用いる共通鍵テーブルは、記憶部１０４６に記憶された共通鍵テーブルのうち、報知対象の共通鍵テーブルの鍵の運用開始日時以前に、運用が開始されている共通鍵テーブルから選択するものとする。報知のタイミングは任意でよい。ただし、運用開始後の報知のタイミングは、周辺の端末装置１０１４からのパケット信号を受信して、当該共通鍵テーブルが使用されていない時に報知するようにしてもよい。

なお、共通鍵テーブルの報知用に別の共通鍵が規定されていてもよい。また、端末装置１０１４から送信された共通鍵あるいは公開鍵によって暗号化してもよい。この場合、共通鍵テーブルを受信できる端末装置１０１４は、暗号化に用いた鍵を送信した端末装置１０１４に限られる。

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

通知部１０７０は、受信したパケット信号に添付された電子署名を生成している共通鍵が、記憶部１０６６に未記録の共通鍵テーブルに含まれていることを検証部１０６２によって検出された場合、その旨を運転者に通知する。

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

図１９は、基地局装置１０１０における共通鍵の選択手順を示すフローチャートである。検証部１０４２は、メッセージタイプが、著名付きデータあるいは暗号化データの場合、記憶部１０４６に記録され、運用開始が開始されている共通鍵テーブルの１つを選択し、さらに、選択した共通鍵テーブルから、１つの鍵を選択する。記憶部１０４６に記録されている端末装置１０１４から受信したパケット信号で使用されていた共通鍵が含まれる共通鍵テーブルのテーブルＩＤが記録されている。検証部１０４２は、この記録に基づいて単位時間内に最も高い頻度で使用されていた共通鍵テーブルを確認する（Ｓ１０３０）。最も高い頻度で使用されていた共通鍵テーブルが、最新の共通鍵テーブル、すなわち運用が開始されている共通鍵テーブルの中で、運用開始日時が最も遅い共通鍵テーブルの場合（Ｓ１０３０のＹ）、最新の共通鍵テーブルを選択する（Ｓ１０３２）。最も高い頻度で使用されていた共通鍵テーブルが、最新の共通鍵テーブルでない場合（Ｓ１０３０のＮ）、その共通鍵テーブルの使用頻度が、予め定めた所定の割合を越えて使用されているかを確認する（Ｓ１０３４）。所定の割合を超えていない場合（Ｓ１０３４のＮ）、最新の共通鍵テーブルを選択する（Ｓ１０３２）。所定の割合を超えている場合（Ｓ１０３４のＹ）、最も使用頻度の高い共通鍵テーブルを選択する（Ｓ１０３６）。そして、運用開始を開始している中で最新の共通鍵テーブルの報知要求を出す（Ｓ１０３８）。これは、周辺の端末装置１０１４の多くが、未だ運用か開始されている最新の共通鍵テーブルを持っていないと推定されるため、これを周辺の端末装置１０１４に報知することを目的とする。使用する共通鍵テーブルが、選択されると、検証部１０４２は、選択された鍵テーブルから、ランダムに１つの共通鍵を選択する（Ｓ１０４０）。そして、選択した共通鍵テーブルのテーブルＩＤと、選択した共通鍵の共通鍵ＩＤを、セキュアフレームの鍵ＩＤに格納し（Ｓ１０４２）、記憶部１０４６より選択した鍵を読み出す（Ｓ１０４４）。

図１８に戻る。検証部１０４２は、暗号部１０４４にて、選択した共通鍵を用いてペイロードヘッダおよびペイロードに対する電子署名を演算し、その値をセキュアフレームの署名に格納する（Ｓ１０１８）。次いで、ＭＡＣフレーム処理部１０２６、変復調部１０２４、ＲＦ部１０２２、アンテナ１０２０を介して、署名を付けたセキュアフレームを、パケット信号として報知する（Ｓ１０２０）。メッセージタイプが暗号化データの場合（Ｓ１０１４の暗号化）、共通鍵を選択する（Ｓ１０２４）。共通鍵の選択は、Ｓ１０１６と同じため説明を割愛する。共通鍵が選択されると、検証部１０４２は、暗号部１０４４にて、ペイロートのＭＡＣ値を求め、セキュアフレームの署名に格納する（Ｓ１０２６）。次いで、選択した共通鍵を用いてペイロードヘッダおよび署名を暗号化する（Ｓ１０２８）。そして、ＭＡＣフレーム処理部１０２６、変復調部１０２４、ＲＦ部１０２２、アンテナ１０２０を介して、暗号化したセキュアフレームを、パケット信号として報知する（Ｓ１０２０）。一方、共通鍵テーブルを送信する場合（Ｓ１０１０のＹ）、検証部１０４２は、記憶部１０４６より送信する共通鍵テーブルを読み出し、読み出した共通鍵テーブルをペイロードに格納したセキュアフレームを生成する（Ｓ１０２２）。以降の処理は、メッセージタイプが暗号化データの場合と同じく、ステップＳ１０２４、ステップＳ１０２６、ステップＳ１０２８を経て、暗号化した共通鍵テーブルを含むセキュアフレームを、パケット信号として報知する（Ｓ１０２０）。

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

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

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

図２２は、端末装置１０１４におけるパケット信号の送信手順を示すフローチャートである。検証部１０６２は、データを取得し、セキュアフレームを生成する（Ｓ１１４０）。メッセージタイプが署名付きである場合（Ｓ１１４２の署名付き）、検証部１０６２は、共通鍵を選択し（Ｓ１１４４）、選択した共通鍵にて電子署名を演算し、署名データに格納する（Ｓ１１４６）。その後、変復調部１０５４、ＲＦ部１０５２、アンテナ１０５０は、パケット信号を報知する（Ｓ１１５４）。メッセージタイプが暗号化である場合（Ｓ１１４２の暗号化）、検証部１０６２は、共通鍵を選択し（Ｓ１１４８）、ペイロードヘッダのＭＡＣ値を演算し、署名データに格納する（Ｓ１１５０）。検証部１０６２は、選択した暗号鍵にて暗号化を実行し（Ｓ１１５２）、変復調部１０５４、ＲＦ部１０５２、アンテナ１０５０は、パケット信号を報知する（Ｓ１１５４）。メッセージタイプが平文である場合（Ｓ１１４２の平文）、変復調部１０５４、ＲＦ部１０５２、アンテナ１０５０は、パケット信号を報知する（Ｓ１１５４）。

図２３は、端末装置１０１４における共通鍵の選択手順を示すフローチャートである。所定時間内に最も使用頻度の高い共通鍵テーブルが最新である場合（Ｓ１１７０のＹ）、あるいは所定時間内に最も使用頻度の高い共通鍵テーブルが最新でなくても（Ｓ１１７０のＮ）、最も使用頻度の高い共通鍵テーブルが所定割合以上使われていない場合（Ｓ１１７２のＮ）、検証部１０６２は、運用を開始している中で運用開始日時が最新の共通鍵テーブルを選択する（Ｓ１１７４）。最も使用頻度の高い共通鍵テーブルが所定割合以上使われている場合（Ｓ１１７２のＹ）、検証部１０６２は、最も使用回数の多い共通鍵テーブルを選択する（Ｓ１１７６）。検証部１０６２は、当該鍵テーブルからランダムに共通鍵を選択し（Ｓ１１７８）、セキュアフレームにテーブルＩＤと共通鍵ＩＤを格納する（Ｓ１１８０）。検証部１０６２は、記憶部１０６６よりテーブルＩＤと共通鍵ＩＤにて特定される鍵を取得する（Ｓ１１８２）。

本発明の変形例によれば、新しい運用開始日時の共通鍵テーブルを優先的に使用するので、安全性を確保できる。また、古い運用開始日時の共通鍵テーブルが多く使用されている場合に、新しい運用開始日時の共通鍵テーブルの代わりに古い運用開始日時の共通鍵テーブルを使用するので、多くの端末装置において共通した共通鍵を使用できる。また、運用開始日時が異なった共通鍵テーブルを切りかえるので、ブロードキャスト通信がなされている場合に、安全性を確保しながら、共通した共通鍵を使用できる。

図２４は、基地局装置１０１０における別のパケット信号の送信手順を示すフローチャートである。基地局装置１０１０から端末装置１０１４に、共通鍵テーブルを送信する場合の手順が異なっている。共通鍵テーブルは、送信用の鍵を用いて暗号化し、メッセージタイプを署名付きデータとして送信する。共通鍵テーブルを送信しない場合（Ｓ１２００のＮ）、検証部１０４２は、処理部１０２８よりデータと、データを送信するメッセージタイプを受け取る。そして、受け取ったデータをペイロードに格納したセキュアフレームを生成する（Ｓ１２０２）。次いで、メッセージタイプが平文データの場合（Ｓ１２０４の平文）、ＭＡＣフレーム処理部１０２６、変復調部１０２４、ＲＦ部１０２２、アンテナ１０２０を介して、そのままセキュアフレームを、パケット信号として報知する（Ｓ１２１８）。メッセージタイプが署名付きデータの場合（Ｓ１２０４の署名付き）、共通鍵を選択する（Ｓ１２１４）。検証部１０４２は、暗号部１０４４にて、選択した共通鍵を用いてペイロードヘッダおよびペイロードに対する電子署名を演算し、その値をセキュアフレームの署名に格納する（Ｓ１２１６）。次いで、ＭＡＣフレーム処理部１０２６、変復調部１０２４、ＲＦ部１０２２、アンテナ１０２０を介して、署名を付けたセキュアフレームを、パケット信号として報知する（Ｓ１２１８）。

メッセージタイプが暗号化データの場合（Ｓ１２０４の暗号化）、共通鍵を選択する（Ｓ１２１０）。検証部１０４２は、選択した共通鍵を用いてペイロードヘッダおよび署名を暗号化する（Ｓ１２１２）。そして、ＭＡＣフレーム処理部１０２６、変復調部１０２４、ＲＦ部１０２２、アンテナ１０２０を介して、暗号化したセキュアフレームを、パケット信号として報知する（Ｓ１２１８）。一方、共通鍵テーブルを送信する場合（Ｓ１２００のＹ）、検証部１０４２は、記憶部１０４６より送信する共通鍵テーブルを読み出し、読み出した共通鍵テーブルを専用鍵で暗号化する（Ｓ１２０６）。検証部１０４２は、暗号化共通鍵テーブルを含むセキュアフレームを生成する（Ｓ１２０８）。以降の処理は、メッセージタイプが署名付きの場合と同じく、ステップＳ１２１４、ステップＳ１２１６を経て、パケット信号として報知する（Ｓ１２１８）。

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

本発明の変形例によれば、電子署名の値を演算するために共通鍵を使用するので、公開鍵を使用する場合と比較して処理量を低減できる。また、処理量が低減されるので、処理可能なパケット信号数を増加できる。また、電子署名の値を演算するために共通鍵を使用するので、公開鍵を使用する場合と比較して伝送効率を向上できる。また、位置情報等のデータに対しては暗号化を実行しないので、処理量を低減する。一方、共通鍵テーブルには暗号化を実行するので、安全性を向上できる。また、ブロードキャスト通信がなされている場合に、安全性を確保しながら、共通した暗号鍵を使用できる。

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

本発明の実施例において、検出部４６は、共通鍵テーブルのテーブルごとに検出処理を実行、検出数が所定回数、あるいは、検出回数の割合が所定の割合以上になった場合に、運用中の最新の共通鍵テーブルをパケット信号として報知するものとしたが、検出の対象となった共通鍵テーブルの次に新しい共通鍵テーブルを、パケット信号として報知しても良い。

本発明の実施例において、通信システム１００は、共通鍵テーブルの運用開始日時や有効期限を設定している。しかしながらこれに限らず例えば、共通鍵テーブルの運用開始日時や有効期限が設定されていなくてもよい。その際、基地局装置１０、端末装置１４は、最新の共通鍵テーブルを常に使用する。本変形例によれば、共通鍵テーブルのサイズを低減できる。

また、端末装置１４は、パケット信号を受信した際に、保持するすべての共通鍵テーブルを使用して復号・検証を実行してもよい。端末装置１４は、その結果をアプリケーションに通知する。例えば、検証が成功したこと、古い共通鍵テーブルによって検証が成功したこと、検証が失敗したこと、不定であること等が通知される。

本発明の実施例において、基地局装置１０が共通鍵テーブルを送信している。しかしながらこれに限らず例えば、基地局装置１０が共通鍵テーブルを送信しなくてもよい。その際、基地局装置１０とは別に、共通鍵テーブル配信用の基地局装置が設けられてもよい。

本発明の実施例において、検出部４６は、確認部から受けつけたテーブルＩＤが、記憶部４４に記憶された最新の共通鍵テーブルのテーブルＩＤよりも前であることを検出した場合、検出数を計数している。しかしながらこれに限らず例えば、さらに、検出部４６は、共通鍵テーブルのバージョンごとに検出処理を実行してもよい。その場合、処理部２６は、所定回数以上になった検出数に対応した共通鍵テーブルのバージョンが、記憶部４４に記憶した最新の共通鍵テーブルのバージョンよりも２世代以上前であっても、最新バージョンの共通鍵テーブルが格納されたパケット信号を生成してもよい。本変形例によれば、最新バージョンの共通鍵テーブルのみを送信するので、トラヒック量を低減できる。

本実施例は、次の項目によって特徴付けられてもよい。
（項目１）
通信に使用可能な共通鍵が複数種類示された第１の共通鍵テーブルと、第１の共通鍵テーブルの運用開始日時よりも新しい運用開始日時の第２の共通鍵テーブルとを記憶する記憶部と、
前記記憶部において記憶した第２の共通鍵テーブルに含まれた共通鍵によって電子署名を生成するとともに、電子署名が添付されたパケット信号を生成する処理部と、
前記処理部において生成したパケット信号を報知する通信部とを備え、
前記通信部は、他の通信装置から報知されたパケット信号を受信し、
前記処理部は、前記通信部において受信したパケット信号に添付された電子署名を生成している共通鍵が第１の共通鍵テーブルに含まれているかを調査し、所定期間において所定回数以上、第１の共通鍵テーブルに含まれた共通鍵を検出した場合、電子署名を生成するために、第２の共通鍵テーブルの代わりに第１の共通鍵テーブルを使用することを特徴とする通信装置。

（項目２）
前記通信部において受信したパケット信号に添付された電子署名を生成している共通鍵が、前記記憶部に未記録の共通鍵テーブルに含まれていることを前記処理部によって検出された場合、その旨をユーザに通知する通知部をさらに備えることを特徴とする項目１に記載の通信装置。

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

Claims

車載器からの車車間通信および路側機からの路車間通信を実行する車載器であって、
複数の共通鍵を含む共通鍵テーブルを記憶する記憶部と、
車車間通信において、
セキュアフレームを規定する識別情報であるバージョンと、
平文データ、署名付きデータ、または暗号化データを設定可能なメッセージタイプと、
ＭＡＣ（ＭｅｓｓａｇｅＡｕｔｈｅｎｔｉｃａｔｉｏｎＣｏｄｅ）生成、またはＭＡＣ生成および暗号化に使用される、前記共通鍵テーブルに含まれる共通鍵を特定する鍵ＩＤと、
発信元として路側機、緊急車両に搭載された車載器、または一般車両に搭載された車載器を設定可能な発信元種別と、
発信元の識別情報である発信元ＩＤと、
当該車載器を搭載した車両の自車両情報を含むアプリケーションデータと、
前記アプリケーションデータを含むＭＡＣ対象に対して前記鍵ＩＤで特定される共通鍵を用いて生成されたＭＡＣと、
を含む通信データを生成する生成部と、
生成された通信データを、ＯＦＤＭ（ＯｒｔｈｏｇｏｎａｌＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ）変調方式のパケット信号としてブロードキャストする送信部と、を備え、
前記生成部は、前記メッセージタイプに暗号化データを設定したとき前記アプリケーションデータ及び前記ＭＡＣを含む暗号化対象を、前記記憶部に記憶されている前記鍵ＩＤで特定される共通鍵を用いて暗号化することを特徴とする車載器。
前記共通鍵テーブルは複数存在し、
前記鍵ＩＤは、前記共通鍵テーブルを識別するテーブルＩＤと前記共通鍵テーブル内の個々の共通鍵を識別する共通鍵ＩＤとを含み、
前記生成部は、前記記憶部に記憶されている複数の共通鍵テーブルから一つの鍵テーブルを選択し、選択した共通鍵テーブルの中から、一つの共通鍵を選択して用いることを特徴とする請求項１に記載の車載器。