JP6074824B2 - 端末装置 - Google Patents
端末装置 Download PDFInfo
- Publication number
- JP6074824B2 JP6074824B2 JP2015241036A JP2015241036A JP6074824B2 JP 6074824 B2 JP6074824 B2 JP 6074824B2 JP 2015241036 A JP2015241036 A JP 2015241036A JP 2015241036 A JP2015241036 A JP 2015241036A JP 6074824 B2 JP6074824 B2 JP 6074824B2
- Authority
- JP
- Japan
- Prior art keywords
- common key
- unit
- key table
- base station
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/068—Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
- H04L9/16—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms the keys or algorithms being changed during operation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/80—Wireless
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/84—Vehicles
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Traffic Control Systems (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Description
本発明は、通信技術に関し、特に所定の情報が含まれた信号を送受信する端末装置に関する。
交差点の出会い頭の衝突事故を防止するために、路車間通信の検討がなされている。路車間通信では、路側機と車載器との間において交差点の状況に関する情報が通信される。路車間通信では、路側機の設置が必要になり、手間と費用が大きくなる。これに対して、車車間通信、つまり車載器間で情報を通信する形態であれば、路側機の設置が不要になる。その場合、例えば、GPS(Global Positioning System)等によって現在の位置情報をリアルタイムに検出し、その位置情報を車載器同士で交換しあうことによって、自車両および他車両がそれぞれ交差点へ進入するどの道路に位置するかを判断する(例えば、特許文献1参照)。
無線通信は、有線通信に比較して通信の傍受が容易になるので、通信内容の秘匿性を確保することが困難になる。また、ネットワーク経由で機器の制御を行う場合、第三者のなりすましにより不正な通信による操作が行われるおそれがある。無線通信において、通信内容の秘匿性を確保するためには、通信データを暗号化し、かつ、暗号化の際に使用する鍵を定期的に更新する必要がある。例えば、ネットワーク装置のそれぞれは、暗号鍵の
更新の際、更新前に使用されている旧暗号鍵によって暗号化が行われたデータのみの送受信が可能な初期状態にある。この状態から、各装置は、旧暗号鍵および更新後の新暗号鍵によって暗号化が行われた双方のデータの送受信を行うことが可能で、新暗号鍵によって暗号化が行われたデータの送受信に関しては動作未確認の状態に移行する。さらに、各装置は、旧暗号鍵、新暗号鍵の双方で暗号化されたデータの送受信が可能であり、新暗号鍵で暗号化されたデータの送受信に関しても動作確認済みの状態に遷移する。最終的に、各装置は、鍵更新完了後の新暗号鍵によって暗号化されたデータのみの送受信が可能な状態に順次遷移する(例えば、特許文献2参照)。
更新の際、更新前に使用されている旧暗号鍵によって暗号化が行われたデータのみの送受信が可能な初期状態にある。この状態から、各装置は、旧暗号鍵および更新後の新暗号鍵によって暗号化が行われた双方のデータの送受信を行うことが可能で、新暗号鍵によって暗号化が行われたデータの送受信に関しては動作未確認の状態に移行する。さらに、各装置は、旧暗号鍵、新暗号鍵の双方で暗号化されたデータの送受信が可能であり、新暗号鍵で暗号化されたデータの送受信に関しても動作確認済みの状態に遷移する。最終的に、各装置は、鍵更新完了後の新暗号鍵によって暗号化されたデータのみの送受信が可能な状態に順次遷移する(例えば、特許文献2参照)。
IEEE802.11等の規格に準拠した無線LAN(Local Area Network)では、CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)とよばれるアクセス制御機能が使用されている。そのため、当該無線LANでは、複数の端末装置によって同一の無線チャネルが共有される。このようなCSMA/CAでは、端末装置間の距離や電波を減衰させる障害物の影響などによって、互いの無線信号が到達しない状況、つまりキャリア・センスが機能しない状況が発生する。キャリア・センスが機能しない場合、複数の端末装置から送信されたパケット信号が衝突する。
一方、無線LANを車車間通信に適用する場合、不特定多数の端末装置へ情報を送信する必要があるために、信号はブロードキャストにて送信されることが望ましい。しかしながら、交差点などでは、車両数の増加、つまり端末装置数の増加がトラヒックを増加させることによって、パケット信号の衝突の増加が想定される。その結果、パケット信号に含まれたデータが他の端末装置へ伝送されなくなる。このような状態が、車車間通信において発生すれば、交差点の出会い頭の衝突事故を防止するという目的が達成されなくなる。さらに、車車間通信に加えて路車間通信が実行されれば、通信形態が多様になる。その際、車車間通信と路車間通信との間における相互の影響の低減が要求される。
また、暗号化のための鍵を更新する場合、これまではユニキャスト通信を前提としていたので、複数の状態を遷移させることが容易であった。ブロードキャスト通信を使用する場合、異なった状態の端末装置が存在すれば、共通した暗号鍵の使用が困難になる。通信の安全性を確保するために、暗号鍵の更新が望まれる。ここで、悪意あるユーザが多く存在する可能性が高いエリアでは、低いエリアよりも暗号鍵の更新周期を短くする必要がある。すべてのエリアにおいて暗号鍵の更新周期を短くすればよいが、新たな暗号鍵の配布のためにトラヒックが増加してしまう。一方、周波数利用効率の悪化を抑制することも要求される。
本発明はこうした状況に鑑みてなされたものであり、その目的は、エリアに応じて暗号鍵を効率的に配布する技術を提供することにある。
上記課題を解決するために、本発明のある態様の端末装置は、車両に搭載され、基地局装置との間での通信を行う端末装置であって、端末装置間の通信を制御する基地局装置から報知されたパケット信号であって、かつ共通鍵が複数種類示された第1の共通鍵テーブルを記憶するとともに、第1の共通鍵テーブルとは異なった第2の共通鍵テーブルを記憶した基地局装置において、記憶した第2の共通鍵テーブルに含まれた共通鍵を使用して生成されたパケット信号を受信する受信部と、基地局装置との間で共有される第2の共通鍵テーブルを記憶する記憶部と、受信部が受信したパケット信号を検証する検証部とを備える。受信部において受信したパケット信号の報知元になる基地局装置は、記憶した第1の共通鍵テーブルが格納されたパケット信号も生成しており、検証部は、受信部が受信したパケット信号に第1の共通鍵テーブルが含まれる場合、第1の共通鍵テーブルが本端末装置の記憶部に未記録であれば、当該第1の共通鍵テーブルを記憶部に記憶する。
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
本発明によれば、エリアに応じて暗号鍵を切り換えて使用することができるようになり、通信システムにおける鍵漏洩のリスクを低減することができる。
本発明を具体的に説明する前に、概要を述べる。本発明の実施例は、車両に搭載された端末装置間において車車間通信を実行するとともに、交差点等に設置された基地局装置から端末装置へ路車間通信も実行する通信システムに関する。車車間通信として、端末装置は、車両の速度や位置等の自車両情報を格納したパケット信号をブロードキャスト送信する(以下、ブロードキャストによりパケット信号の送信を「報知」という)。また、他の端末装置は、パケット信号を受信するとともに、データをもとに車両の接近等を認識する。また、路車間通信として、基地局装置は、交差点情報、渋滞情報、および、セキュリティ情報等が格納されたパケット信号を報知する。以下、説明を簡単にするために、車車間通信および路車間通信のパケット信号に含まれる情報の総称を「データ」という。
交差点情報には、交差点の位置、基地局装置が設置された交差点の撮影画像や、交差点内の車両の位置情報等の交差点の状況に関する情報が含まれる。端末装置は、この交差点情報をモニタに表示し、この交差点情報をもとに交差点車両の状況を認識して、出会い頭・右折・左折による衝突防止を目的とした他の車両や歩行者の存在等をユーザに伝達し、事故の防止を図る。また、渋滞情報には、基地局装置が設置された交差点近辺の走路の混雑状況、道路工事や事故に関する情報が含まれる。この情報を元に進行方向の渋滞をユーザに伝達し、あるいは、迂回路を提示する。セキュリティ情報では、共通鍵テーブルの提供等のデータを保護に関する情報が含まれる。詳細については、後述する。
また、このような通信においてなりすまし等を抑制するために、電子署名が使用される。電子署名を生成するためには、暗号鍵が使用される。本実施例に係る通信システムでは、処理の負荷を考慮し、暗号鍵として共通鍵を使用する。また、共通鍵の漏洩リスクを低減去るために複数の共通鍵を使用する。ひとつの共通鍵をひとつの共通鍵IDとして管理し、複数の共通鍵を共通鍵テーブルにまとめる。また、共通鍵テーブルには、共通鍵テーブルIDが付与されることによって、複数種類の共通鍵テーブルが規定される。通信システムにおいて、使用可能なエリアが制限されている、すなわち、予め定められた所定のエリアのみで使用される第1の共通テーブル群と、使用可能なエリアの制限がない、すなわち、所定のエリア外で使用される第2の共通エリア群に分けられる。ここで、第1の共通鍵テーブル群は、使用可能なエリア内の基地局装置、あるいは、使用可能なエリアの周囲の基地局装置から報知されている。端末装置は、第1の共通鍵テーブル群に属する共通鍵テーブルを受信すると、それを内部に保持していない場合、内部に記録する。一方、第2の共通鍵テーブル群に属する共通鍵テーブルは、端末装置に予め記憶されている。
図1は、本発明の実施例に係る通信システム100の構成を示す。これは、ひとつの交差点を上方から見た場合に相当する。通信システム100は、基地局装置10、車両12と総称される第1車両12a、第2車両12b、第3車両12c、第4車両12d、第5車両12e、第6車両12f、第7車両12g、第8車両12h、ネットワーク202を含む。なお、各車両12には、図示しない端末装置が搭載されている。
図示のごとく、図面の水平方向、つまり左右の方向に向かう道路と、図面の垂直方向、つまり上下の方向に向かう道路とが中心部分で交差している。ここで、図面の上側が方角の「北」に相当し、左側が方角の「西」に相当し、下側が方角の「南」に相当し、右側が方角の「東」に相当する。また、ふたつの道路の交差部分が「交差点」である。第1車両12a、第2車両12bが、左から右へ向かって進んでおり、第3車両12c、第4車両12dが、右から左へ向かって進んでいる。また、第5車両12e、第6車両12fが、上から下へ向かって進んでおり、第7車両12g、第8車両12hが、下から上へ向かって進んでいる。
ここで、通信システム100では、通信においてなりすまし等を抑制するために、電子署名が添付されたパケット信号が報知される。電子署名とは、パケット信号に含まれたデータ等の電磁的記録に付与すべき電子的な署名である。これは、紙文書における印や署名に相当し、主に本人確認、偽造・かいざんの防止のために使用される。具体的に説明すると、ある文書についてその作成者として文書に記載されている者がある場合、その文書が本当にその作成名義人によって作成されたものであることは、紙の文書の場合、その文書に付されたその作成者の署名や印によって証明される。しかしながら、電子文書には直接印を押したり署名を付したりすることはできないので、これを証明するために、電子署名が使用される。電子署名を生成するためには、暗号が使用される。
電子署名として、公開鍵暗号方式に基づくデジタル署名が有力である。電子署名方式は、鍵生成アルゴリズム、署名アルゴリズム、検証アルゴリズムによって構成される。鍵生成アルゴリズムは電子署名の事前準備に相当する。鍵生成アルゴリズムは、ユーザの公開鍵および秘密鍵を出力する。鍵生成アルゴリズムが実行される度に異なる乱数が選ばれるので、ユーザごとに異なる公開鍵・秘密鍵ペアが割り振られる。各ユーザは、秘密鍵を保管し、公開鍵を公開する。
署名を作成したユーザは、その署名文に対する署名者とよばれる。署名者は、署名アルゴリズムによって署名文を作成する際、メッセージとともに自分の秘密鍵を入力する。署名者の秘密鍵を知っているのは署名者本人だけのはずなので、電子署名を付した電子文書の作成者を識別する根拠になる。メッセージと署名文を受け取ったユーザである検証者は、検証アルゴリズムを実行することによって、署名文が正しいか否かを検証する。その際、検証者は検証アルゴリズムに署名者の公開鍵を入力する。検証アルゴリズムは署名文が本当にそのユーザによって作成されたか否かを判定し、その結果を出力する。
このような公開鍵暗号方式の処理負荷は、一般的に大きい。例えば、交差点近傍では、例えば、100msecの間に500台の端末装置14からのパケット信号を処理しなければならなくなる。また、通信システム100において車両12に搭載された端末装置から報知されるパケット信号には、100バイト程度のデータが格納される。これに対して、公開鍵暗号方式の公開鍵証明書と電子署名は、200バイト程度になってしまい、伝送効率の低下が大きくなってしまう。また、公開鍵方式における電子署名の検証の演算処理は大きく、100msecの間に500台の端末装置14からのパケット信号を処理しようとすると、高機能の暗号演算装置あるいはコントローラを必要になってしまい、端末装置のコストが増加する。公開鍵暗号方式に基づく電子署名方式として、RSA、DSA、ECDSA等が使用される。
これに対して、共通鍵暗号方式を用いた電子署名がある。共通鍵暗号方式では、暗号化に用いる鍵と同一、または暗号化鍵から容易に導出可能な値が復号鍵として使用される。受信側の端末装置にとって復号鍵が既知であり、鍵の証明書が不要になるので、公開鍵暗号方式と比較して伝送効率の悪化が抑制される。電子署名方式としてCBC−MACがある。また、共通鍵暗号方式は、公開鍵暗号方式と比較して処理量が少ない。代表的な共通鍵暗号は、DES、AESである。通信システム100では、伝送負荷および処理負荷を考慮し、暗号方式として共通鍵暗号方式を採用する。
なお、通信システム100で使用される共通鍵が1種類だけであれば、悪意あるユーザであっても、共通鍵の入手が容易になる。これに対応するため、通信システム100では、複数の共通鍵を予め規定しており、各共通鍵は共通鍵IDにて管理されている。また、複数の共通鍵が共通鍵テーブルにまとめられている。さらに、共通鍵テーブルは共通鍵テーブルIDにて管理されており、共通鍵テーブルIDを増加させることによって、複数の共通鍵テーブルが規定される。以下では、説明を明瞭にするために、端末装置14は、第1の共通鍵テーブル群に含まれる第1の共通鍵テーブルと第2の共通鍵テーブル群に含まれる第2の共通鍵テーブルのふたつの共有鍵テーブルを使用するものとする。また、第1の共通鍵テーブルが使用できる所定のエリアは、基地局装置10のキャリア信号を受信可能な範囲として規定されものとする。
第1の共通鍵テーブルは、予め選択された基地局装置10が割当てられていて、割り当てられた基地局装置10の周囲で使用可能であり、第2の共通鍵テーブルは、基地局装置10の割当てがない共通鍵テーブルであって、第1の共通鍵テーブルを使用しないエリアで使用される。このように、第1の共通鍵テーブルを使用可能なエリアが制限されているので、端末装置14は、第1の共通鍵テーブルを常に保持している必要がなく、使用可能なエリアの内、あるいは、使用可能なエリアの周辺の基地局装置10から送信によって端末装置14に提供される。第2の共通鍵テーブルは、エリアに関係なく使用されるので、端末装置14は、第2の共通鍵テーブルを常に保持している。
図2は、基地局装置10の構成を示す。基地局装置10は、アンテナ20、RF部22、変復調部24、MACフレーム処理部26、検証部40、処理部28、制御部30、ネットワーク通信部32、センサ通信部34を含む。また、検証部40は、暗号部42と記憶部44を含む。RF部22は、受信処理として、図示しない端末装置や他の基地局装置10からのパケット信号をアンテナ20にて受信する。RF部22は、受信した無線周波数のパケット信号に対して周波数変換を実行し、ベースバンドのパケット信号を生成する。さらに、RF部22は、ベースバンドのパケット信号を変復調部24に出力する。一般的に、ベースバンドのパケット信号は、同相成分と直交成分によって形成されるので、ふたつの信号線が示されるべきであるが、ここでは、図を明瞭にするためにひとつの信号線だけを示すものとする。RF部22には、LNA(Low Noise Amplifier)、ミキサ、AGC、A/D変換部も含まれる。
RF部22は、送信処理として、変復調部24から入力したベースバンドのパケット信号に対して周波数変換を実行し、無線周波数のパケット信号を生成する。さらに、RF部22は、路車送信期間において、無線周波数のパケット信号をアンテナ20から送信する。また、RF部22には、PA(Power Amplifier)、ミキサ、D/A変換部も含まれる。
変復調部24は、受信処理として、RF部22からのベースバンドのパケット信号に対して、復調を実行する。さらに、変復調部24は、復調した結果から、MACフレームを取り出し、MACフレーム処理部26に出力する。また、変復調部24は、送信処理として、MACフレーム処理部26からのMACフレームに対して、変調を実行する。さらに、変復調部24は、変調した結果をベースバンドのパケット信号としてRF部22に出力する。ここで、通信システム100は、OFDM(Orthogonal Frequency Division Multiplexing)変調方式に対応するので、変復調部24は、受信処理としてFFT(Fast Fourier Transform)も実行し、送信処理としてIFFT(Inverse Fast Fourier Transform)も実行する。
図3は、通信システム100において規定されるパケット信号に格納されるMACフレームのフォーマットを示す。MACフレームの前段から、「MACヘッダ」、「LLCヘッダ」、「情報ヘッダ」、「セキュアフレーム」が配置される。MACヘッダ、LLCヘッダ、および、情報ヘッダはデータ通信制御に関わる情報が格納されており、それぞれが通信レイヤの各層に対応する。各フィード長さは、例えば、MACヘッダが30バイト、LLCヘッダが8バイト、情報ヘッダが12バイト。セキュアフレームについては後述する。図2に戻る。
MACフレーム処理部26は、受信処理として、変復調部24からのMACフレームから、セキュアフレームを取り出し、検証部40に出力する。MACフレーム処理部26は、送信処理として、検証部40からのセキュアフレームに対して、MACヘッダ、LLCヘッダ、および情報ヘッダを付加し、MACフレームを生成し、変復調部24に出力する。また、他の基地局装置あるいは端末装置からのパケット信号がぶつからないようにタイミング制御をする。
図4は、通信システム100において規定されるセキュアフレームのフォーマットを示す。セキュアフレームは、「ペイロードヘッダ」、「ペイロード」、「署名」が配置される。さらに、ペイロードヘッダには、「メッセージバーション」、「メッセージタイプ」、「鍵ID」、「発信元種別」、「発信元ID」、「発信日時」および「ロケーション」が配置される。
メッセージバージョンは、セキュアフレームのフォーマットと規定する識別情報である。通信システム100においては固定値となる。メッセージタイプは、ペイロードに対する暗号処理を規定する情報である。ここでは、平文データ(=0)、署名付きデータ(=1)、暗号化データ(=2)を設定するものとする。鍵IDは、電子署名あるいはペイロードの暗号化に使用した共通鍵を特定する識別情報で、共通鍵テーブルIDと共通鍵IDを連結したものである。発信元種別IDは、パケット信号の発信者の種類、すなわち、基地局装置10(=3)、救急車や消防車のような緊急車両(優先車両と呼ぶ)に搭載の端末装置(=2)、その他の車両(一般車両とよぶ)に搭載の端末装置(=1)および非車両搭載の端末装置(=0)が設定するものとする。発信元IDは、パケット信号を発信した基地局装置10あるいは端末装置14を、一意に特定できる装置ごとにユニークか識別情報である。発信元が基地局の場合、後述する基地局IDが納められる。
ペイロードは、前述のデータを格納するフィールドであり、交差点情報や道路情報等の端末装置へ通知すべき情報に相当する。また、メッセージタイプが署名付きデータ(=1)の時、ペイロードヘッダおよびペイロードに対する電子署名を格納するフィールドである。また、メッセージタイプが暗号化データ(=12)の時、無効としてもよいが、ここでは固定値、ペイロードヘッダの部分の写しなどの受信側特定可能な値、あるいは、ペイロードヘッダまたは/および暗号化前のペイロードに対するハッシュ値(ハッシュ関数による演算結果)、チェックサム、パリティなどの受信側で演算可能な値を格納するものとする。そして、ペイロードおよび署名をまとめて暗号化する。このようにすることで、復号によって得られた署名に格納された値と、受信側で特定した、あるいは、演算した値とが一致すれば、復号が正常の行われ、ペイロードに格納されているデータ、あるいはペイロードヘッダとペイロードに格納されているデータの正当性が確認できる。
各フィード長さは、例えば、ペイロードヘッダが32バイト、ペイロードが100バイト(端末装置が報知する場合)あるいは1Kバイト(基地局装置が報知する場合)。署名が16バイト。通信システム100では、暗号方式としてAES(Advanced Encryption Standard)暗号を使用する。そして、メッセージタイプが署名付きデータの場合には、電子署名は、CBC−MAC(Cipher Block Chaining−Message Authentication Code)によって求めたMAC値を署名に格納する。メッセージタイプが暗号化データの場合には、ペイロードヘッダに対するMAC値を署名に格納し、ペイロードおよび署名を、CBC(Cipher Block Chaining)モードで暗号化する。図2に戻る。
検証部40は、受信処理として、MACフレーム処理部26からのセキュアフレームを解釈し、データを処理部28に出力する。また、検証部40は、送信処理として、処理部28からのデータを受け取り、セキュアフレームを生成し、MACフレーム処理部26に出力する。通信システム100では、共通鍵暗号方式を使用しているため、暗号部42は、共通鍵方式による暗号・復号処理を行う。具体的には、メッセージデータタイプが署名付きデータの場合、署名の作成を、メッセージデータタイプが暗号化データの場合、セキュアフレーム作成時に暗号処理を、セキュアフレーム解釈時には、データの復号処理を行う。
記憶部44は、通信システム100に使用可能な共通鍵が複数種類示された共通鍵テーブルを記憶する。前述のごとく、複数の共通鍵テーブルが規定されており、ここでは、それらを第1の共通鍵テーブルと第2の共通鍵テーブルとする。第1の共通鍵テーブルでは、制限されたエリアにおける通信に使用可能な複数の共通鍵が含まれている。第2の共通鍵テーブルでは、エリアに関係なく使用可能な複数の共通鍵が含まれている。これは、第1の共通鍵テーブルを使用可能でないエリアにおいて使用可能な複数の共通鍵が含まれているともいる。
図5は、記憶部44に記憶される共通鍵テーブルのデータ構造を示す。第1の共通鍵テーブルおよび第2の共通鍵テーブルには、共通鍵テーブルIDが付与されている。図5において、第1テーブルは、共通鍵テーブルIDが「128」、第2テーブルは、共通鍵テーブルIDが「2」である。各共通鍵テーブルには、複数の共通鍵が含まれており、各共通鍵は共通鍵IDで管理されている。図5において、共通鍵テーブルは、それぞれN個の共通鍵を含む。第1共通鍵は、共通鍵IDが「1」である場合に相当し、第2共通鍵は、共通鍵IDが「2」である場合に相当する。そのため、ひとつの共通鍵は、共通鍵テーブルIDと共通鍵IDとの組合せによって特定される。また、第1の共通鍵テーブルには、制限されたエリアを示す、M(M≧1)個の基地局IDが含まれている。第1の共通テーブルは、第1から第M基地局IDにて特定される基地局装置10からのキャリア信号を受信可能なエリアにおいて優先的に選択される。なお、キャリア信号を発信した基地局装置の特定は、セキュアフレームの発信元IDに格納されている基地局IDによって行うことができる。図2に戻る。
ここで、第1の共通鍵テーブルを使用可能なエリアについて説明する。説明を簡単にするために、第1の共通鍵テーブルには、基地局IDが1つのみ含まれているものとする。図6は、通信システム100における基地局装置10の配置を示す。説明を簡易にするために、5つの基地局装置10、つまり第1基地局装置10a、第2基地局装置10b、第3基地局装置10c、第4基地局装置10d、第5基地局装置10eが一元的に一列に並んで配置されている場合を想定する。各基地局装置10の周りに示されている円は、各基地局のキャリア信号を受信可能なエリアに相当する。ここでは、第3基地局装置10cが、前述の選択した基地局装置10に相当し、第1の共通鍵テーブルには、第3基地局装置10cの基地局IDが含まれている。そのため、第3基地局装置10cにて形成されたエリア内に進入し、第3基地局装置10cからのパケット信号を受信した端末装置は、パケット信号の報知の際に、第1の共通鍵テーブルを使用する。
一方、第3基地局装置10cにて形成されたエリアから出たことによって、第3基地局装置10cからのパケット信号を一定期間受信しなくなった、あるいは、他の基地局装置からのキャリア信号を受信した端末装置は、パケット信号の報知の際に、第2の共通鍵テーブルを使用する。図6において第1基地局装置10aにて形成されたエリア、第2基地局装置10bにて形成されたエリア、第4基地局装置10dにて形成されたエリア、第5基地局装置10eにて形成されたエリア内に存在する、あるいは、いずれのエリアにも存在しない端末装置は、パケット信号の報知の際に、第2の共通鍵テーブルを使用する。詳細は後述するが、端末装置は、第3基地局装置10cからのパケット信号を受信している場合に、第1の共通鍵テーブルを使用し、第3基地局装置10cからのパケット信号を受信していない場合に、第2の共通鍵テーブルを使用する。図2に戻る。
検証部40は、セキュアフレームを生成する際、記憶部44を参照して、共通鍵を抽出する。例えば、本基地局装置10が、図6の第3基地局装置10cに相当する場合、検証部40は、第1の共通鍵テーブルの中から、ひとつの共通鍵をランダムに選択する。また、本基地局装置10が、図6の第1基地局装置10a、第2基地局装置10b、第4基地局装置10d、第5基地局装置10eに相当する場合、検証部40は、第2の共通鍵テーブルの中から、ひとつの共通鍵をランダムに選択する。検証部40は、メッセージタイプが署名付きデータの場合には、選択した共通鍵を使用して暗号部42にてペイロードヘッダとペイロードに対する電子署名を演算する。また、メッセージタイプが暗号化データの場合には、暗号部42にてペイロードと署名を暗号化する。検証部40は、メッセージタイプが平文データの場合には、生成したセキュアフレームを、そのままMACフレーム処理部26へ出力する。
検証部40は、セキュアフレームを解釈する際、MACフレーム処理部26から受け取ったセキュアフレームの鍵IDを参照し、使用する共通鍵の鍵テーブルIDと共通鍵IDを得る。次いで、記憶部44を参照して、この鍵テーブルIDと共通鍵IDにて特定される共通鍵を抽出する。さらに、検証部40は、抽出した共通鍵を使用して、MACフレーム処理部26から受け取ったセキュアフレームのメッセージタイプが署名付きデータの場合には、署名の正当性を検証する。詳細には、暗号部42にてペイロードヘッダとペイロードに対する電子署名を演算し、求めた値と、MACフレーム処理部26から受け取ったセキュアフレームの署名に格納された電子署名の値と比較する。2つの電子署名の値が一致すれば、電子署名が正当であり、このセキュアフレームに含まれる情報が正規の基地局装置10、あるいは、端末装置14からの情報であると判断し、処理部28に出力する。2つの電子署名の値が不一致ならば電子署名が正当でないと判断し、データは破棄される。また、メッセージタイプが暗号化データの場合には、暗号部42にてペイロードと署名の復号処理を実行する。そして、署名が予め定めた値であれば、セキュアフレームから取り出したデータが正常復号されたと判断し、セキュアフレームから取り出したデータを処理部28に出力する。なお、予め定めた値でない場合、データは破棄される。なお、暗号化対象を署名としているのは、前述のごとく署名には既知の値を格納して暗号化の対象とすることで、復号時に復号が正常の行われたか否かをチェックする機能を持たせたためである。このようなチェック機能を持たせない場合には、署名を暗号化の対象とする必要はない。メッセージタイプが平文データの場合には、受け取ったセキュアフレームから取り出したデータを、無条件で処理部28に出力する。
センサ通信部34は、図示しない内部ネットワークに接続される。この内部ネットワークには、図示しない交差点の各所に設置されたカメラやレーザセンサなどの交差点の情報収集する機器が接続されている。センサ通信部34に接続された交差点の情報を収集する機器の総称をセンサという。センサ通信部34は、ネットワークを介して、交差点の各所に設置されたセンサの情報を受け取り、処理部28へ出力する。ネットワーク通信部32は、図示しないネットワークに接続される。
処理部28は、検証部40から受け取ったデータに対する処理を実行する。処理結果は、ネットワーク通信部32を介して、図示しないネットワーク202へ出力されてもよいし、内部に蓄積して、定期的に図示しないネットワークへ出力されてもよい。また、処理部28は、ネットワーク通信部3を介して、図示しないネットワークから受け取った道路情報(工事、渋滞など)や、センサ通信部34を介して、図示しないセンサからの交差点の情報に基づいて、端末装置14に送信するデータを生成する。制御部30は、基地局装置10全体の処理を制御する。
なお、本基地局装置10が、図6の第3基地局装置10cである場合、検証部40は、第1の共通鍵テーブルを使用して、処理部28から取得したデータを含むセキュリティパケットを生成し、変復調部24、RF部22、アンテナ20を介して報知する。また、第1の共通鍵テーブルを使用して、記憶部44において記憶した第1の共通鍵テーブル含むセキュリティパケットを生成し、報知する。つまり、第1の共通鍵テーブルを使用可能なエリアを形成している基地局装置10の検証部40は、第1の共通鍵テーブル自体も報知する。また、第1の共通鍵テーブルを使用可能なエリアを形成している基地局装置10に隣接した基地局装置10、例えば、図6の第2基地局装置10b、第4基地局装置10dの検証部40も、第3基地局装置10cと同様に、第1の共通鍵テーブル自体を報知する。ここで、第1の共通鍵テーブルを使用可能なエリアを形成している基地局装置10から所定の距離の基地局装置10も、第1の共通鍵テーブル自体を報知してもよい。また、図6の第1基地局装置10a、第2基地局装置10b、第4基地局装置10d、第5基地局装置10eの検証部40は、1の共通鍵テーブルを使用して、処理部28から取得したデータを含むセキュリティパケットを生成して報知する。
この構成は、ハードウエア的には、任意のコンピュータのCPU、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
図7は、車両12に搭載された端末装置14の構成を示す。端末装置14は、アンテナ50、RF部52、変復調部54、MACフレーム処理部56、受信処理部58、データ生成部60、検証部62、通知部70、制御部72を含む。検証部62は、暗号部64と記憶部66、判定部68を含む。アンテナ50、RF部52、変復調部54、MACフレーム処理部56、検証部62、記憶部66、暗号部64は、図2のアンテナ20、RF部22、変復調部24、MACフレーム処理部26、検証部40、暗号部42、記憶部44と同様の処理を実行する。そのため、ここでは、同様の処理の説明を割愛し、差異を中心に説明する。
検証部62は、検証部40と同様に、セキュアフレームの生成および解釈を行う。また、受け取ったセキュアフレームのペイローロードが、セキュリティ情報の場合、すなわち、第1の共通鍵テーブルが含まれる時、その第1の共通鍵テーブルが記憶部66に未記録の場合には、記憶部66に受け取った第1の共通鍵テーブルを記憶させる。記憶部66に空きがある場合、受け取った共通鍵テーブルをそのまま追記する。記憶部66に、他のテーブルIDを含む第1の共通テーブルが記録されている場合、記憶部66に記憶されている第1の共通鍵テーブルを書き換える。記憶部66に、同じテーブルIDを含む第1の共通テーブルが記録されている場合、受け取った第1の共通テーブルを破棄する。
受信処理部58は、検証部62から受け取ったデータと、データ生成部60から受け取った自車両情報に基づいて、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また、データが、画像情報であれば通知部70にて表示できるように処理をする。
通知部70は、図示しないモニタやランプやスピーカ等のユーザへの通知手段を含む。受信処理部58から指示しにしたがって、図示しない他の車両12の接近等を運転者へモニタやランプやスピーカを介して通知する。また、渋滞情報や交差点等の画像情等をモニタに表示する。
前述のごとく、基地局装置10を識別するための情報は、セキュアフレームの「発信元ID」に基地局IDが格納されている。判定部68は、パケット信号の発信元が、基地局装置10である場合、発信元IDから基地局IDを抽出して、パケット信号の報知元になる基地局装置10を特定する。
また、前述のごとく記憶部66に記録されている第1の共通鍵テーブルには、第1の共通鍵テーブルを使用可能なエリアを形成する基地局装置の基地局IDのリストが含まれている。ここでは、図6の第3基地局装置10cに相当した基地局装置10の基地局IDがリストに含まれている。判定部68は、記憶部66に記憶されたリスト中に、受けつけた基地局IDが含まれているかを判定する。これは、第1の共通鍵テーブルを使用可能なエリア内に存在するかを判定することに相当する。判定部68は、判定結果を保持する。検証部62は、セキュリティフレームを生成する際、判定部68の判定結果に従って、共通鍵テーブルを選択する。
データ生成部60は、図示しないGPS受信機、ジャイロスコープ、車速センサ等を含んでおり、それらから供給される情報によって、図示しない自車両の情報、つまり端末装置14が搭載された車両12の存在位置、進行方向、移動速度等を取得する。なお、存在位置は、緯度・経度によって示される。これらの取得には公知の技術が使用されればよいので、ここでは説明を省略する。データ生成部60は、取得した情報を元にデータを生成し、生成したデータを検証部62に出力する。また、取得した情報を受信処理部58に自車両情報として出力する。
以上の構成による通信システム100のパケット信号の送受信に関わる動作を説明する。図8は、基地局装置10におけるパケット信号の送信手順を示すフローチャートである。共通鍵テーブルを送信しない場合(S10のN)、検証部40は、処理部28よりデータと、データを送信するメッセージタイプのデータ形式を受け取る。そして、受け取ったデータをペイロードに格納したセキュアフレームを生成する(S12)。この時、鍵IDおよび署名は、空であり、例えば、すべてに0を格納する。次いで、メッセージタイプのデータ形式が平文データの場合(S14のY)、MACフレーム処理部26、変復調部24、RF部22、アンテナ20を介して、そのままセキュアフレームを、パケット信号として報知する(S22)。メッセージタイプのデータ形式が署名付きデータまたは暗号データの場合(S14のN)、共通鍵を選択する(S16)。共通鍵は最新の共通鍵テーブルよりランダムに選択される。共通鍵を選択するとセキュアフレームの鍵IDには、最新の共通鍵テーブルのテーブルIDと選択された共通鍵IDが格納される。再び、メッセージタイプのデータ形式を参照して、データ形式が署名付きデータの場合(S18のY)、検証部40は、暗号部42にて、選択した共通鍵を用いてペイロードヘッダおよびペイロードに対する電子署名を演算し、その値をセキュアフレームの署名に格納する(S20)。次いで、MACフレーム処理部26、変復調部24、RF部22、アンテナ20を介して、署名を付けたセキュアフレームを、パケット信号として報知する(S22)。メッセージタイプのデータ形式が暗号化データの場合(S18のN)、検証部40は、暗号部42にて、ペイロートのMAC値を求め、セキュアフレームの署名に格納する(S24)。次いで、選択した共通鍵を用いてペイロードヘッダおよび署名を暗号化する(S26)。そして、MACフレーム処理部26、変復調部24、RF部22、アンテナ20を介して、暗号化したセキュアフレームを、パケット信号として報知する(S22)。
共通鍵テーブルを送信する場合(S10のY)、検証部40は、記憶部44より報知する共通鍵テーブルを取得し、セキュアフレームを生成し(S28)、共通鍵を選択する(S30)。検証部40は、暗号部42にて、ペイロートのMAC値を求め、セキュアフレームの署名に格納する(S24)。次いで、選択した共通鍵を用いてペイロードヘッダおよび署名を暗号化する(S26)。そして、MACフレーム処理部26、変復調部24、RF部22、アンテナ20を介して、暗号化したセキュアフレームを、パケット信号として報知する(S22)。
図9は、基地局装置10におけるパケット信号の受信手順を示すフローチャートである。アンテナ20、RF部22、変復調部24は、パケット信号を受信する(S40)。データ形式が署名付きあるいは暗号化であれば(S42のN)、検証部40は、鍵テーブルIDおよび共通鍵IDを確認する(S44)。記憶部44は、鍵テーブルIDを蓄積する(S46)。検証部40は、記憶部44から共通鍵を取得する(S48)。データ形式が署名付きであり(S50のY)、署名データが正当であれば(S52のY)、検証部40は、テーブルIDを計数する(S58)。一方、データ形式が暗号化である場合(S50のN)、検証部40は、取得した暗号鍵にて復号する(S54)。データが正当であれば(S56のY)、検証部40は、テーブルIDを計数する(S58)。署名データが正当でない場合(S52のN)、あるいはデータが正当でない場合(S56のN)、検証部40は、データを破棄する(S62)。テーブルIDが計数された後、あるいはデータ形式が平文である場合(S42のY)、検証部40は、データを取り出す(S60)。
図10は、端末装置14におけるパケット信号の受信手順を示すフローチャートである。アンテナ50、RF部52、変復調部54は、パケット信号を受信する(S80)。データ形式が署名付きあるいは暗号化であれば(S82のN)、検証部62は、鍵テーブルIDおよび共通鍵IDを確認する(S84)。記憶部66が鍵テーブルを有していれば(S86のY)、記憶部66は、鍵テーブルIDを蓄積する(S88)。検証部62は、記憶部66から共通鍵を取得する(S90)。データ形式が署名付きであり(S92のY)、署名データが正当であれば(S94のY)、検証部62は、データを抽出する(S104)。
一方、データ形式が暗号化である場合(S92のN)、検証部62は、取得した暗号鍵にて復号する(S96)。データが正当であり(S98のY)、データ種別がなければ(S100のN)、検証部62は、データを抽出する(S104)。データ形式が平文である場合(S82のY)、検証部62は、データを取り出す(S104)。記憶部66が鍵テーブルを有していない場合(S86のN)、あるいは署名データが正当でない場合(S94のN)、あるいはデータが正当でない場合(S98のN)、検証部62は、データを破棄する(S106)。データ種別があり(S100のY)、鍵テーブルがある場合(S102のY)、検証部62は、データを破棄する(S106)。鍵テーブルがなければ(S102のN)、検証部62は、記憶部66に格納させる(S108)。
図11は、端末装置14におけるパケット信号の送信手順を示すフローチャートである。検証部62は、データを取得し、セキュアフレームを生成する(S120)。メッセージタイプが署名付きあるいは暗号化であり(S122のN)、基地局装置受信エリアでなければ(S124のN)、検証部62は、第2共通鍵テーブルから共通鍵を選択する(S128)。基地局装置受信エリアであり(S124のY)、基地局装置10から受信したパケット信号に含まれる発信元IDが第1の共通鍵テーブルの基地局IDのリストに含まれていなくても(S126のN)、検証部62は、第2共通鍵テーブルから共通鍵を選択する(S128)。
基地局装置10から受信したパケット信号に含まれる発信元IDが第1の共通鍵テーブルの基地局IDのリストに含まれていれば(S126のY)、検証部62は、第1共通鍵テーブルから共通鍵を選択する(S130)。メッセージタイプが署名付きであれば(S132のY)、検証部62は、選択した共通鍵にて電子署名を演算し、署名データに格納し(S134)、変復調部54、RF部52、アンテナ50は、パケット信号を報知する(S140)。メッセージタイプが暗号化であれば(S132のN)、検証部62は、ペイロードヘッダのMAC値を演算し、署名データに格納する(S136)。検証部62は、選択して暗号鍵にて暗号化し(S138)、変復調部54、RF部52、アンテナ50は、パケット信号を報知する(S140)。メッセージタイプが平文であれば(S122のY)、変復調部54、RF部52、アンテナ50は、パケット信号を報知する(S140)。
本発明の実施例によれば、所定のエリア内に存在すれば、第2の共通鍵テーブルとは別の第1の共通鍵テーブルを使用するので、エリアに応じて、少なくとも2種類の共通鍵テーブルを使用できる。また、エリアに応じて、少なくとも2種類の共通鍵テーブルが使用されるので、一方の共通鍵テーブルのみを更新できる。また、一方の共通鍵テーブルのみが更新されるので、エリアに応じて暗号鍵を効率的に配布できる。また、一方の共通鍵テーブルのみが更新されるので、危険性の高いエリアのみにおいて共通鍵テーブルを更新できる。また、所定のエリア内において、第1の共通鍵テーブルを記憶していなければ、第1の共通鍵テーブルに含まれた共通鍵によって生成された電子署名を正当と判定しないので、安全性を確保できる。
また、所定のエリア内において、第1の共通鍵テーブルを記憶していなくても、第1の共通鍵テーブルに含まれた共通鍵によって生成された電子署名を所定回数以上検出すれば、検証を省略するので、当該電子署名を添付したデータを取得できる。また、所定回数以上検出した場合だけデータを取得するので、電子署名を検証しなくても危険性を低減できる。また、データが取得されるので、他の車両の接近を認識できる。また、第1の共通鍵テーブルを使用していない基地局装置も第1の共通鍵テーブルを配布するので、第1の共通鍵テーブルを利用しやすくできる。また、第1の共通鍵テーブルを配布する基地局装置が制限されるので、伝送効率の悪化を抑制できる。
また、電子署名を生成するために共通鍵を使用するので、公開鍵を使用する場合と比較して処理量を低減できる。また、処理量が低減されるので、処理可能なパケット信号数を増加できる。また、電子署名を生成するために共通鍵を使用するので、公開鍵を使用する場合と比較して伝送効率を向上できる。また、位置情報等のデータに対しては暗号化を実行しないので、処理量を低減する。一方、共通鍵テーブルには暗号化を実行するので、安全性を向上できる。
次に本発明の変形例を説明する。セキュリティを向上させるためには、定期的な暗号鍵の更新が望まれる。複数の端末装置において共通した暗号鍵を使用させながら、暗号鍵を更新するためには、通信システム内に暗号鍵を管理させるための装置が接続されるべきである。しかしながら、端末装置が主に車両に搭載され、車両が移動している状況を想定すると、暗号鍵を管理させるための装置によって、暗号鍵が管理されないエリアも存在する。そのため、端末装置だけが存在する状況下においても、暗号鍵の自律的な更新が望まれる。変形例の目的は、暗号鍵を自律的に更新させる技術を提供することにある。
本発明の変形例では、ひとつの共通鍵をひとつの共通鍵IDとして管理し、複数の共通鍵を共通鍵テーブルにまとめる。さらに、共通鍵テーブルのバージョンは、テーブルIDとして管理される。そのため、ひとつのテーブルIDには、複数の共通鍵IDが含まれる。このような共通鍵テーブルは定期的に更新されることが望ましい。本通信システムが十分普及する前の段階や、交通量の少ないエリア等では、基地局装置の設置数が少ないことが想定される。そのような状況において、基地局装置が、新たな共通鍵テーブルを通知することによって、端末装置が、共通鍵テーブルを更新する場合、共通鍵テーブルを更新していない端末装置の数が増加しうる。これに対応するため、本変形例に係る端末装置は、共通鍵テーブルを更新するための非可逆変換関数を予め記憶し、既に使用している共通鍵テーブルを非可逆変換関数によって更新することによって、新たな共通鍵テーブルを生成する。つまり、端末装置は、共通鍵テーブルを自律的にかつ定期的に更新する。
変形例に係る通信システム100は、図1と同様のタイプである。電子署名として、公開鍵暗号方式に基づくデジタル署名が有力である。公開鍵暗号方式に基づく方式として、具体的には、RSA、DSA、ECDSA等が使用される。電子署名方式は、鍵生成アルゴリズム、署名アルゴリズム、検証アルゴリズムによって構成される。鍵生成アルゴリズムは電子署名の事前準備に相当する。鍵生成アルゴリズムは、ユーザの公開鍵および秘密鍵を出力する。鍵生成アルゴリズムが実行される度に異なる乱数が選ばれるので、ユーザごとに異なる公開鍵・秘密鍵ペアが割り振られる。各ユーザは、秘密鍵を保管し、公開鍵を公開する。共通鍵テーブルはテーブルIDにて管理されており、テーブルIDを増加させることによって、共通鍵テーブルはバージョンアップに対応する。共通鍵テーブルのバージョンアップは、基地局装置10および端末装置14のそれぞれになされる。
端末装置14は、非可逆変換関数を予め記憶し、既に使用している共通鍵テーブルを非可逆変換関数にて変換することによって、新たな共通鍵テーブルを生成する。そのため、端末装置14における共通鍵テーブルのバージョンアップは自律的になされる。ここで、バージョンアップのタイミングは、例えば、現在の共通鍵テーブルを使用開始してから所定の期間経過したときであればよい。また、端末装置14は、他の端末装置14からのパケット信号を受信し、当該パケット信号にて使用されている共通鍵を含んだ共通鍵テーブルのバージョンが新しいことを検出したときが、バージョンアップのタイミングであってもよい。一方、基地局装置10は、端末装置14と同様に、共通鍵テーブルのバージョンアップを実行してもよく、ネットワーク202から新たな共通鍵テーブルを受けつけてることによって、バージョンアップを実行してもよい。
変形例に係る基地局装置10は、図2と同様のタイプである。図12は、通信システム100において規定されるMACフレームに格納されるセキュリティフレームのフォーマットを示す。セキュリティフレームは、「セキュリティヘッダ」、「ペイロード」、「署名」が配置される。さらに、セキュリティヘッダには、「プロトコルバーション」、「メッセージタイプ」、「テーブルID」、「鍵ID」、「発信元種別」、「発信元ID」、「発信日時」、「ロケーション」、「ペイロード長」が配置される。プロトコルバーションは、セキュリティフレームのフォーマットを規定するための識別情報である。通信システム100においては固定値となる。メッセージタイプには、「データ種別」と「データ形式」とリザーブが含まれる。データ種別には、ペイロードに格納されるデータがアプリケーションデータ(=0)、すなわち、後続のMACフレーム処理部26へ出力されるデータであるか、メンテナンスデータ(=1)、すなわち、検証部40の内部で処理されるセキュリティ情報であるかを識別するためのフラグ情報が設定される。
データ形式は、ペイロードに格納されるデータのセキュリティに関わる形式、つまり、ペイロードに対する暗号処理を規定するためのフラグである。ここでは、平文データ(=0)、署名付きデータ(=1)、暗号化データ(=2)が設定される。なお、リザーブは将来に対する予備であり、通信システム100では使用しない。テーブルIDは、電子署名あるいはペイロードの暗号化に使用した共通鍵が含まれた共通鍵テーブルの識別情報である。鍵IDは、電子署名あるいはペイロードの暗号化に使用した共通鍵を特定するための識別情報であり、前述の共通鍵IDに相当する。発信元種別IDは、パケット信号の発信者の種類、すなわち、基地局装置10(=3)、救急車や消防車のような緊急車両(優先車両とよぶ)に搭載の端末装置(=2)、その他の車両(一般車両とよぶ)に搭載の端末装置(=1)および非車両搭載の端末装置(=0)が設定される。発信元IDは、パケット信号を発信した基地局装置10あるいは端末装置14を一意に特定するための識別情報であり、これは装置ごとにユニークに規定される。
ペイロードは、前述のデータを格納するためのフィールドであり、交差点情報や道路情報等の端末装置へ通知すべき情報に相当する。また、メッセージタイプのデータ形式が署名付きデータ(=1)のとき、セキュリティヘッダおよびペイロードに対する電子署名が生成される。また、メッセージタイプのデータ形式が暗号化データ(=2)のとき、無効としてもよいが、ここでは固定値、セキュリティヘッダの部分の写しなどの受信側特定可能な値、あるいは、セキュリティヘッダまたは/および暗号化前のペイロードに対するハッシュ値(ハッシュ関数による演算結果)、チェックサム、パリティなどの受信側で演算可能な値を格納するものとする。そして、ペイロードが暗号化される。このようにすることで、復号によって得られた署名に格納された値と、受信側で特定した、あるいは、演算した値とが一致すれば、復号が正常の行われ、ペイロードに格納されているデータ、あるいはセキュリティヘッダとペイロードに格納されているデータの正当性が確認できる。各フィード長さは、例えば、セキュリティヘッダが32バイト、ペイロードが100バイト(端末装置が報知する場合)あるいは1Kバイト(基地局装置が報知する場合)であり、署名が16バイトである。
通信システム100では、暗号方式としてAES(Advanced Encryption Standard)暗号を使用する。図13(a)−(b)は、セキュリティフレームに対する処理内容を示す。図13(a)、はメッセージタイプのデータ形式が署名付きデータの場合を示す。電子署名は、セキュリティヘッダの一部、ここでは、発信元種別、発信元ID、発信日時、ローケーション、ペイロード長と、ペイロードに対して演算され、その値は、セキュリティフッダにある署名に格納される。電子署名の演算対象に、発信元種別、発信元IDを含めているのは、発信元となる車載器あるいは路側機の素性を証明するためである。また、発信日時、ローケーションを含めているのは、発信日時、ローケーションの改ざんを防止し、パケット信号を傍受して、そのパケット信号を再送信することによる妨害を防ぐためである。図13(b)は、メッセージタイプのデータ形式が暗号化データの場合を示す。電子署名は、セキュリティヘッダの一部、ここでは、発信元種別、発信元ID、発信日時、ローケーション、ペイロード長に対して演算され、その値は、セキュリティフッダにある署名に格納される。ペイロードは、CBC(Cipher Block Chaining)モードで暗号化される。CBCモードでは、最初のブロックを暗号化する場合に、初期ベクトル(Inital Vector、以下では、「IV」という。)が使用される。IVの値は、通常いかなる値を用いてもよいが、通信システム100では、ペイロードに格納されたデータを、情報の発信元に対して紐付けして暗号化することですることで、データの信頼性を向上させる。ここでは、発信元種別、発信元ID、発信日時、ローケーション、ペイロード長を元にして演算して、IVを決定する。具体的には、先に求めたセキュリティヘッダに一部に対する電子署名の値を、IVとして用いるものとする。図2に戻る。
記憶部44は、通信システム100に使用可能な共通鍵が含まれた複数の共通鍵テーブルを記憶する。図14は、記憶部44に記憶される共通鍵テーブルのデータ構造を示す。共通鍵テーブルには、複数のバージョンが存在してもよく、それらは、テーブルIDとして管理される。図14において、第1テーブル220は、テーブルIDが「N−1」である場合に相当し、第2テーブル222は、テーブルIDが「N」である場合に相当する。第2テーブル222が第1テーブル220よりも新しいバージョンである。ここでは、ふたつの共通鍵テーブルを示しているが、記憶部44には、3つ以上の共通鍵テーブルが記憶されていてもよい。各共通鍵テーブルには、複数の共通鍵が含まれており、各共通鍵は共通鍵IDで管理されている。図14において、第1共通鍵は、共通鍵IDが「1」である場合に相当し、第2共通鍵は、共通鍵IDが「2」である場合に相当する。そのため、ひとつの共通鍵は、テーブルIDと共通鍵IDとの組合せによって特定される。また、各共通鍵テーブルに、更新日時に関する情報が含まれている。第1テーブル220の更新日時が「2010.1.1」であり、第2テーブル222の更新日時が「2010.3.1」である。なお、記憶部44は、共通鍵テーブルの更新が、基地局装置および端末装置に普及するまでの期間を補償するために、少なくとの1つ過去の共通鍵テーブルを保持する。図2に戻る。
検証部40は、セキュリティフレームを生成する際、記憶部44を参照して、共通鍵を抽出する。例えば、各共通鍵テーブルには、更新日時が規定されており、検証部40は、現在の時刻をもとに、ひとつの共通鍵テーブルを選択する。検証部40は、運用中の共通鍵テーブルの中から、最新の更新日時の共通鍵テーブルを選択する。さらに、検証部40は、選択した共通鍵テーブルの中から、ひとつの共通鍵を選択する。この選択は、ランダムになされてもよいし、基地局装置10に付与された識別番号にしたがってなされてもよい。
検証部40は、メッセージタイプのデータ形式が署名付きデータの場合に、選択した共通鍵を使用して暗号部42にてセキュリティヘッダとペイロードに対する電子署名を演算させる。また、メッセージタイプのデータ形式が暗号化データの場合には、暗号部42にてペイロードを暗号化させる。検証部40は、メッセージタイプのデータ形式が平文データの場合に、生成したセキュリティフレームをMACフレーム処理部26へそのまま出力する。なお、MACフレーム処理部26から受け取ったデータを用いてセキュリティフレームを生成する場合、検証部40は、メッセージタイプのデータ種別をアプリケーションデータ(=0)にする。
検証部40は、セキュリティフレームを解釈する際、MACフレーム処理部26から受け取ったセキュリティフレームのテーブルIDと共通鍵IDとを取得する。次いで、検証部40は、記憶部44を参照して、このテーブルIDと共通鍵IDにて特定される共通鍵を抽出する。さらに、検証部40は、MACフレーム処理部26から受け取ったセキュリティフレームのメッセージタイプのデータ形式が署名付きデータの場合に、抽出した共通鍵を使用して署名の正当性を検証する。詳細には、暗号部42がセキュリティヘッダとペイロードに対する電子署名を演算し、求めた値と、MACフレーム処理部26から受け取ったセキュリティフレームの署名に格納された電子署名の値と比較する。ふたつの電子署名の値が一致すれば、電子署名が正当であり、このセキュリティフレームに含まれる情報が正規の基地局装置10、あるいは、端末装置14からの情報であると判断し、MACフレーム処理部26に出力する。ふたつの電子署名の値が不一致ならば電子署名が正当でないと判断し、データは破棄される。
また、メッセージタイプのデータ形式が暗号化データの場合に、暗号部42がペイロードと署名の復号処理を実行する。そして、署名が予め定めた値であれば、セキュリティフレームから取り出したデータが正常復号されたと判断し、セキュリティフレームから取り出したデータをMACフレーム処理部26に出力する。なお、予め定めた値でない場合、データは破棄される。メッセージタイプのデータ形式が平文データの場合に、検証部40は、受け取ったセキュリティフレームから取り出したデータを、無条件でMACフレーム処理部26に出力する。
処理部28は、検証部40から受け取ったデータに対する処理を実行する。処理結果は、ネットワーク通信部32を介して、直接、図示しないネットワークへ出力されてもよし、内部に蓄積して、定期的に図示しないネットワークへ出力されてもよい。また、処理部28は、ネットワーク通信部32を介して、図示しないネットワークから道路情報(工事、渋滞など)を受け取ったり、センサ通信部34を介して、図示しないセンサからの交差点の情報を受け取ったりする。処理部28は、これらの情報にもとづいて、端末装置14に送信すべきデータを生成する。また、処理部28は、ネットワーク通信部32を介して図示しないサーバ装置から、新たな共通鍵テーブルを受け取ると、検証部40の記憶部44に書き込む。制御部30は、基地局装置10全体の処理を制御する。
この構成は、ハードウエア的には、任意のコンピュータのCPU、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
図15は、車両12に搭載された端末装置14の構成を示す。端末装置14は、アンテナ50、RF部52、変復調部54、MACフレーム処理部56、受信処理部58、データ生成部60、検証部62、通知部70、制御部72を含む。検証部62は、暗号部1064、記憶部1066、生成部1076、判定部1074を含む。アンテナ50、RF部52、変復調部54、MACフレーム処理部56、検証部62、記憶部1066、暗号部1064は、図2のアンテナ20、RF部22、変復調部24、MACフレーム処理部26、検証部40、暗号部42、記憶部44と同様の処理を実行する。そのため、ここでは、同様の処理の説明を割愛し、差異を中心に説明する。
検証部62は、検証部40と同様に、セキュリティフレームの生成および解釈を行う。つまり、記憶部1066は、RF部52等におけるパケット信号の送受信に使用可能な共通鍵が複数種類示された共通鍵テーブルを記憶しており、検証部62は、検証部40と同様に、記憶部1066において記憶した共通鍵テーブルから、いずれかの共通鍵を選択する。また、検証部62は、選択した共通鍵を使用して、RF部52等において受信したパケット信号に添付された電子署名を検証するか、あるいはRF部52等から送信すべきパケット信号に添付される電子署名を生成する。なお、検証部62は、暗号化や復号に共通鍵を使用してもよい。
判定部1074は、記憶部1066に記憶した共通鍵テーブルを更新すべきタイミングを判定する。判定部1074は、共通鍵テーブルを更新すべき日時を予め保持しており、内部に含んだ図示しない時計によって取得した日時、予め設定した日時になったとき、生成部1076に対して共通鍵テーブル更新を指示する。ここで、共通鍵テーブルを更新すべき日時が定期的に定められることによって、共通鍵テーブルは、定期的に更新される。なお、他の端末装置と日時が大幅にずれることを防ぐために、データ生成部60に含まれる、GPS受信機によって取得される日時情報、あるいは、MACフレーム処理部56から受け取ったパケット信号に含まれる日時情報によって、内部に時計をアジャストする。ここでは、判定部1074は、内部に時計を含むように示したが、必ずしも、内部に時計を含む必要はない。データ生成部60に含まれる、GPS受信機によって取得される日時情報を取得して判定を行ってもよい。
生成部1076は、判定部1074から更新指示を受けた場合、記憶部1066に記憶した共通鍵テーブルに対して非可逆変換関数による演算を実行することによって、共通鍵テーブルを更新する。共通鍵テーブルを更新することは、共通鍵テーブルに含まれた複数の共通鍵をそれぞれ更新することに相当する。なお、非可逆変換関数は、予め定められているとする。図16(a)−(c)は、生成部1076による共通鍵テーブルの更新の概要を示す。ここで、テーブルIDによって管理できる最大数をM(Mは、自然数)とすると、テーブルIDは、Mを法とした剰余系に値であり、N−1、N、N+1はMを法とした剰余値である。図16(a)では、記憶部1066に記憶された最新の共通鍵テーブル、つまりテーブルIDがNの共通鍵テーブル対して、非可逆変換関数f1を使用することによって、新たな共通鍵テーブルを生成することが示される。新たな共通鍵テーブルのテーブルIDはN+1である。
また、図16(b)では、記憶部1066に記憶された過去の共通テーブル、つまりテーブルIDがN−1の共通鍵テーブル対して、非可逆変換関数f2を使用することによって、新たな共通鍵テーブルを生成することが示される。さらに、図16(c)では、記憶部1066に記憶された最新の共通鍵テーブルと過去の共通鍵テーブル、つまりテーブルIDがNとテーブルIDがN−1の共通鍵テーブル対して、非可逆変換関数f3を使用することによって、新たな共通鍵テーブルを生成することが示される。この場合、ふたつの共通鍵テーブルを使用して、ひとつの共通鍵テーブルが生成される。新たな共通鍵テーブルは、記憶部1066に記録される。このとき、記憶部1066の新しい領域に記憶してもよいし、最も古い共通鍵テーブルに上書き記録してもよい。記憶部1066が、図14のごとく、2つの共通鍵テーブルしか記録できない場合、新たな共通鍵テーブル(テーブルID=N+1)は、最も古い共通鍵テーブル(テーブルID=N+1)と置き換えられる。また、2つの共通鍵テーブルを記憶していることを前提として、共通鍵テーブルの更新の概念を述べたが、新たな共通鍵テーブルを生成するもととなる以前の共通鍵テーブルを限定するものではない。更新以前の1つあるいは複数の共通鍵テーブルを元として新たな共通鍵テーブルを生成するように構成できる。この場合、記憶部1066は、新たな共通鍵テーブルを生成の元となる共通鍵テーブルを記憶していなければならない。図15に戻る。
判定部1074は、MACフレーム処理部56から受け取ったパケット信号に含まれたテーブルIDをもとに、共通鍵テーブルを更新すべきタイミングを取得してもよい。具体的には説明すると、検証部62は、メッセージタイプデータのデータ形式が署名付きデータあるいは暗号化データであって、テーブルIDの共通鍵テーブルが記憶部1066に記憶されていない場合、生成部1076にて、パケット信号に含まれたテーブルIDと共通鍵IDに対応した共通鍵を生成する。そして、検証部62は、メッセージタイプデータのデータ形式が署名付きデータの場合に、生成部1076において生成した共通鍵を使用して、暗号部1064にてセキュリティヘッダとペイロードに対する電子署名を演算する。また、検証部62は、メッセージタイプが暗号データの場合に、生成部1076において生成した共通鍵を使用して、暗号部42にてセキュリティヘッダに対する電子署名を演算し、ペイロードを復号する。これらの処理が正常になされた場合、判定部1074は、生成した共通鍵が正しいと判断する。生成した共通鍵が正しい場合、判定部1074は、生成部1076に対して、先のテーブルIDの共通鍵テーブルへの更新を指示する。制御部72は、端末装置14全体の動作を制御する。
以上の構成による通信システム100のパケット信号の送受信に関わる動作を説明する。図17は、端末装置14における共通鍵テーブルのメンテナンス手順を示すフローチャートである。判定部1074は、現在の日時と、記憶部1066に記憶されている最新の共通鍵テーブルのテーブルID、更新日時により導かれる更新予定日時を共通鍵テーブルの更新タイミングを判断する(S1010)。判定部1074は、更新タイミングだと判断した場合(S1010のY)、生成部1076は、共通鍵テーブルを更新する(S1014)。判定部1074は、更新タイミングでないと判断した場合(S1010のN)、受信処理からの更新要求を確認する(S1012)。これは、MACフレーム処理部56から受け取ったパケット信号に含まれたテーブルIDをもとに、共通鍵テーブルを更新すべきかどうかの判断である。パケット信号に含まれたテーブルIDによって、共通鍵テーブルの更新要求を受け取っていると、更新のタイミングであると判断し(S1012のY)、つまりパケット信号に記憶していないテーブルIDで指定されたテーブルに含まれる共有鍵で署名、あるいは、暗号化されたデータを検出すれば、生成部1076は、共通鍵テーブルを更新する(S1014)。判定部1074は、受信処理からの更新要求を受けつけなければ、更新タイミングでないと判断し(S1012のN)、処理を終了する。
図18は、端末装置14におけるパケット信号の受信手順を示すフローチャートである。アンテナ50、RF部52、変復調部54は、パケット信号を受信する(S1030)。データ形式が署名付きあるいは暗号文であれば(S1032のN)、検証部62は、テーブルIDおよび共通鍵IDが記憶部1066に記憶されているかを確認する(S1034)。記憶部1066が鍵テーブルを有していれば(S1034のY)、検証部62は、記憶部1066から共通鍵を取得する(S1038)。記憶部1066が鍵テーブルを有していなければ(S1034のN)、生成部1076は、記憶部1066の共通鍵テーブルから鍵を演算する(S1036)。
データ形式が署名付きであれば(S1040のY)、検証部62は、取得した共通鍵にて、セキュリティヘッダの一部とペイロードに対する電子署名を演算する(S1042)。一方、データ形式が暗号文である場合(S1040のN)、検証部62は、取得した共通鍵にて復号する(S1044)。データの復号には、セキュリティヘッダの一部に対する電子署名の演算と、その値をIVとした暗号化されているペイロードの復号が含まれる。演算した電子署名の値と、セキュリティフッダの署名の値を比較して、両者が一致すればデータが正当であると判断する(S1046のY)。正当である場合、演算した共通鍵であれば(S1048のY)、判定部1074に対して、共通鍵テーブルの更新要求する(S1050)。演算した共通鍵でなければ(S1048のN)、ステップ1050はスキップされる。
データ形式が平文である場合(S1032のY)、ステップ1034からステップ1050はスキップされる。データ種別がメンテナンスデータである場合(S1052のY)、検証部40は、データを抽出する(S1054)。データ種別がアプリケーションデータである場合(S1052のN)、検証部40は、受信処理部58へデータを出力する(S1056)。データが正当でない場合(S1046のN)、検証部40は、データを破棄する(S1058)。
図19は、端末装置14におけるパケット信号の送信手順を示すフローチャートである。検証部62は、データを取得し、セキュアフレームを生成する(S1070)。メッセージタイプが署名付きあるいは暗号文である場合(S1072のN)、検証部62は、共通鍵を選択する(S1074)。メッセージタイプが署名付きであれば(S1076のY)、検証部62は、選択した共通鍵にて電子署名を演算する(S1078)。メッセージタイプが暗号文であれば(S1076のN)、検証部62は、選択した共通鍵にて暗号化を実行する(S1080)。メッセージタイプが平文であれば(S1072のY)、ステップ1074からステップ1080までの処理はスキップされる。変復調部54、RF部52、アンテナ50は、パケット信号を報知する(S1082)。
本発明の変形例において、共通鍵テーブルの更新タイミングの判断おいて、予約された日時による判断と、受信したパケット信号に含まれるテーブルIDに基づく2つの判断を併用するよう説明したが、いずれか、一方の判断によって共通鍵テーブルの更新タイミングを判断してもよい。前者のみの場合は、すべての端末装置14が、時計あるいはGPS等から日時情報を取得する手段を備えなければならない。また、後者の場合、基地局装置10、あるいは、新たに市場に投入された車両12に搭載された端末装置の記憶部1066に記憶されている最新の共通鍵テーブルが、共通鍵テーブル更新のきっかけとなり、すべての端末装置に普及する。また、端末装置14に付いて述べてきたが、基地局装置10に適用してもよい。特に、図2におけるネットワーク通信部32を備えない基地局に対して有効である。
本発明の変形例において、発信元種別に無関係に共通鍵テーブルを選択するように示したが、発信元種別毎の共通鍵テーブルを記憶部1066に格納し、パケット信号を報知する際に、自身の発信者種別にあった共通鍵テーブルを選択するようにしてもよい。パケット信号の受信時は、発信元種別とテーブルIDによって、共通鍵テーブルを選択する。共通鍵テーブルの更新タイミングは、それぞれ、独立して行ってもよいし、同じとしてもよい。共通鍵テーブルの更新タイミングが同じ場合には、共通鍵テーブルを更新する非可逆演算関数は、相互に共通鍵テーブルを引数とするようにしてもよい。また、発信元毎に、共通鍵テーブルを持つのではなく、記憶部1066に記憶されている共通鍵テーブルに含まれる共通鍵と、発信元種別とから、署名あるいは暗号化のための共通鍵を算出するようにしても同様な効果が得られる。これらの場合、署名あるいは暗号化に使用する共通鍵は、すでに、発信元種別に紐付けされているので、発信元種別を電子署名の演算対象から外しても構わない。このようにすることで、同時に運用する鍵の総数が増加する、共通鍵の解読に要されるサンプルデータ数が減る。とりわけ、救急車や消防車等の優先車両のサンプルデータ数が激減し、通信路からの共通鍵漏洩の危険性が低下する。
本発明の変形例において、生成部1076は、非可逆変換関数を予め保持する。しかしながらこれに限らず例えば、非可逆変換関数は基地局装置10から奉仕されてもよい。その場合、非可逆変換関数が含まれたパケット信号には、暗号化がなされる。本変形例によれば、非可逆変換関数を変更できる。
本発明の変形例によれば、端末装置が自律的に共通鍵テーブルを更新するので、基地局装置が共通鍵テーブルを配信しない場合であっても、安全性を向上できる。また、既に記憶した共通鍵テーブルに対して非可逆変換関数を演算させるので、基地局装置が共通鍵テーブルを配信しない場合であっても、自律的に共通鍵テーブルを更新できる。また、基地局装置による共通鍵テーブルの配信が不要になるので、周波数利用効率を改善できる。また、共通鍵テーブルの更新タイミングを定期的に判定することで、共通鍵テーブルを定期的に更新できる。また、受信したパケット信号から共通鍵テーブルの更新タイミングを判定するので、周囲の端末装置に合わせるように共通鍵テーブルを更新できる。
また、電子署名を生成するために共通鍵を使用するので、公開鍵を使用する場合と比較して処理量を低減できる。また、処理量が低減されるので、処理可能なパケット信号数を増加できる。また、電子署名を生成するために共通鍵を使用するので、公開鍵を使用する場合と比較して伝送効率を向上できる。また、位置情報等のデータに対しては暗号化を実行しないので、処理量を低減する。
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
本発明の実施例では、第1の共通鍵テーブルを受信可能なエリアを、基地局装置からのパケット信号を受信範囲とし、第1の共通鍵テーブルには、基地局装置IDのリストが含まれる旨示したが、第1の共通鍵テーブル使用エリアを座標によって表現してもよい。ここで、座標とは、複数の地球上の座標点、すなわち、経度と緯度で表される点をいい、例えば、利用可能エリアはリストに複数の座標に囲まれた内側の地域とすることができる。この場合、第1の共通鍵テーブルには、使用可能なエリアを指定する複数の座標をリストに含む。また、1つの座標点から同一距離にある地域とすることもできる。この場合、第1の共通鍵テーブルには、使用可能なエリアを指定する情報として、座標と距離の組みを1あるいは複数含む。なお、第1の共通鍵テーブルは、使用可能なエリアを指定する情報のリストを含むように記したが、必ずしもいったとなっている必要はない。第1の共通鍵テーブルと別に、第1の共通鍵テーブルの使用可能なエリアを指定する情報のリストを持っても良い。この場合、両者は紐付けされている。
本発明の実施例において、通信システム100は、2種類の共通鍵テーブルを規定する。しかしながらこれに限らず例えば、通信システム100は、3種類以上の共通鍵テーブルを規定してもよい。その際、第1の共通鍵テーブルが複数種類規定される。所定の基地局装置10の周囲では、所定の第1の共通鍵テーブルが使用され、別の基地局装置10の周囲では、別の第1の共通鍵テーブルが使用される。本変形例によれば、更新すべき共通鍵テーブルが使用されるエリアをさらに限定できる。
本発明の変形例において、判定部68は、パケット信号に含まれた基地局装置10の識別情報をもとに、第1の共通鍵テーブルを使用可能なエリアに存在するかを判定している。しかしながらこれに限らず例えば、判定部68は、GPS等によって取得した位置情報をもとに、第1の共通鍵テーブルを使用可能なエリアに存在するかを判定してもよい。本変形例によれば、第1の共通鍵テーブルを使用可能なエリアを位置情報に対応づけて規定できる。
本実施例は、次の項目によって特徴付けられてもよい。
(項目1)
共通鍵暗号方式における共通鍵によって生成した電子署名が添付されたパケット信号を送受信する通信部と、
前記通信部におけるパケット信号の送受信に使用可能な共通鍵が複数種類示された共通鍵テーブルを記憶する記憶部と、
前記記憶部において記憶した共通鍵テーブルから、いずれかの共通鍵を選択する選択部と、
前記選択部において選択した共通鍵を使用して、前記通信部において受信したパケット信号に添付された電子署名を検証するか、あるいは前記通信部から送信すべきパケット信号に添付される電子署名を生成する処理部とを備え、
前記処理部は、前記記憶部に記憶した共通鍵テーブルに対して、変換関数による演算を実行することによって、共通鍵テーブルを更新することを特徴とする無線装置。
この場合、暗号鍵を自律的に更新できる。
(項目1)
共通鍵暗号方式における共通鍵によって生成した電子署名が添付されたパケット信号を送受信する通信部と、
前記通信部におけるパケット信号の送受信に使用可能な共通鍵が複数種類示された共通鍵テーブルを記憶する記憶部と、
前記記憶部において記憶した共通鍵テーブルから、いずれかの共通鍵を選択する選択部と、
前記選択部において選択した共通鍵を使用して、前記通信部において受信したパケット信号に添付された電子署名を検証するか、あるいは前記通信部から送信すべきパケット信号に添付される電子署名を生成する処理部とを備え、
前記処理部は、前記記憶部に記憶した共通鍵テーブルに対して、変換関数による演算を実行することによって、共通鍵テーブルを更新することを特徴とする無線装置。
この場合、暗号鍵を自律的に更新できる。
10 基地局装置、 12 車両、 14 端末装置、 20 アンテナ、 22 RF部、 24 変復調部、 26 MACフレーム処理部、 28 処理部、 30 制御部、 32 ネットワーク通信部、 34 センサ通信部、 40 検証部、 42 暗号部、 44 記憶部、 50 アンテナ、 52 RF部、 54 変復調部、 56 MACフレーム処理部、 58 受信処理部、 60 データ生成部、 62 検証部、 64 暗号部、 66 記憶部、 68 判定部、 70 通知部、 72 制御部、 100 通信システム。
Claims (2)
- 車両に搭載され、基地局装置との間での通信を行う端末装置であって、
前記基地局装置から報知されたパケット信号であって、かつ共通鍵が複数種類示された第1の共通鍵テーブルを記憶するとともに、第1の共通鍵テーブルとは異なった第2の共通鍵テーブルを記憶した前記基地局装置において、記憶した第2の共通鍵テーブルに含まれた共通鍵を使用して生成されたパケット信号を受信する受信部と、
前記基地局装置との間で共有される第2の共通鍵テーブルを記憶する記憶部と、
前記受信部が受信したパケット信号を検証する検証部とを備え、
前記受信部において受信したパケット信号の報知元になる前記基地局装置は、記憶した第1の共通鍵テーブルが格納されたパケット信号も生成しており、
前記検証部は、前記受信部が受信したパケット信号に第1の共通鍵テーブルが含まれる場合、第1の共通鍵テーブルが本端末装置の前記記憶部に未記録であれば、当該第1の共通鍵テーブルを前記記憶部に記憶し、第1の共通鍵テーブルが本端末装置の前記記憶部に記録されていれば、当該第1の共通鍵テーブルを破棄することを特徴とする端末装置。 - 本端末装置の前記記憶部に記憶した第1の共通鍵テーブルに含まれた共通鍵を使用してパケット信号を生成する生成部と、
前記生成部において生成したパケット信号を、アンテナから報知させるためにアンテナに出力する変調部とをさらに備えることを特徴とする請求項1に記載の端末装置。
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010124967 | 2010-05-31 | ||
JP2010124967 | 2010-05-31 | ||
JP2010134941 | 2010-06-14 | ||
JP2010134941 | 2010-06-14 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015030961A Division JP5899457B2 (ja) | 2010-05-31 | 2015-02-19 | 端末装置 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016248279A Division JP6273561B2 (ja) | 2010-05-31 | 2016-12-21 | 端末装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2016105596A JP2016105596A (ja) | 2016-06-09 |
JP6074824B2 true JP6074824B2 (ja) | 2017-02-08 |
Family
ID=45066433
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012518250A Active JP5789745B2 (ja) | 2010-05-31 | 2011-05-31 | 基地局装置 |
JP2015030961A Active JP5899457B2 (ja) | 2010-05-31 | 2015-02-19 | 端末装置 |
JP2015241036A Active JP6074824B2 (ja) | 2010-05-31 | 2015-12-10 | 端末装置 |
JP2016248279A Active JP6273561B2 (ja) | 2010-05-31 | 2016-12-21 | 端末装置 |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012518250A Active JP5789745B2 (ja) | 2010-05-31 | 2011-05-31 | 基地局装置 |
JP2015030961A Active JP5899457B2 (ja) | 2010-05-31 | 2015-02-19 | 端末装置 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016248279A Active JP6273561B2 (ja) | 2010-05-31 | 2016-12-21 | 端末装置 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20130182844A1 (ja) |
JP (4) | JP5789745B2 (ja) |
CN (1) | CN102577227A (ja) |
WO (1) | WO2011152042A1 (ja) |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5459176B2 (ja) * | 2010-04-07 | 2014-04-02 | 株式会社デンソー | 無線通信装置およびデータ通信装置 |
JP5724389B2 (ja) * | 2011-01-07 | 2015-05-27 | 住友電気工業株式会社 | 通信システム |
JP5435513B2 (ja) * | 2012-01-27 | 2014-03-05 | トヨタ自動車株式会社 | 暗号通信システム、鍵配布装置、暗号通信方法 |
JP6102109B2 (ja) * | 2012-07-25 | 2017-03-29 | 住友電気工業株式会社 | 路側通信機、無線通信システム、及び送信方法 |
US9154481B1 (en) * | 2012-12-13 | 2015-10-06 | Emc Corporation | Decryption of a protected resource on a cryptographic device using wireless communication |
US9819488B2 (en) * | 2014-07-10 | 2017-11-14 | Ohio State Innovation Foundation | Generation of encryption keys based on location |
JP2016045860A (ja) | 2014-08-26 | 2016-04-04 | 株式会社デンソー | 車両用データ変換装置及び車両用データ出力方法 |
JP6477714B2 (ja) * | 2014-09-02 | 2019-03-06 | 大日本印刷株式会社 | 通信装置、鍵データ更新方法、及び鍵データ更新処理プログラム |
JP6197000B2 (ja) * | 2015-07-03 | 2017-09-13 | Kddi株式会社 | システム、車両及びソフトウェア配布処理方法 |
CN107005844B (zh) * | 2015-07-31 | 2020-12-04 | 华为技术有限公司 | 一种通信方法及相关装置 |
JP6567376B2 (ja) | 2015-09-25 | 2019-08-28 | パナソニック株式会社 | 装置 |
JP6183436B2 (ja) * | 2015-10-08 | 2017-08-23 | 住友電気工業株式会社 | 車載機及び共通鍵の更新の契機を得る方法 |
CN105635177A (zh) * | 2016-02-23 | 2016-06-01 | 苏州元禾医疗器械有限公司 | 一种加密数据传输方法、装置及*** |
JP6171046B1 (ja) * | 2016-04-26 | 2017-07-26 | 京セラ株式会社 | 電子機器、制御方法、及び制御プログラム |
KR102028151B1 (ko) * | 2017-04-07 | 2019-10-02 | 주식회사트러스트홀딩스 | 장치 인증키를 이용한 데이터 암호화 방법 및 시스템 |
CN107085961A (zh) * | 2017-06-22 | 2017-08-22 | 公安部交通管理科学研究所 | 一种车载终端、获取路***通信号控制信息的方法及*** |
JP6669154B2 (ja) * | 2017-12-19 | 2020-03-18 | 株式会社デンソー | 車両用データ変換装置及び車両用データ出力方法 |
CN109474909B (zh) * | 2018-08-28 | 2020-07-24 | 北京交通大学 | 用于ctcs-3级列控***车地安全通信协议的密钥管理方法 |
DE102019207753A1 (de) * | 2019-05-27 | 2020-12-03 | Robert Bosch Gmbh | Verfahren zum Ansteuern eines Fahrzeugs |
JP7028833B2 (ja) * | 2019-07-31 | 2022-03-02 | パナソニック株式会社 | 装置、プロセッサ、制御方法、プログラム |
KR20210063168A (ko) * | 2019-11-22 | 2021-06-01 | 삼성전자주식회사 | 무선 접속 망에서 사업자 특정 서비스를 지원하기 위한 장치 및 방법 |
JPWO2023084694A1 (ja) * | 2021-11-11 | 2023-05-19 |
Family Cites Families (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2595899B2 (ja) * | 1994-05-17 | 1997-04-02 | 日本電気株式会社 | オンライン伝文暗号化装置 |
JP3555345B2 (ja) * | 1996-08-09 | 2004-08-18 | 株式会社日立製作所 | 自動料金収受システムの車載機 |
JP3445490B2 (ja) * | 1998-03-25 | 2003-09-08 | 株式会社日立製作所 | 移動体通信方法および移動体通信システム |
JP2000151578A (ja) * | 1998-11-10 | 2000-05-30 | Mitsubishi Electric Corp | 暗号通信装置 |
US8472627B2 (en) * | 2000-10-30 | 2013-06-25 | Geocodex Llc | System and method for delivering encrypted information in a communication network using location indentity and key tables |
WO2002076011A1 (fr) * | 2001-03-19 | 2002-09-26 | Yozan Inc. | Systeme de communication cryptee |
DE60322929D1 (de) * | 2003-12-23 | 2008-09-25 | Motorola Inc | Schlüsselaktualisierung in sicherer Multicastkommunikation |
JP4559794B2 (ja) * | 2004-06-24 | 2010-10-13 | 株式会社東芝 | マイクロプロセッサ |
JP4619858B2 (ja) * | 2004-09-30 | 2011-01-26 | 株式会社日立製作所 | 分散環境における暗号鍵更新方法、暗号鍵更新システム、暗号鍵更新システムを構成する無線基地局 |
JP4192893B2 (ja) * | 2005-01-11 | 2008-12-10 | 住友電気工業株式会社 | 信号制御情報通信システム |
KR101153640B1 (ko) * | 2005-05-04 | 2012-06-18 | 삼성전자주식회사 | 디지털 멀티미디어 방송 수신 제한 시스템 및 그 방법 |
US8266431B2 (en) * | 2005-10-31 | 2012-09-11 | Cisco Technology, Inc. | Method and apparatus for performing encryption of data at rest at a port of a network device |
US7945070B2 (en) * | 2006-02-24 | 2011-05-17 | Digimarc Corporation | Geographic-based watermarking keys |
JP2008060789A (ja) * | 2006-08-30 | 2008-03-13 | Toyota Infotechnology Center Co Ltd | 公開鍵配布システムおよび公開鍵配布方法 |
JP4950868B2 (ja) * | 2007-12-18 | 2012-06-13 | 株式会社東芝 | 情報処理装置及び情報処理方法 |
JP5163192B2 (ja) * | 2008-03-13 | 2013-03-13 | 株式会社デンソー | 無線通信システム及び無線通信方法 |
-
2011
- 2011-05-31 JP JP2012518250A patent/JP5789745B2/ja active Active
- 2011-05-31 CN CN2011800034017A patent/CN102577227A/zh active Pending
- 2011-05-31 WO PCT/JP2011/003056 patent/WO2011152042A1/ja active Application Filing
-
2012
- 2012-11-30 US US13/691,096 patent/US20130182844A1/en not_active Abandoned
-
2015
- 2015-02-19 JP JP2015030961A patent/JP5899457B2/ja active Active
- 2015-12-10 JP JP2015241036A patent/JP6074824B2/ja active Active
-
2016
- 2016-12-21 JP JP2016248279A patent/JP6273561B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP5789745B2 (ja) | 2015-10-07 |
JP6273561B2 (ja) | 2018-02-07 |
CN102577227A (zh) | 2012-07-11 |
JP2015100132A (ja) | 2015-05-28 |
JP5899457B2 (ja) | 2016-04-06 |
US20130182844A1 (en) | 2013-07-18 |
WO2011152042A1 (ja) | 2011-12-08 |
JP2016105596A (ja) | 2016-06-09 |
JP2017103780A (ja) | 2017-06-08 |
JPWO2011152042A1 (ja) | 2013-07-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6273561B2 (ja) | 端末装置 | |
JP6273658B2 (ja) | 基地局装置 | |
JP5362925B2 (ja) | 路側機および車載器 | |
JP5390036B2 (ja) | 車載器 | |
JP6112467B2 (ja) | 通信装置 | |
JP5991561B2 (ja) | 無線装置 | |
JP2014158105A (ja) | 端末装置 | |
JP6187888B2 (ja) | 処理装置 | |
JP5903629B2 (ja) | 無線装置 | |
JP2014158104A (ja) | 端末装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20161122 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20161221 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 6074824 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |