JP5341274B1 - 車載器 - Google Patents
車載器 Download PDFInfo
- Publication number
- JP5341274B1 JP5341274B1 JP2013116769A JP2013116769A JP5341274B1 JP 5341274 B1 JP5341274 B1 JP 5341274B1 JP 2013116769 A JP2013116769 A JP 2013116769A JP 2013116769 A JP2013116769 A JP 2013116769A JP 5341274 B1 JP5341274 B1 JP 5341274B1
- Authority
- JP
- Japan
- Prior art keywords
- common key
- unit
- vehicle
- data
- packet signal
- 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
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/16—Anti-collision systems
- G08G1/161—Decentralised systems, e.g. inter-vehicle communication
- G08G1/163—Decentralised systems, e.g. inter-vehicle communication involving continuous checking
-
- 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/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
- H04W12/041—Key generation or derivation
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
- H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
- H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/02—Data link layer protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/08—Access point devices
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)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Mobile Radio Communication Systems (AREA)
- Traffic Control Systems (AREA)
Abstract
記憶部44は、端末装置間の通信に使用可能な共通鍵が複数種類示された共通鍵テーブルを記憶する。MACフレーム処理部26は、端末装置から報知されたパケット信号を受信する。確認部は、受信したパケット信号に添付された電子署名を生成するための共通鍵が含まれた共通鍵テーブルのバージョンを確認する。検出部46は、確認した共通鍵テーブルのバージョンが、記憶部44に記憶した共通鍵テーブルのバージョンよりも前であることを検出する。MACフレーム処理部26は、検出数が単位期間において所定回数以上であれば、記憶部44において記憶した共通鍵テーブルが格納されたパケット信号を生成する。MACフレーム処理部26は、生成したパケット信号を報知する。
【選択図】図2
【選択図】図2
Description
本発明は、通信技術に関し、特に所定の情報が含まれた信号を送受信する車載器に関する。
交差点の出会い頭の衝突事故を防止や渋滞の緩和を目的とした路車間通信による道路情報、あるいは、交差点情報の提供、および、車車間通信による車両の運行情報の相互提供する運転支援システムの検討がなされている。路車間通信では、路側機と車載器との間において交差点の状況に関する情報が通信される。路車間通信では、交差点や路側に路側機の設置が必要になり、手間と費用が大きくなる。これに対して、車車間通信、つまり車両に搭載された車載器間で情報を通信する形態であれば、路側機の設置が不要になる。その場合、例えば、GPS(Global Positioning System)等によって現在の位置情報をリアルタイムに検出し、その位置情報を車載器同士で交換しあうことによって、自車両および他車両がそれぞれ交差点へ進入するどの道路に位置するかを判断する(例えば、特許文献1参照)。
無線通信は、有線通信に比較して通信の傍受が容易になるので、通信内容の秘匿性を確保することが困難になる。また、ネットワーク経由で機器の制御を行う場合、第三者のなりすましにより不正な通信による操作が行われるおそれがある。無線通信において、通信内容の秘匿性を確保するためには、通信データを暗号化し、かつ、暗号化の際に使用する鍵を定期的に更新する必要がある。例えば、ネットワーク装置のそれぞれは、暗号鍵の更新の際、更新前に使用されている旧暗号鍵によって暗号化が行われたデータのみの送受信が可能な初期状態にある。この状態から、各装置は、旧暗号鍵および更新後の新暗号鍵によって暗号化が行われた双方のデータの送受信を行うことが可能で、新暗号鍵によって暗号化が行われたデータの送受信に関しては動作未確認の状態に移行する。さらに、各装置は、旧暗号鍵、新暗号鍵の双方で暗号化されたデータの送受信が可能であり、新暗号鍵で暗号化されたデータの送受信に関しても動作確認済みの状態に遷移する。最終的に、各装置は、鍵更新完了後の新暗号鍵によって暗号化されたデータのみの送受信が可能な状態に順次遷移する(例えば、特許文献2参照)。
無線LANを車車間通信に適用する場合、不特定多数の端末装置へ情報を送信する必要があるために、信号はブロードキャストにて送信されることが望ましい。しかしながら、交差点などでは、車両数の増加、つまり端末装置数の増加がトラヒックを増加させることによって、パケット信号の衝突の増加が想定される。その結果、パケット信号に含まれたデータが他の端末装置へ伝送されなくなる。このような状態が、車車間通信において発生すれば、交差点の出会い頭の衝突事故を防止するという目的が達成されなくなる。さらに、車車間通信に加えて路車間通信が実行されれば、通信形態が多様になる。その際、車車間通信と路車間通信との間における相互の影響の低減が要求される。
また、暗号化のための鍵を更新する場合、これまではユニキャスト通信を前提としていたので、複数の状態を遷移させることが容易であった。ブロードキャスト通信を使用する場合、異なった状態の端末装置が存在すれば、共通した暗号鍵の使用が困難になる。また、新たな暗号鍵の配布のためにトラヒックが増加するが、周波数利用効率の悪化を抑制させたい。また、新たな暗号鍵を使用可能な端末装置が存在すれば、新たな暗号鍵を使用不可能な端末装置も存在する。その結果、すべての端末装置に対して、新たな暗号鍵を使用させることは困難である。一方、通信システムの安全性を向上させるためには、新たな暗号鍵の使用が好ましい。
本発明はこうした状況に鑑みてなされたものであり、その目的は、ブロードキャスト通信に適した暗号鍵の使用技術を提供することにある。
上記課題を解決するために、本発明のある態様の基地局装置は、共通鍵暗号方式における共通鍵によって生成した電子署名が添付されたパケット信号を報知すべき端末装置間の通信を制御する基地局装置であって、端末装置間の通信に使用可能な共通鍵が複数種類示された共通鍵テーブルを記憶する記憶部と、端末装置から報知されたパケット信号を受信する受信部と、受信部において受信したパケット信号に添付された電子署名を生成するための共通鍵が含まれた共通鍵テーブルのバージョンを確認する確認部と、確認部において確認した共通鍵テーブルのバージョンが、記憶部に記憶した共通鍵テーブルのバージョンよりも前であることを検出する検出部と、検出部における検出数が単位期間において所定回数以上であれば、記憶部において記憶した共通鍵テーブルが格納されたパケット信号を生成する生成部と、生成部において生成したパケット信号を報知する報知部と、を備える。
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
本発明によれば、ブロードキャスト通信に適した暗号鍵の使用技術を提供できる。
本発明を具体的に説明する前に、概要を述べる。本発明の実施例は、車両に搭載された端末装置間において車車間通信を実行するとともに、交差点等に設置された基地局装置から端末装置へ路車間通信も実行する通信システムに関する。車車間通信として、端末装置は、車両の速度や位置等の自車両情報を格納したパケット信号をブロードキャストにより送信する(以下、パケット信号をブロードキャストによる送信を「報知」という)。また、他の端末装置は、パケット信号を受信するとともに、データをもとに車両の接近等を認識する。また、路車間通信として、基地局装置は、交差点情報、渋滞情報、および、セキュリティ情報等が格納されたパケット信号を報知する。以下、説明を簡単にするために、車車間通信および路車間通信のパケット信号に含まれる情報の総称を「データ」という。
交差点情報は、交差点の位置、基地局装置が設置された交差点の撮影画像や、交差点内の車両の位置情報等の交差点の状況に関する情報が含まれる。端末装置は、この交差点情報をモニタに表示、この交差点情報をもとに交差点車両の状況を認識して、出会い頭・右折・左折による衝突防止を目的とした他の車両や歩行者の存在等をユーザにする伝達し、事故の防止を図る。また、渋滞情報は、基地局装置が設置された交差点近辺の走路の混雑状況、道路工事や事故に関する情報が含まれる。この情報を元に進行方向の渋滞をユーザに伝達、あるいは、迂回路を提示する。セキュリティ情報では、共通鍵テーブルの提供等のデータを保護に関する情報が含まれる。詳細については、後述する。
また、このような通信においてなりすまし等を抑制するために、電子署名が使用される。電子署名を生成するためには、暗号鍵が使用される。本実施例に係る通信システムでは、処理の負荷を考慮し、暗号鍵として共通鍵を使用する。また、共通鍵の漏洩リスクを低減去るために複数の共通鍵を使用する。ひとつの共通鍵をひとつの鍵IDとして管理する。複数の共通鍵を共通鍵テーブルにまとめ、共通鍵テーブルのバージョンは、テーブルIDとして管理される。さらに、鍵テーブル内の個々の共通鍵は、共通鍵IDとして管理される。そのため、鍵IDには、テーブルIDと、共通鍵IDが含まれる。このように規定されることによって、なりすましが防止されるとともに、処理量の増加および周波数利用効率の悪化が抑制される。
図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では、共通鍵暗号方式における共通鍵によって生成した電子署名が添付されたパケット信号が報知される。電子署名とは、パケット信号に含まれたデータ等の電磁的記録に付与すべき電子的な署名である。これは、紙文書における印や署名に相当し、主に本人確認、偽造・かいざんの防止のために使用される。具体的に説明すると、ある文書についてその作成者として文書に記載されている者がある場合、その文書が本当にその作成名義人によって作成されたものであることは、紙の文書の場合、その文書に付されたその作成者の署名や印によって証明される。しかしながら、電子文書には直接印を押したり署名を付したりすることはできないので、これを証明するために、電子署名が使用される。電子署名を生成するためには、暗号が使用される。
電子署名として、公開鍵暗号方式に基づくデジタル署名が有力である。公開鍵暗号方式に基づく方式として、具体的には、RSA、DSA、ECDSA等が使用される。電子署名方式は、鍵生成アルゴリズム、署名アルゴリズム、検証アルゴリズムによって構成される。鍵生成アルゴリズムは電子署名の事前準備に相当する。鍵生成アルゴリズムは、ユーザの公開鍵および秘密鍵を出力する。鍵生成アルゴリズムが実行される度に異なる乱数が選ばれるので、ユーザごとに異なる公開鍵・秘密鍵ペアが割り振られる。各ユーザは、秘密鍵を保管し、公開鍵を公開する。公開鍵は第三者機関である認証局(図せず。)にてデジタル署名を付けた公開鍵証明書の形式で公開される。
署名を作成したユーザは、その署名文に対する署名者とよばれる。署名者は、署名アルゴリズムによって署名文を作成する際、メッセージとともに自分の秘密鍵を入力する。署名者の秘密鍵を知っているのは署名者本人だけのはずなので、電子署名を付したメッセージの作成者を識別する根拠になる。公開鍵証明書と電子署名を付したメッセージを受け取ったユーザである検証者は、検証アルゴリズムを実行することによって、電子署名が正しいか否かを検証する。その際、検証者は検証アルゴリズムに受け取った公開鍵証明書と認証局の公開鍵を入力して署名者の公開鍵の検証を行う。検証アルゴリズムは署名者の公開鍵の正当性の判断を行う。そして正当であると判断されると、検証者は検証アルゴリズムに受け取った電子署名を付したメッセージと署名者の公開鍵を入力する。検証アルゴリズムはメッセージが本当にそのユーザによって作成されたか否かを判定し、その結果を出力する。このような公開の仕組みはPKI(Publick Key Infrastructure)と呼ばれる。
このような公開鍵暗号方式の処理負荷は、一般的に大きい。例えば、交差点近傍では、例えば、100msecの間に500台の端末装置14からのパケット信号を処理しなければならなくなる。また、通信システム100において車両12に搭載された端末装置から報知されるパケット信号には、100バイト程度のデータが格納される。これに対して、公開鍵暗号方式の公開鍵証明書と電子署名は、200バイト程度になってしまい、伝送効率の低下が大きくなってしまう。また、公開鍵方式における電子署名の検証の演算処理は大きく、100msecの間に500台の端末装置14からのパケット信号を処理しようとすると、高機能の暗号演算装置あるいはコントローラを必要になってしまい、端末装置のコストが増加する。これに対して、共通鍵暗号方式を用いた電子署名がある。共通鍵暗号方式では、暗号化に用いる鍵と同じ鍵が復号鍵として使用される。共通鍵方式では、送信側と受信側との間で事前に鍵の共有が必要となる。よって受信側の端末装置にとって復号鍵が既知であり、鍵の証明書が不要になるので、公開鍵暗号方式と比較して伝送効率の悪化が抑制される。また、共通鍵暗号方式は、公開鍵暗号方式と比較して処理量が少ない。代表的な共通鍵暗号方式は、DES、AES(Advanced Encryption Standard)である。通信システム100では、伝送負荷および処理負荷を考慮し、暗号方式として共通鍵暗号方式を採用する。なお、公開鍵暗号方式のデジタル署名に対して、共通鍵暗号方式はメッセージ認証と呼ばれる。その際、署名の代わりにMAC(Message Authentication Code)がメッセージに添付される。このMACの代表的な方式が、CBC−MAC(Cipher Block Chaining MAC)である。
前述のように共通鍵の漏洩リスクを低減去るために複数の共通鍵を使用する。通信システム100は、共通鍵はテーブルIDで管理される共通鍵テーブルのバージョンアップに対応する。共通鍵テーブルのバージョンアップは、基地局装置10が、新たな共通鍵テーブルをパケット信号に格納して報知することによってなされる。共通鍵テーブルには、運用開始日時と有効期限が規定されているので、運用開始日時より前に、共通鍵テーブルの報知がなされる。
図2は、基地局装置10の構成を示す。基地局装置10は、アンテナ20、RF部22、変復調部24、MACフレーム処理部26、検証部40、処理部28、制御部30、ネットワーク通信部32、センサ通信部34を含む。また、検証部40は、暗号部42、記憶部44、検出部46を含む。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)、すなわち、後続のMACフレーム処理部26へ出力されるデータであるか、メンテナンスデータ(=1)、すなわち、検証部40の内部で処理されるセキュリティ情報であるかを識別するフラグ情報を設定するものとする。
通信システム100において、メンテナンスデータは、共通鍵テーブルである。データ形式は、ペイロードに格納されるデータのセキュリティに関わる形式、つまり、ペイロードに対する暗号処理を規定するフラグである。ここでは、平文データ(=0)、署名付きデータ(=1)、暗号化データ(=2)を設定するものとする。なお、リザーブは将来に対する予備であり、通信システム100では使用しない。鍵IDは、電子署名あるいはペイロードの暗号化に使用した共通鍵を特定する識別情報で、テーブルIDと共通鍵IDを連結したものである。発信元種別IDは、パケット信号の発信者の種類、すなわち、基地局装置10(=3)、救急車や消防車のような緊急車両(優先車両と呼ぶ)に搭載の端末装置(=2)、その他の車両(一般車両とよぶ)に搭載の端末装置(=1)および非車両搭載の端末装置(=0)が設定するものとする。発信元IDは、パケット信号を発信した基地局装置10あるいは端末装置14を、一意に特定できる装置毎にユニークな識別情報である。ペイロードは、前述のデータを格納するフィールドであり、交差点情報や道路情報等の端末装置へ通知すべき情報に相当する。また、メッセージタイプのデータ形式が署名付きデータ(=1)の時、ペイロードヘッダおよびペイロードに対する電子署名、すなわちMAC値を格納するフィールドである。また、メッセージタイプのデータ形式が暗号化データ(=2)の時、無効としても良いが、ここでは固定値、ペイロードヘッダの部分の写しなどの受信側特定可能な値、あるいは、ペイロードヘッダまたは/および暗号化前のペイロードに対するハッシュ値(ハッシュ関数による演算結果)、チェックサム、パリティなどの受信側で演算可能な値、あるいは、署名付きデータ(=1)の時と同様に電子署名を格納するものとする。そして、ペイロードおよび署名をまとめて暗号化する。このようにすることで、復号によって得られた署名に格納された値と、受信側で特定した、あるいは、演算した値とが一致すれば、復号が正常に行われ、ペイロードに格納されているデータ、あるいはペイロードヘッダとペイロードに格納されているデータの正当性が確認できる。各フィード長さは、例えば、ペイロードヘッダが32バイト、ペイロードが100バイト(端末装置が報知する場合)あるいは1Kバイト(基地局装置が報知する場合)、署名が16バイトである。通信システム100では、暗号方式としてAES暗号を使用する。そして、メッセージタイプのデータ形式が署名付きデータの場合には、電子署名は、CBC−MACによって求めたMAC値を署名に格納する。メッセージタイプのデータ形式が暗号化データの場合には、ペイロードヘッダに対するMAC値を署名に格納し、ペイロードおよび署名を、CBCモードで暗号化する。なお、署名にMAC値を格納する場合は、他の暗号化モード、例えばカウンタモードで暗号化を行うようにしてもよい。図2に戻る。
通信システム100において、メンテナンスデータは、共通鍵テーブルである。データ形式は、ペイロードに格納されるデータのセキュリティに関わる形式、つまり、ペイロードに対する暗号処理を規定するフラグである。ここでは、平文データ(=0)、署名付きデータ(=1)、暗号化データ(=2)を設定するものとする。なお、リザーブは将来に対する予備であり、通信システム100では使用しない。鍵IDは、電子署名あるいはペイロードの暗号化に使用した共通鍵を特定する識別情報で、テーブルIDと共通鍵IDを連結したものである。発信元種別IDは、パケット信号の発信者の種類、すなわち、基地局装置10(=3)、救急車や消防車のような緊急車両(優先車両と呼ぶ)に搭載の端末装置(=2)、その他の車両(一般車両とよぶ)に搭載の端末装置(=1)および非車両搭載の端末装置(=0)が設定するものとする。発信元IDは、パケット信号を発信した基地局装置10あるいは端末装置14を、一意に特定できる装置毎にユニークな識別情報である。ペイロードは、前述のデータを格納するフィールドであり、交差点情報や道路情報等の端末装置へ通知すべき情報に相当する。また、メッセージタイプのデータ形式が署名付きデータ(=1)の時、ペイロードヘッダおよびペイロードに対する電子署名、すなわちMAC値を格納するフィールドである。また、メッセージタイプのデータ形式が暗号化データ(=2)の時、無効としても良いが、ここでは固定値、ペイロードヘッダの部分の写しなどの受信側特定可能な値、あるいは、ペイロードヘッダまたは/および暗号化前のペイロードに対するハッシュ値(ハッシュ関数による演算結果)、チェックサム、パリティなどの受信側で演算可能な値、あるいは、署名付きデータ(=1)の時と同様に電子署名を格納するものとする。そして、ペイロードおよび署名をまとめて暗号化する。このようにすることで、復号によって得られた署名に格納された値と、受信側で特定した、あるいは、演算した値とが一致すれば、復号が正常に行われ、ペイロードに格納されているデータ、あるいはペイロードヘッダとペイロードに格納されているデータの正当性が確認できる。各フィード長さは、例えば、ペイロードヘッダが32バイト、ペイロードが100バイト(端末装置が報知する場合)あるいは1Kバイト(基地局装置が報知する場合)、署名が16バイトである。通信システム100では、暗号方式としてAES暗号を使用する。そして、メッセージタイプのデータ形式が署名付きデータの場合には、電子署名は、CBC−MACによって求めたMAC値を署名に格納する。メッセージタイプのデータ形式が暗号化データの場合には、ペイロードヘッダに対するMAC値を署名に格納し、ペイロードおよび署名を、CBCモードで暗号化する。なお、署名にMAC値を格納する場合は、他の暗号化モード、例えばカウンタモードで暗号化を行うようにしてもよい。図2に戻る。
検証部40は、受信処理として、MACフレーム処理部26からのセキュアフレームを解釈し、データを処理部28に出力する。また、検証部40は、送信処理として、処理部28からのデータを受け取り、セキュアフレームを生成し、MACフレーム処理部26に出力する。通信システム100では、共通鍵暗号方式を使用しているため、暗号部42は、共通鍵方式による電子署名の作成・検証およびデータの暗号・復号処理を行う。具体的には、メッセージデータタイプが署名付きデータの場合、セキュアフレーム作成時に電子署名の作成を、セキュアフレーム解釈時には、電子署名の検証処理を、メッセージデータタイプが暗号化データの場合、セキュアフレーム作成時に暗号処理を、セキュアフレーム解釈時には、データの復号処理を行う。
記憶部44は、通信システム100に使用可能な共通鍵が複数の共通鍵テーブルを記憶する。図5は、記憶部44に記憶される共通鍵テーブルのデータ構造を示す。共通鍵テーブルには、複数のバージョンが存在してもよく、それらは、テーブルIDとして管理される。図5において、第1テーブルは、テーブルIDが「1」である場合に相当し、第2テーブルは、テーブルIDが「2」、第Mテーブルは、テーブルIDが「M」である。各共通鍵テーブルには、複数の共通鍵が含まれており、各共通鍵は共通鍵IDで管理されている。図5において、第1共通鍵は、共通鍵IDが「1」である場合に相当し、第2共通鍵は、共通鍵IDが「2」である場合に相当する。そのため、ひとつの共通鍵は、テーブルIDと共通鍵IDとの組合せによって特定される。また、各共通鍵テーブルに、運用開始日時を設置するNotBeforeが設けられている。第1テーブルの運用開始日時が「2009.1.1」であり、第2テーブルは、テーブルIDが「2009.3.1」、第Mテーブルは、テーブルIDが「2010.6.1」である。今が、2010.5.1であるとすると、第Mテーブルは使用することができない。尚、テーブルIDは、連続している必要はない。なお、共通鍵テーブルに、NotAfter(運用終了日時あるいは有効期限)が含まれていてもよい。図2に戻る。
検証部40は、セキュアフレームを生成する際、記憶部44を参照して、共通鍵を抽出する。例えば、各共通鍵テーブルには、NotBeforeとして運用開始日時が規定されており、MACフレーム処理部26は、現在の時刻をもとに、ひとつの共通鍵テーブルを選択する。検証部40は、運用中の共通鍵テーブルの中から、NotBeforeに記載される運用開始日時が最も遅い最新の共通鍵テーブルを選択する。さらに、検証部40は、選択した共通鍵テーブルの中から、ひとつの共通鍵を選択する。この選択は、ランダムになされてもよいし、基地局装置10に付与された識別番号にしたがってなされてもよい。検証部40は、メッセージタイプのデータ形式が署名付きデータの場合には、選択した共通鍵を使用して暗号部42にてペイロードヘッダとペイロードに対する電子署名を演算する。また、メッセージタイプのデータ形式が暗号化データの場合には、暗号部42にてペイロードと署名を暗号化する。検証部40は、メッセージタイプのデータ形式が平文データの場合には、生成したセキュアフレームを、そのままMACフレーム処理部26へ出力する。なお、MACフレーム処理部26から受け取ったデータを用いてセキュアフレームを生成する場合、メッセージタイプのデータ種別は、アプリケーションデータ(=0)とする。
検証部40は、セキュアフレームを解釈する際、MACフレーム処理部26から受け取ったセキュアフレームの鍵IDを参照し、使用する共通鍵のテーブルIDと共通鍵IDを得る。次いで、記憶部44を参照して、このテーブルIDと共通鍵IDにて特定される共通鍵を抽出する。さらに、検証部40は、抽出した共通鍵を使用して、MACフレーム処理部26から受け取ったセキュアフレームのメッセージタイプのデータ形式が署名付きデータの場合には、署名の正当性を検証する。詳細には、暗号部42にてペイロードヘッダとペイロードに対する電子署名を演算し、求めた値と、MACフレーム処理部26から受け取ったセキュアフレームの署名に格納された電子署名の値と比較する。2つの電子署名の値が一致すれば、電子署名が正当であり、このセキュアフレームに含まれる情報が正規の基地局装置10、あるいは、端末装置14からの情報であると判断し、MACフレーム処理部26に出力する。2つの電子署名の値が不一致ならば電子署名が正当でないと判断し、データは破棄される。また、メッセージタイプのデータ形式が暗号化データの場合には、暗号部42にてペイロードと署名の復号処理を実行する。そして、署名が予め定めた値であれば、セキュアフレームから取り出したデータが正常復号されたと判断し、セキュアフレームから取り出したデータをMACフレーム処理部26に出力する。なお、予め定めた値でない場合、データは破棄される。なお、暗号化対象を署名としているのは、前述のごとく署名には既知の値を格納して暗号化の対象とすることで、復号時に復号が正常の行われたか否かをチェックする機能を持たせたためである。このようなチェック機能を持たせない場合には、署名を暗号化の対象とする必要はない。メッセージタイプのデータ形式が平文データの場合には、受け取ったセキュアフレームから取り出したデータを、無条件でMACフレーム処理部26に出力する。なお、ここでは2つの電子署名、すなわちセキュアフレームの署名に格納された電子署名と、演算したペイロードヘッダとペイロードに対する電子署名とを比較によって検証を行うとしたが、これに限定されるものではない。電子署名の検証は採用した電子署名方式の検証アルゴリズムに従い行われる。
さらに、検証部40は、記憶部44に記憶された共通鍵テーブルを含んだセキュアフレームを生成する。この時、メッセージタイプのデータ種別はメンテナンスデータ(=1)とする。記憶部44に記憶された共通鍵テーブルは、運用開始日時前から報知の対象になり運用開始後も報知される。検証部40は、報知の対象のテーブルIDが付与された共通鍵テーブルを選択し、選択した共通鍵テーブルが格納されたセキュアフレームを生成する。その際、メッセージタイプのデータ形式を暗号化データとする。生成したセキュアフレームを、そのままMACフレーム処理部26へ出力する。
検出部46は、検証部40において正当であると判定された電子署名あるいは暗号化に使用された共通鍵テーブルのテーブルIDを受けつける。これは、受信したパケット信号で使用されていた共通鍵が含まれた共通鍵テーブルのバージョンを確認することに相当する。また、検出部46は、当該パケット信号の送信元になる端末装置の識別番号を取得してもよい。
検出部46は、受け付けたテーブルIDと、記憶部44に記憶された最新の共通鍵テーブルのテーブルIDとを比較する。検出部46は、前者のテーブルIDが、後者のテーブルIDと一致しないことを検出した場合、テーブルIDごとに検出数を計数する。検出部46は、いずれかの検出数が単位期間において所定回数以上であれば、最新の共通鍵テーブルの報知を決定する。ここで、検出数として、端末装置の識別番号の数も計数されてもよい。同一の端末装置から複数のパケット信号を受信することを加味して、単位時間あたりの検出回数を補正するためである。また、所定時間内の検出割合を加味して判断するようにしても良い。
報知が決定すると、検証部40は報知の対象となる共通鍵テーブル、すなわち、運用中の最新の共通鍵テーブルを、報知を決定した計数の対象となったテーブルIDで特定される共通鍵テーブルの共通鍵で暗号化したセキュアフレームを生成して、パケット信号として報知する。
なお、共通鍵テーブルの報知に、記憶部44に記録されている運用中の共通鍵テーブルの共通鍵を使用するとしたが、共通鍵テーブル報知用に用意された別の共通鍵あるいは共通鍵テーブルを使用してもよい。これは、テーブルマスタ鍵を使用することに相当する。また、端末装置14から送信された共通鍵あるいは公開鍵によって暗号化しても良い。この場合、共通鍵テーブルを受信できる端末装置14は、暗号化に用いた鍵を送信した端末装置14に限られる。さらに、共通鍵テーブルを送信すべき端末装置を限定してもよい。例えば、端末装置が使用している共通鍵テーブルの鍵、あるいはテーブルマスタ鍵に加えて、端末装置を識別するための端末IDによって、共通鍵テーブルが暗号化される。また、別の例では、端末装置が使用している共通鍵テーブルの鍵、あるいはテーブルマスタ鍵に加えて、端末装置を識別するための端末IDによって送信鍵が暗号化されるとともに、送信鍵によって共通鍵テーブルが暗号化される。その結果、送信鍵と、送信鍵によって暗号化された共通鍵テーブルが報知される。これによって、個別に共通鍵テーブルを送信する場合であっても、通信コストや処理負担を軽減できる。
センサ通信部34は、図示しない内部ネットワークに接続される。この内部ネットワークには、図示しない交差点の各所に設置されたカメラやレーザセンサなどの交差点の情報収集する機器が接続されている。センサ通信部34に接続された交差点の情報収集する機器の総称をセンサと言う。センサ通信部34は、ネットワークを介して、交差点の各所に設置されたセンサの情報を受け取り、処理部28へ出力する。ネットワーク通信部32は、図示しないネットワークに接続される。
処理部28は、検証部40から受け取ったデータに対する処理を実行する。処理結果は、ネットワーク通信部32を介して、直接、図示しないネットワークへ出力されてもよし、内部に蓄積して、定期的に図示しないネットワークへ出力されてもよい。また、処理部28は、ネットワーク通信部32を介して、図示しないネットワークから受け取った道路情報(工事、渋滞など)や、センサ通信部34を介して、図示しないセンサからの交差点の情報に基づいて、端末装置14に送信するデータを生成する。また、処理部28は、ネットワーク通信部32を介して、新たな共通鍵テーブルを受け取ると、検証部40の記憶部44に書き込み、検証部40に報知に期間を通知する。制御部30は、基地局装置10全体の処理を制御する。
この構成は、ハードウエア的には、任意のコンピュータのCPU、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
図6は、車両12に搭載された端末装置14の構成を示す。端末装置14は、アンテナ50、RF部52、変復調部54、MACフレーム処理部56、受信処理部58、データ生成部60、検証部62、通知部70、制御部72を含む。検証部62は、暗号部64と記憶部66を含む。アンテナ50、RF部52、変復調部54、MACフレーム処理部56、検証部62、記憶部66、暗号部64は、図2のアンテナ20、RF部22、変復調部24、MACフレーム処理部26、暗号部42、記憶部44と同様の処理を実行する。そのため、ここでは、同様の処理の説明を割愛し、差異を中心に説明する。
検証部62は、検証部40と同様に、セキュアフレームの生成および解釈を行う。また、受け取ったセキュアフレームのペイローロードが、セキュリティ情報の場合、すなわち、共通鍵テーブルが含まれる時、その共通鍵テーブルが記憶部66に未記録の場合には、記憶部66に受け取った共通鍵テーブルを記憶させる。記憶部66に空きがある場合、受け取った共通鍵テーブルをそのまま追記する。記憶部66に空きがない場合、記憶部66に記憶されている共通鍵テーブルの内、運用開始日時が最も古いものを書き換える。なお。検証部62は、記憶部66に記憶されている共通鍵テーブルを送信することはない。
受信処理部58は、検証部62から受け取ったデータと、データ生成部60から受け取った自車両情報に基づいて、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また、データが、画像情報であれば通知部70にて表示できるように処理をする。
通知部70は、図示しないモニタやランプやスピーカ等のユーザへの通知手段を含む。受信処理部58から指示しにしたがって、図示しない他の車両12の接近等を運転者へモニタやランプやスピーカを介して通知する。また、渋滞情報や交差点等の画像情等をモニタに表示する。
データ生成部60は、図示しないGPS受信機、ジャイロスコープ、車速センサ等を含んでおり、それらから供給される情報によって、図示しない自車両の情報、つまり端末装置14が搭載された車両12の存在位置、進行方向、移動速度等を取得する。なお、存在位置は、緯度・経度によって示される。これらの取得には公知の技術が使用されればよいので、ここでは説明を省略する。データ生成部60は、取得した情報を元にデータを生成し、生成したデータを検証部62に出力する。また、取得した情報を受信処理部58に自車両情報として出力する。制御部72は、端末装置14全体の動作を制御する。
以上の構成による通信システム100のパケット信号の送受信に関わる動作を説明する。図7は、基地局装置10におけるパケット信号の送信手順を示すフローチャートである。共通鍵テーブルを送信しない場合(S10のN)、検証部40は、処理部28よりデータと、データを送信するメッセージタイプのデータ形式を受け取る。そして、受け取ったデータをペイロードに格納したセキュアフレームを生成する(S12)。この時、鍵IDおよび署名は、空であり、例えば、全てに0を格納する。次いで、メッセージタイプのデータ形式が平文データの場合(S14のY)、MACフレーム処理部56、変復調部54、RF部52、アンテナ50を介して、そのままセキュアフレームを、パケット信号として報知する(S22)。メッセージタイプのデータ形式が署名付きデータまたは暗号データの場合(S14のN)、共通鍵を選択する(S16)。共通鍵は最新の共通鍵テーブルよりランダムに選択される。共通鍵を選択するとセキュアフレームの鍵IDには、最新の共通鍵テーブルのテーブルIDと選択された共通鍵IDが格納される。再び、メッセージタイプのデータ形式を参照して、データ形式が署名付きデータの場合(S18のY)、検証部40は、暗号部42にて、選択した共通鍵を用いてペイロードヘッダおよびペイロードに対する電子署名を演算し、その値をセキュアフレームの署名に格納する(S20)。次いで、MACフレーム処理部56、変復調部54、RF部52、アンテナ50を介して、署名を付けたセキュアフレームを、パケット信号として報知する(S22)。メッセージタイプのデータ形式が暗号化データの場合(S18のN)、検証部40は、暗号部42にて、ペイロートのMAC値を求め、セキュアフレームの署名に格納する(S24)。次いで、選択した共通鍵を用いてペイロードヘッダおよび署名を暗号化する(S26)。そして、MACフレーム処理部56、変復調部54、RF部52、アンテナ50を介して、暗号化したセキュアフレームを、パケット信号として報知する(S22)。
一方、共通鍵テーブルを送信する場合(S10のY)、検証部40は、記憶部44より送信する共通鍵テーブルを読み出し、検出部読み出した共通鍵テーブルをペイロードに格納したセキュアフレームを生成する(S28)。そして、送信する共通鍵テーブルに対応した共通鍵テーブルから、ランダムに共通鍵を1つ選択する(S30)。共通鍵を選択するとセキュアフレームの鍵IDには、対象の共通鍵テーブルのテーブルIDと選択された共通鍵IDが格納される。以降、ステップS24、ステップS26を経て、暗号化した共通鍵テーブルを含むセキュアフレームを、パケット信号として報知する(S22)。
図8は、基地局装置10におけるパケット信号の受信手順を示すフローチャートである。RF部22、変復調部24は、パケット信号を受信する(S40)。データ形式が平文でない場合(S42のN)、つまりデータ形式が署名付きあるいは暗号化である場合、検証部40は、テーブルID、共通鍵IDを確認する(S44)。検証部40は、テーブルIDを蓄積し(S46)、記憶部44から共通鍵を取得する(S48)。データ形式が署名付きである場合(S50のY)、署名データが正当であれば(S52のY)、検証部40は、テーブルIDを計数し(S58)、データを取り出す(S60)。署名データが正当でなければ(S52のN)、検証部40は、データを破棄する(S62)。データ形式が署名付きでない場合(S50のN)、つまりデータ形式が暗号化である場合、検証部40は、取得した暗号鍵にて復号する(S54)。データが正当である場合(S56のY)、検証部40は、テーブルIDを計数し(S58)、データを取り出す(S60)。データが正当でない場合(S56のN)、検証部40は、データを破棄する(S62)。データ形式が平文である場合(S42のY)、検証部40は、データを取り出す(S60)。
図9は、基地局装置10の検出部46における共通鍵テーブルの報知決定手順を示すフローチャートである。テーブルIDが最新でなければ(S70のN)、検出部46は、該当テーブルIDを計数する(S72)。単位時間の回数がL以上であれば(S74のY)、検出部46は、共通鍵テーブルの送信を決定する(S76)。テーブルIDが最新である場合(S70のY)、あるいは単位時間の回数がL以上でない場合(S74のN)、処理は終了される。
図10は、端末装置14におけるパケット信号の受信手順を示すフローチャートである。RF部52、変復調部54は、パケット信号を受信する(S90)。データ形式が平文でない場合(S92のN)、つまりデータ形式が署名付きあるいは暗号化である場合、検証部62は、テーブルID、共通鍵IDを確認する(S94)。鍵テーブルがあれば(S96のY)、検証部62は、テーブルIDを蓄積し(S98)、記憶部66から共通鍵を取得する(S100)。データ形式が署名付きである場合(S102のY)、署名データが正当であれば(S104のY)、検証部62は、データを抽出する(S114)。署名データが正当でなければ(S104のN)、検証部62は、データを破棄する(S116)。
データ形式が署名付きでない場合(S102のN)、つまりデータ形式が暗号化である場合、検証部62は、取得した暗号鍵にて復号する(S106)。データが正当である場合(S108のY)、データ種別がメンテナンスデータであり(S110のY)、鍵テーブルがなければ(S112のN)、検証部62は、記憶部66に格納する(S118)。データが正当でない場合(S104のN)、あるいはデータが正当でない場合(S108のN)、あるいは鍵テーブルがある場合(S112のY)、検証部62は、データを破棄する(S116)。データ種別がメンテナンスデータでない場合(S110のN)、検証部62は、データを抽出する(S114)。
図11は、端末装置14におけるパケット信号の送信手順を示すフローチャートである。検証部62は、処理部よりデータを取得し、セキュアフレームを生成する(S130)。メッセージタイプが平文でない場合(S132のN)、つまりメッセージタイプが署名付きあるいは暗号化である場合、検証部62は、共通鍵を選択する(S134)。メッセージタイプが署名付きである場合(S136のY)、検証部62は、選択した共通鍵にて電子署名を演算し、署名データに格納する(S138)。変復調部54、RF部52は、パケット信号を報知する(S144)。メッセージタイプが署名付きでない場合(S136のN)、つまりメッセージタイプが暗号化である場合、検証部62は、ペイロードヘッダのMAC値を演算し、署名データに格納する(S140)とともに、選択した暗号鍵にて暗号化を実行する(S142)。変復調部54、RF部52は、パケット信号を報知する(S144)。メッセージタイプが平文である場合(S132のY)、変復調部54、RF部52は、パケット信号を報知する(S144)。
本発明の実施例によれば、端末装置にて使用されている共通鍵テーブルが旧バージョンであることを検出し、かつ検出数が所定回数以上である場合に、新たな共通鍵テーブルを送信するので、送信回数を制限できる。また、送信回数が制限されるので、トラヒックの増加を抑制できる。また、トラヒックの増加が抑制されるので、ブロードキャスト通信において共通鍵を効率的に配布できる。また、旧バージョンの共通鍵を使用している端末装置数が増加すれば、最新バージョンの共通鍵テーブルを報知するので、共通鍵テーブルを更新できる。また、最新バージョンの共通鍵が使用されるので、安全性を向上できる。
また、電子署名を生成するために共通鍵を使用するので、公開鍵を使用する場合と比較して処理量を低減できる。また、処理量が低減されるので、処理可能なパケット信号数を増加できる。また、電子署名を生成するために共通鍵を使用するので、公開鍵を使用する場合と比較して伝送効率を向上できる。また、位置情報等のデータに対しては暗号化を実行しないので、処理量を低減する。一方、共通鍵テーブルには暗号化を実行するので、安全性を向上できる。
本発明の変形例は、車両に搭載された端末装置間において車車間通信を実行するとともに、交差点等に設置された基地局装置から端末装置へ路車間通信も実行する通信システムに関する。車車間通信として、端末装置は、車両の速度や位置等の自車両情報を格納したパケット信号をブロードキャストにより送信する(以下、パケット信号をブロードキャストによる送信を「報知」という)。また、他の端末装置は、パケット信号を受信するとともに、データをもとに車両の接近等を認識する。また、路車間通信として、基地局装置は、交差点情報、渋滞情報、および、セキュリティ情報等が格納されたパケット信号を報知する。以下、説明を簡単にするために、車車間通信および路車間通信のパケット信号に含まれる情報の総称を「データ」という。
交差点情報には、交差点の位置、基地局装置が設置された交差点の撮影画像や、交差点内の車両の位置情報等の交差点の状況に関する情報が含まれる。端末装置は、この交差点情報をモニタに表示、この交差点情報をもとに交差点車両の状況を認識して、出会い頭・右折・左折による衝突防止を目的とした他の車両や歩行者の存在等をユーザにする伝達し、事故の防止を図る。また、渋滞情報には、基地局装置が設置された交差点近辺の走路の混雑状況、道路工事や事故に関する情報が含まれる。この情報をもとに進行方向の渋滞をユーザに伝達、あるいは、迂回路を提示する。セキュリティ情報では、共通鍵テーブルの提供等のデータを保護に関する情報が含まれる。詳細については、後述する。
図12は、本発明の変形例に係る通信システム1100の構成を示す。これは、ひとつの交差点を上方から見た場合に相当する。通信システム1100は、基地局装置1010、車両1012と総称される第1車両1012a、第2車両1012b、第3車両1012c、第4車両1012d、第5車両1012e、第6車両1012f、第7車両1012g、第8車両1012h、ネットワーク1202を含む。通信システム1100、基地局装置1010、車両1012、ネットワーク1202は、図1の通信システム100、基地局装置10、車両12、ネットワーク202に対応する。ここでは、差異を中心に説明する。通信システム1100では、通信においてなりすまし等を抑制するために、電子署名が使用される。
通信システム1100で使用される共通鍵が1種類だけであれば、悪意あるユーザであっても、共通鍵の入手が容易になる。これに対応し、鍵の漏えいリスクを低減するために複数の共通鍵を使用するため、通信システム1100では、予め定めた数の共通鍵を1つの共通鍵テーブルにまとめる。また、共通鍵テーブルを複数備えて、必要に応じて切り換えて使用する。ひとつの共通鍵は、共通鍵テーブルを識別するテーブルIDと、テーブル内の共通鍵を識別する共通鍵IDによって特定される。共通鍵テーブルには、運用開始日時(NotBefore)が規定されている。したがって、新たに運用を開始する共通鍵テーブルは、運用開始日時より前に、基地局装置1010から路車間通信により報知したり、事前に端末装置に記録しておくことで端末装置間、あるいは、基地局装置1010と端末装置間で共有が図られる。なお、共通鍵テーブルは、セキュリティ情報に含まれる。
通信システム1100では、データの正当性が要求されるデータ、すなわち車車間通信における自車両情報、路車間通信における交差点情報や渋滞情報などのデータは、データ自体の暗号化を行わず、共通鍵を使用して電子署名を生成し、データに電子署名を添付させたパケット信号を報知する。パケット信号には、電子署名の生成のために使用されたテーブルIDと共通鍵IDとが含まれる。このように規定されることによって、なりすましが防止される。また、情報の秘匿性を要求されるデータ、すなわち路車間通信におけるセキュリティ情報などのデータは、データ自身を暗号化したパケット信号を報知する。パケット信号には、暗号化のために使用されたテーブルIDと共通鍵IDとが含まれる。このようにすることで、データの信頼性・安全性を補償するとともに、処理量の増加および伝送負荷の悪化が抑制される。
図13は、基地局装置1010の構成を示す。基地局装置1010は、アンテナ1020、RF部1022、変復調部1024、MACフレーム処理部1026、検証部1042、処理部1028、制御部1030、ネットワーク通信部1032、センサ通信部1034を含む。検証部1042は、暗号部1044と記憶部1046を含む。アンテナ1020、RF部1022、変復調部1024、MACフレーム処理部1026、検証部1042、処理部1028、制御部1030、ネットワーク通信部1032、センサ通信部1034は、図2のアンテナ20、RF部22、変復調部24、MACフレーム処理部26、検証部40、処理部28、制御部30、ネットワーク通信部32、センサ通信部34に対応する。ここでは、差異を中心に説明する。
図14は、通信システム1100において規定されるパケット信号に格納されるMACフレームのフォーマットを示す。これは、図3と同様であるので、説明を省略する。図15は、通信システム1100において規定されるセキュアフレームのフォーマットを示す。これは、図4と同様であるので、説明を省略する。図16は、記憶部1046に記憶される共通鍵テーブルのデータ構造を示す。ここで、NetBeforeがなくてもよい。これは、図5と同様であるので、説明を省略する。
記憶部1046は、さらに受信したパケット信号に使用されていた共通鍵テーブルのテーブルIDを記録する。記録するテーブルIDは、単位時間毎に受信したパケット信号で使用されていたテーブルIDの最も頻度の高いものを特定するために使用する。したがって、時間経過あるいは記憶部1046の記憶可能な鍵テーブルの数の制限によって自動的に破棄される構成でよい。
検証部1042は、セキュアフレームを生成する際、記憶部1046を参照して、共通鍵を抽出する。各共通鍵テーブルには、NotBeforeが規定されており、検証部1042は、現在の日時をもとに、すでに運用が開始されている共通鍵テーブルのひとつを選択する。複数の共通鍵テーブルの運用が開始されている場合、検証部1042は、NotBeforeが最も大きな値の共通鍵テーブル、すなわち最も運用開始日時が新しい共通鍵テーブルを選択する。検証部1042は、所定期間において所定回数以上、共通鍵テーブルのテーブルIDが運用開始日時の古い共通鍵テーブルに対応する場合、電子署名を生成するために、最も運用開始日時が新しい共通鍵テーブルの代わりに運用開始日時の古い共通鍵テーブルを使用する。なお、NetBeforeがない場合には、最も新しく格納された共通鍵テーブルを使用するものとすればよい。
さらに、検証部1042は、記憶部1046に記憶された共通鍵テーブルを含んだセキュアフレームを生成する。記憶部1046に記憶された共通鍵テーブルは、運用開始日時前から報知の対象になり運用開始後も報知される。そして、さらに未来に運用を開始するように運用開始日時が設定され共通鍵テーブルの報知が開始されると報知の対象から除外される。検証部1042は、記憶部1046に記憶された共通鍵テーブルのそれぞれに対して、報知の対象になっているかを管理する。検証部1042は、報知の対象のテーブルIDが付与された共通鍵テーブルを選択し、選択した共通鍵テーブルが格納されたセキュアフレームを生成する。その際、メッセージタイプを暗号化データとする。暗号化に用いる共通鍵テーブルは、記憶部1046に記憶された共通鍵テーブルのうち、報知対象の共通鍵テーブルの鍵の運用開始日時以前に、運用が開始されている共通鍵テーブルから選択するものとする。報知のタイミングは任意でよい。ただし、運用開始後の報知のタイミングは、周辺の端末装置1014からのパケット信号を受信して、当該共通鍵テーブルが使用されていない時に報知するようにしてもよい。
なお、共通鍵テーブルの報知用に別の共通鍵が規定されていてもよい。また、端末装置1014から送信された共通鍵あるいは公開鍵によって暗号化してもよい。この場合、共通鍵テーブルを受信できる端末装置1014は、暗号化に用いた鍵を送信した端末装置1014に限られる。
図17は、車両1012に搭載された端末装置1014の構成を示す。端末装置1014は、アンテナ1050、RF部1052、変復調部1054、MACフレーム処理部1056、受信処理部1058、データ生成部1060、検証部1062、通知部1070、制御部1072を含む。検証部1062は、暗号部1064と記憶部1066を含む。アンテナ1050、RF部1052、変復調部1054、MACフレーム処理部1056、検証部1062、記憶部1066、暗号部1064は、図13のアンテナ1020、RF部1022、変復調部1024、MACフレーム処理部1026、検証部1042、暗号部1044、記憶部1046と同様の処理を実行する。受信処理部1058、データ生成部1060、通知部1070、制御部1072は、図6の受信処理部58、データ生成部60、通知部70、制御部72と同様である。そのため、ここでは、同様の処理の説明を割愛し、差異を中心に説明する。
通知部1070は、受信したパケット信号に添付された電子署名を生成している共通鍵が、記憶部1066に未記録の共通鍵テーブルに含まれていることを検証部1062によって検出された場合、その旨を運転者に通知する。
以上の構成による通信システム1100のキャリア信号の送受信に関わる動作を説明する。図18は、基地局装置1010におけるパケット信号の送信手順を示すフローチャートである。共通鍵テーブルを送信しない場合(S1010のN)、検証部1042は、処理部1028よりデータと、データを送信するメッセージタイプを受け取る。そして、受け取ったデータをペイロードに格納したセキュアフレームを生成する(S1012)。この時、鍵IDおよび署名は、空であり、例えば、すべてに0を格納する。次いで、メッセージタイプが平文データの場合(S1014の平文)、MACフレーム処理部1026、変復調部1024、RF部1022、アンテナ1020を介して、そのままセキュアフレームを、パケット信号として報知する(S1020)。メッセージタイプが署名付きデータの場合(S1014の署名付き)、共通鍵を選択する(S1016)。共通鍵を選択するとセキュアフレームの鍵IDには、選択された共通鍵のテーブルIDと共通鍵IDが格納される。
図19は、基地局装置1010における共通鍵の選択手順を示すフローチャートである。検証部1042は、メッセージタイプが、著名付きデータあるいは暗号化データの場合、記憶部1046に記録され、運用開始が開始されている共通鍵テーブルの1つを選択し、さらに、選択した共通鍵テーブルから、1つの鍵を選択する。記憶部1046に記録されている端末装置1014から受信したパケット信号で使用されていた共通鍵が含まれる共通鍵テーブルのテーブルIDが記録されている。検証部1042は、この記録に基づいて単位時間内に最も高い頻度で使用されていた共通鍵テーブルを確認する(S1030)。最も高い頻度で使用されていた共通鍵テーブルが、最新の共通鍵テーブル、すなわち運用が開始されている共通鍵テーブルの中で、運用開始日時が最も遅い共通鍵テーブルの場合(S1030のY)、最新の共通鍵テーブルを選択する(S1032)。最も高い頻度で使用されていた共通鍵テーブルが、最新の共通鍵テーブルでない場合(S1030のN)、その共通鍵テーブルの使用頻度が、予め定めた所定の割合を越えて使用されているかを確認する(S1034)。所定の割合を超えていない場合(S1034のN)、最新の共通鍵テーブルを選択する(S1032)。所定の割合を超えている場合(S1034のY)、最も使用頻度の高い共通鍵テーブルを選択する(S1036)。そして、運用開始を開始している中で最新の共通鍵テーブルの報知要求を出す(S1038)。これは、周辺の端末装置1014の多くが、未だ運用か開始されている最新の共通鍵テーブルを持っていないと推定されるため、これを周辺の端末装置1014に報知することを目的とする。使用する共通鍵テーブルが、選択されると、検証部1042は、選択された鍵テーブルから、ランダムに1つの共通鍵を選択する(S1040)。そして、選択した共通鍵テーブルのテーブルIDと、選択した共通鍵の共通鍵IDを、セキュアフレームの鍵IDに格納し(S1042)、記憶部1046より選択した鍵を読み出す(S1044)。
図18に戻る。検証部1042は、暗号部1044にて、選択した共通鍵を用いてペイロードヘッダおよびペイロードに対する電子署名を演算し、その値をセキュアフレームの署名に格納する(S1018)。次いで、MACフレーム処理部1026、変復調部1024、RF部1022、アンテナ1020を介して、署名を付けたセキュアフレームを、パケット信号として報知する(S1020)。メッセージタイプが暗号化データの場合(S1014の暗号化)、共通鍵を選択する(S1024)。共通鍵の選択は、S1016と同じため説明を割愛する。共通鍵が選択されると、検証部1042は、暗号部1044にて、ペイロートのMAC値を求め、セキュアフレームの署名に格納する(S1026)。次いで、選択した共通鍵を用いてペイロードヘッダおよび署名を暗号化する(S1028)。そして、MACフレーム処理部1026、変復調部1024、RF部1022、アンテナ1020を介して、暗号化したセキュアフレームを、パケット信号として報知する(S1020)。一方、共通鍵テーブルを送信する場合(S1010のY)、検証部1042は、記憶部1046より送信する共通鍵テーブルを読み出し、読み出した共通鍵テーブルをペイロードに格納したセキュアフレームを生成する(S1022)。以降の処理は、メッセージタイプが暗号化データの場合と同じく、ステップS1024、ステップS1026、ステップS1028を経て、暗号化した共通鍵テーブルを含むセキュアフレームを、パケット信号として報知する(S1020)。
図20は、基地局装置1010におけるパケット信号の受信手順を示すフローチャートである。アンテナ1020、RF部1022、変復調部1024は、パケット信号を受信する(S1060)。メッセージタイプが署名付きあるいは暗号化であれば(S1062のN)、検証部1042は、テーブルIDおよび共通鍵IDを確認する(S1064)。記憶部1046は、テーブルIDを蓄積する(S1066)。検証部1042は、記憶部1046から共通鍵を取得する(S1068)。メッセージタイプが署名付きであり(S1070のY)、署名データが正当であれば(S1072のY)、検証部1042は、データを取り出す(S1078)。一方、メッセージタイプが暗号化である場合(S1070のN)、検証部1042は、取得した暗号鍵にて復号する(S1074)。データが正当であれば(S1076のY)、検証部1042は、データを取り出す(S1078)。メッセージタイプが平文である場合(S1062のY)、検証部1042は、データを取り出す(S1078)。署名データが正当でない場合(S1072のN)、あるいはデータが正当でない場合(S1076のN)、検証部1042は、データを破棄する(S1080)。
図21は、端末装置1014におけるパケット信号の受信手順を示すフローチャートである。アンテナ1050、RF部1052、変復調部1054は、パケット信号を受信する(S1100)。メッセージタイプが署名付きあるいは暗号化であれば(S1102のN)、検証部1062は、テーブルIDおよび共通鍵IDを確認する(S1104)。記憶部1066が鍵テーブルを有していれば(S1106のY)、記憶部1066は、テーブルIDを蓄積する(S1108)。検証部1062は、記憶部1066から共通鍵を取得する(S1110)。メッセージタイプが署名付きであり(S1112のY)、署名データが正当であれば(S1114のY)、検証部1062は、データを抽出する(S1122)。
一方、メッセージタイプが暗号化である場合(S1112のN)、検証部1062は、取得した暗号鍵にて復号する(S1116)。データが正当であり(S1118のY)、共通鍵テーブルがなければ(S1120のN)、検証部1062は、データを抽出する(S1122)。メッセージタイプが平文である場合(S1102のY)、検証部1062は、データを取り出す(S1122)。記憶部1066が鍵テーブルを有していない場合(S1106のN)、あるいは署名データが正当でない場合(S1114のN)、あるいはデータが正当でない場合(S1118のN)、検証部1062は、データを破棄する(S1124)。共通鍵テーブルがある場合(S1120のY)、検証部1062は、記憶部1066に格納させる(S1126)。
図22は、端末装置1014におけるパケット信号の送信手順を示すフローチャートである。検証部1062は、データを取得し、セキュアフレームを生成する(S1140)。メッセージタイプが署名付きである場合(S1142の署名付き)、検証部1062は、共通鍵を選択し(S1144)、選択した共通鍵にて電子署名を演算し、署名データに格納する(S1146)。その後、変復調部1054、RF部1052、アンテナ1050は、パケット信号を報知する(S1154)。メッセージタイプが暗号化である場合(S1142の暗号化)、検証部1062は、共通鍵を選択し(S1148)、ペイロードヘッダのMAC値を演算し、署名データに格納する(S1150)。検証部1062は、選択した暗号鍵にて暗号化を実行し(S1152)、変復調部1054、RF部1052、アンテナ1050は、パケット信号を報知する(S1154)。メッセージタイプが平文である場合(S1142の平文)、変復調部1054、RF部1052、アンテナ1050は、パケット信号を報知する(S1154)。
図23は、端末装置1014における共通鍵の選択手順を示すフローチャートである。所定時間内に最も使用頻度の高い共通鍵テーブルが最新である場合(S1170のY)、あるいは所定時間内に最も使用頻度の高い共通鍵テーブルが最新でなくても(S1170のN)、最も使用頻度の高い共通鍵テーブルが所定割合以上使われていない場合(S1172のN)、検証部1062は、運用を開始している中で運用開始日時が最新の共通鍵テーブルを選択する(S1174)。最も使用頻度の高い共通鍵テーブルが所定割合以上使われている場合(S1172のY)、検証部1062は、最も使用回数の多い共通鍵テーブルを選択する(S1176)。検証部1062は、当該鍵テーブルからランダムに共通鍵を選択し(S1178)、セキュアフレームにテーブルIDと共通鍵IDを格納する(S1180)。検証部1062は、記憶部1066よりテーブルIDと共通鍵IDにて特定される鍵を取得する(S1182)。
本発明の変形例によれば、新しい運用開始日時の共通鍵テーブルを優先的に使用するので、安全性を確保できる。また、古い運用開始日時の共通鍵テーブルが多く使用されている場合に、新しい運用開始日時の共通鍵テーブルの代わりに古い運用開始日時の共通鍵テーブルを使用するので、多くの端末装置において共通した共通鍵を使用できる。また、運用開始日時が異なった共通鍵テーブルを切りかえるので、ブロードキャスト通信がなされている場合に、安全性を確保しながら、共通した共通鍵を使用できる。
図24は、基地局装置1010における別のパケット信号の送信手順を示すフローチャートである。基地局装置1010から端末装置1014に、共通鍵テーブルを送信する場合の手順が異なっている。共通鍵テーブルは、送信用の鍵を用いて暗号化し、メッセージタイプを署名付きデータとして送信する。共通鍵テーブルを送信しない場合(S1200のN)、検証部1042は、処理部1028よりデータと、データを送信するメッセージタイプを受け取る。そして、受け取ったデータをペイロードに格納したセキュアフレームを生成する(S1202)。次いで、メッセージタイプが平文データの場合(S1204の平文)、MACフレーム処理部1026、変復調部1024、RF部1022、アンテナ1020を介して、そのままセキュアフレームを、パケット信号として報知する(S1218)。メッセージタイプが署名付きデータの場合(S1204の署名付き)、共通鍵を選択する(S1214)。検証部1042は、暗号部1044にて、選択した共通鍵を用いてペイロードヘッダおよびペイロードに対する電子署名を演算し、その値をセキュアフレームの署名に格納する(S1216)。次いで、MACフレーム処理部1026、変復調部1024、RF部1022、アンテナ1020を介して、署名を付けたセキュアフレームを、パケット信号として報知する(S1218)。
メッセージタイプが暗号化データの場合(S1204の暗号化)、共通鍵を選択する(S1210)。検証部1042は、選択した共通鍵を用いてペイロードヘッダおよび署名を暗号化する(S1212)。そして、MACフレーム処理部1026、変復調部1024、RF部1022、アンテナ1020を介して、暗号化したセキュアフレームを、パケット信号として報知する(S1218)。一方、共通鍵テーブルを送信する場合(S1200のY)、検証部1042は、記憶部1046より送信する共通鍵テーブルを読み出し、読み出した共通鍵テーブルを専用鍵で暗号化する(S1206)。検証部1042は、暗号化共通鍵テーブルを含むセキュアフレームを生成する(S1208)。以降の処理は、メッセージタイプが署名付きの場合と同じく、ステップS1214、ステップS1216を経て、パケット信号として報知する(S1218)。
図25は、端末装置1014における別のパケット信号の受信手順を示すフローチャートである。アンテナ1050、RF部1052、変復調部1054は、パケット信号を受信する(S1240)。メッセージタイプが署名付きあるいは暗号化であれば(S1242のN)、検証部1062は、テーブルIDおよび共通鍵IDを確認する(S1244)。記憶部1066が鍵テーブルを有していれば(S1246のY)、検証部1062は、記憶部1066から共通鍵を取得する(S1248)。記憶部1066は、テーブルIDを蓄積する(S1250)。メッセージタイプが暗号化である場合(S1252のN)、検証部1062は、取得した暗号鍵にて復号する(S1254)。データが正当であれば(S1258のY)、検証部1062は、データを取り出す(S1264)。データが正当でなければ(S1258のN)、検証部1062は、データを破棄する(S1266)。メッセージタイプが署名付きであり(S1252のY)、署名データが正当であり(S1256のY)、共通鍵テーブルであれば(S1260のY)、検証部1062は、専用暗号鍵にて復号し(S1262)、記憶部1066に格納する(S1268)。署名データが正当でなければ(S1256のN)、検証部1062は、データを破棄し(S1266)、共通鍵テーブルでなければ(S1260のN)、検証部1062は、データを取り出す(S1264)。メッセージタイプが平文である場合(S1242のY)、検証部1062は、データを取り出す(S1264)。鍵テーブルがなければ(S1246のN)、検証部1062は、データを破棄する(S1266)。
本発明の変形例によれば、電子署名の値を演算するために共通鍵を使用するので、公開鍵を使用する場合と比較して処理量を低減できる。また、処理量が低減されるので、処理可能なパケット信号数を増加できる。また、電子署名の値を演算するために共通鍵を使用するので、公開鍵を使用する場合と比較して伝送効率を向上できる。また、位置情報等のデータに対しては暗号化を実行しないので、処理量を低減する。一方、共通鍵テーブルには暗号化を実行するので、安全性を向上できる。また、ブロードキャスト通信がなされている場合に、安全性を確保しながら、共通した暗号鍵を使用できる。
以上、本発明の実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
本発明の実施例において、検出部46は、共通鍵テーブルのテーブルごとに検出処理を実行、検出数が所定回数、あるいは、検出回数の割合が所定の割合以上になった場合に、運用中の最新の共通鍵テーブルをパケット信号として報知するものとしたが、検出の対象となった共通鍵テーブルの次に新しい共通鍵テーブルを、パケット信号として報知しても良い。
本発明の実施例において、通信システム100は、共通鍵テーブルの運用開始日時や有効期限を設定している。しかしながらこれに限らず例えば、共通鍵テーブルの運用開始日時や有効期限が設定されていなくてもよい。その際、基地局装置10、端末装置14は、最新の共通鍵テーブルを常に使用する。本変形例によれば、共通鍵テーブルのサイズを低減できる。
また、端末装置14は、パケット信号を受信した際に、保持するすべての共通鍵テーブルを使用して復号・検証を実行してもよい。端末装置14は、その結果をアプリケーションに通知する。例えば、検証が成功したこと、古い共通鍵テーブルによって検証が成功したこと、検証が失敗したこと、不定であること等が通知される。
本発明の実施例において、基地局装置10が共通鍵テーブルを送信している。しかしながらこれに限らず例えば、基地局装置10が共通鍵テーブルを送信しなくてもよい。その際、基地局装置10とは別に、共通鍵テーブル配信用の基地局装置が設けられてもよい。
本発明の実施例において、検出部46は、確認部から受けつけたテーブルIDが、記憶部44に記憶された最新の共通鍵テーブルのテーブルIDよりも前であることを検出した場合、検出数を計数している。しかしながらこれに限らず例えば、さらに、検出部46は、共通鍵テーブルのバージョンごとに検出処理を実行してもよい。その場合、処理部26は、所定回数以上になった検出数に対応した共通鍵テーブルのバージョンが、記憶部44に記憶した最新の共通鍵テーブルのバージョンよりも2世代以上前であっても、最新バージョンの共通鍵テーブルが格納されたパケット信号を生成してもよい。本変形例によれば、最新バージョンの共通鍵テーブルのみを送信するので、トラヒック量を低減できる。
本実施例は、次の項目によって特徴付けられてもよい。
(項目1)
通信に使用可能な共通鍵が複数種類示された第1の共通鍵テーブルと、第1の共通鍵テーブルの運用開始日時よりも新しい運用開始日時の第2の共通鍵テーブルとを記憶する記憶部と、
前記記憶部において記憶した第2の共通鍵テーブルに含まれた共通鍵によって電子署名を生成するとともに、電子署名が添付されたパケット信号を生成する処理部と、
前記処理部において生成したパケット信号を報知する通信部とを備え、
前記通信部は、他の通信装置から報知されたパケット信号を受信し、
前記処理部は、前記通信部において受信したパケット信号に添付された電子署名を生成している共通鍵が第1の共通鍵テーブルに含まれているかを調査し、所定期間において所定回数以上、第1の共通鍵テーブルに含まれた共通鍵を検出した場合、電子署名を生成するために、第2の共通鍵テーブルの代わりに第1の共通鍵テーブルを使用することを特徴とする通信装置。
(項目1)
通信に使用可能な共通鍵が複数種類示された第1の共通鍵テーブルと、第1の共通鍵テーブルの運用開始日時よりも新しい運用開始日時の第2の共通鍵テーブルとを記憶する記憶部と、
前記記憶部において記憶した第2の共通鍵テーブルに含まれた共通鍵によって電子署名を生成するとともに、電子署名が添付されたパケット信号を生成する処理部と、
前記処理部において生成したパケット信号を報知する通信部とを備え、
前記通信部は、他の通信装置から報知されたパケット信号を受信し、
前記処理部は、前記通信部において受信したパケット信号に添付された電子署名を生成している共通鍵が第1の共通鍵テーブルに含まれているかを調査し、所定期間において所定回数以上、第1の共通鍵テーブルに含まれた共通鍵を検出した場合、電子署名を生成するために、第2の共通鍵テーブルの代わりに第1の共通鍵テーブルを使用することを特徴とする通信装置。
(項目2)
前記通信部において受信したパケット信号に添付された電子署名を生成している共通鍵が、前記記憶部に未記録の共通鍵テーブルに含まれていることを前記処理部によって検出された場合、その旨をユーザに通知する通知部をさらに備えることを特徴とする項目1に記載の通信装置。
前記通信部において受信したパケット信号に添付された電子署名を生成している共通鍵が、前記記憶部に未記録の共通鍵テーブルに含まれていることを前記処理部によって検出された場合、その旨をユーザに通知する通知部をさらに備えることを特徴とする項目1に記載の通信装置。
10 基地局装置、 12 車両、 14 端末装置、 20 アンテナ、 22 RF部、 24 変復調部、 26 MACフレーム処理部、 28 処理部、 30 制御部、 32 ネットワーク通信部、 34 センサ通信部、 40 検証部、 42 暗号部、 44 記憶部、 46 検出部、 50 アンテナ、 52 RF部、 54 変復調部、 56 MACフレーム処理部、 58 受信処理部、 60 データ生成部、 62 検証部、 64 暗号部、 66 記憶部、 70 通知部、 72 制御部、 100 通信システム、 202 ネットワーク、 212 エリア、 214 エリア外。
本発明によれば、ブロードキャスト通信に適した暗号鍵の使用技術を提供できる。
Claims (5)
- 車載器からの車車間通信および路側機からの路車間通信を実行する車載器であって、
車車間通信において、
セキュアフレームを規定する識別情報であるバージョンと、
平文データ、署名付きデータ、または暗号化データを設定可能なメッセージタイプと、
MAC(Message Authentication Code)生成、またはMAC生成および暗号化に使用される共通鍵を特定する鍵IDと、
発信元として路側機、緊急車両に搭載された車載器、または一般車両に搭載された車載器を設定可能な発信元種別と、
発信元の識別情報である発信元IDと、
当該車載器を搭載した車両の自車両情報を含むアプリケーションデータと、
前記アプリケーションデータを含むMAC対象に対して前記鍵IDで特定される共通鍵を用いて生成されたMACと、
を含む通信データを生成する生成部と、
生成された通信データを、OFDM(Orthogonal Frequency Division Multiplexing)変調方式のパケット信号としてブロードキャストする送信部と、を備え、
前記生成部は、前記メッセージタイプに暗号化データを設定したとき前記アプリケーションデータ及び前記MACを含む暗号化対象を、前記鍵IDで特定される共通鍵を用いて暗号化し、
本車載器は、
他の車載器からブロードキャストされたパケット信号を受信する受信部と、
受信したパケット信号を復調する復調部と、
前記鍵IDで特定される共通鍵を用いて、前記パケット信号に含まれる暗号化データを復号し、前記MACを検証する検証部と、
をさらに備えることを特徴とする車載器。 - 複数の共通鍵を含む共通鍵テーブルを記憶する記憶部を、さらに備え、
前記共通鍵テーブルは、車載器間で事前に共有されており、
前記鍵IDは、前記共通鍵テーブルに含まれる共通鍵を特定することを特徴とする請求項1に記載の車載器。 - 前記共通鍵テーブルは、路側機とも事前に共有されており、
前記受信部は、路側機からブロードキャストされたパケット信号を受信し、
前記検証部は、前記パケット信号に含まれる鍵IDで特定される共通鍵を用いて、前記パケット信号に含まれる暗号化データを復号することを特徴とする請求項2に記載の車載器。 - 前記共通鍵テーブルは複数存在し、
前記共通鍵テーブルを識別するテーブルIDと前記共通鍵テーブル内の個々の共通鍵を識別する共通鍵IDとを含み、
前記生成部は、前記記憶部に記憶されている複数の共通鍵テーブルから一つの鍵テーブルを選択し、選択した共通鍵テーブルの中から、一つの共通鍵を選択して用いることを特徴とする請求項2または3に記載の車載器。 - 前記検証部は、前記記憶部に記憶されているいずれかの共通鍵テーブルから、前記パケット信号に含まれる通信データの鍵IDによって特定される共通鍵を用いることを特徴とする請求項4に記載の車載器。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013116769A JP5341274B1 (ja) | 2010-05-19 | 2013-06-03 | 車載器 |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010115839 | 2010-05-19 | ||
JP2010115839 | 2010-05-19 | ||
JP2010124968 | 2010-05-31 | ||
JP2010124968 | 2010-05-31 | ||
JP2013116769A JP5341274B1 (ja) | 2010-05-19 | 2013-06-03 | 車載器 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012515764A Division JP5301034B2 (ja) | 2010-05-19 | 2011-05-19 | 車載器 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP5341274B1 true JP5341274B1 (ja) | 2013-11-13 |
JP2013232909A JP2013232909A (ja) | 2013-11-14 |
Family
ID=44991471
Family Applications (8)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012515764A Active JP5301034B2 (ja) | 2010-05-19 | 2011-05-19 | 車載器 |
JP2013116768A Active JP5341273B1 (ja) | 2010-05-19 | 2013-06-03 | 車載器 |
JP2013116769A Active JP5341274B1 (ja) | 2010-05-19 | 2013-06-03 | 車載器 |
JP2013116770A Active JP5362928B2 (ja) | 2010-05-19 | 2013-06-03 | 無線装置 |
JP2013175841A Active JP5732626B2 (ja) | 2010-05-19 | 2013-08-27 | 無線装置 |
JP2015019200A Active JP5891384B2 (ja) | 2010-05-19 | 2015-02-03 | 無線装置 |
JP2015216481A Active JP6037153B2 (ja) | 2010-05-19 | 2015-11-04 | 処理装置 |
JP2016204090A Active JP6273658B2 (ja) | 2010-05-19 | 2016-10-18 | 基地局装置 |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012515764A Active JP5301034B2 (ja) | 2010-05-19 | 2011-05-19 | 車載器 |
JP2013116768A Active JP5341273B1 (ja) | 2010-05-19 | 2013-06-03 | 車載器 |
Family Applications After (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013116770A Active JP5362928B2 (ja) | 2010-05-19 | 2013-06-03 | 無線装置 |
JP2013175841A Active JP5732626B2 (ja) | 2010-05-19 | 2013-08-27 | 無線装置 |
JP2015019200A Active JP5891384B2 (ja) | 2010-05-19 | 2015-02-03 | 無線装置 |
JP2015216481A Active JP6037153B2 (ja) | 2010-05-19 | 2015-11-04 | 処理装置 |
JP2016204090A Active JP6273658B2 (ja) | 2010-05-19 | 2016-10-18 | 基地局装置 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20130195272A1 (ja) |
JP (8) | JP5301034B2 (ja) |
CN (1) | CN102484791A (ja) |
WO (1) | WO2011145353A1 (ja) |
Families Citing this family (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5459176B2 (ja) * | 2010-04-07 | 2014-04-02 | 株式会社デンソー | 無線通信装置およびデータ通信装置 |
JP2013156721A (ja) * | 2012-01-27 | 2013-08-15 | Advanced Telecommunication Research Institute International | 端末装置 |
JP5888189B2 (ja) * | 2012-08-30 | 2016-03-16 | トヨタ自動車株式会社 | 車車間通信システム、車車間通信方法および車載端末 |
ES2629195T3 (es) | 2013-01-21 | 2017-08-07 | Dolby Laboratories Licensing Corporation | Codificación y descodificación de una secuencia de bits según un nivel de confianza |
JP6218184B2 (ja) * | 2014-11-13 | 2017-10-25 | 日立オートモティブシステムズ株式会社 | 情報処理装置、メッセージ認証方法 |
JP6183436B2 (ja) * | 2015-10-08 | 2017-08-23 | 住友電気工業株式会社 | 車載機及び共通鍵の更新の契機を得る方法 |
PL3698976T3 (pl) * | 2016-06-17 | 2021-11-22 | Hewlett-Packard Development Company, L.P. | Uwierzytelnianie wymiennego elementu |
JP6678995B2 (ja) * | 2016-08-19 | 2020-04-15 | 住友電工システムソリューション株式会社 | 無線通信機、情報登録方法、及びコンピュータプログラム |
US10319224B2 (en) * | 2016-08-19 | 2019-06-11 | Veniam, Inc. | Adaptive road management in the network of moving things |
CN108810889B (zh) * | 2017-05-05 | 2020-12-04 | 华为技术有限公司 | 通信方法、装置及系统 |
CN107085961A (zh) * | 2017-06-22 | 2017-08-22 | 公安部交通管理科学研究所 | 一种车载终端、获取路口交通信号控制信息的方法及系统 |
GB2564430C (en) * | 2017-07-07 | 2021-02-17 | Gurulogic Microsystems Oy | Data communication system and method |
CN109587518B (zh) | 2017-09-28 | 2022-06-07 | 三星电子株式会社 | 图像传输装置、操作图像传输装置的方法以及片上系统 |
JP2019140577A (ja) * | 2018-02-13 | 2019-08-22 | 株式会社デンソー | 電子制御装置及び通信システム |
CN111867707A (zh) | 2018-03-15 | 2020-10-30 | 恩特格里斯公司 | 氟化过滤薄膜、过滤器及方法 |
DE102019004790A1 (de) * | 2019-07-11 | 2021-01-14 | Infineon Technologies Ag | Authentizität und Sicherheit auf der Sicherungsschicht für Fahrzeugkommunikationssystem |
US11521491B2 (en) * | 2020-01-24 | 2022-12-06 | Ford Global Technologies, Llc | Priority vehicle management |
Family Cites Families (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06237249A (ja) * | 1992-12-18 | 1994-08-23 | Kawasaki Steel Corp | ネットワーク管理のセキュリティシステム |
US6847365B1 (en) * | 2000-01-03 | 2005-01-25 | Genesis Microchip Inc. | Systems and methods for efficient processing of multimedia data |
US6986046B1 (en) * | 2000-05-12 | 2006-01-10 | Groove Networks, Incorporated | Method and apparatus for managing secure collaborative transactions |
JP2001358641A (ja) * | 2000-06-15 | 2001-12-26 | Matsushita Electric Ind Co Ltd | 車車間通信システム及び車車間通信装置 |
JP3920583B2 (ja) * | 2001-03-29 | 2007-05-30 | 株式会社日立製作所 | 通信セキュリティ保持方法及びその実施装置並びにその処理プログラム |
JP2003101533A (ja) * | 2001-09-25 | 2003-04-04 | Toshiba Corp | 機器認証管理システム及び機器認証管理方法 |
JP2003174441A (ja) * | 2001-12-05 | 2003-06-20 | Nippon Telegr & Teleph Corp <Ntt> | コンテンツ暗号化方法,コンテンツ復号化方法,コンテンツ暗号化装置およびコンテンツ復号化装置 |
US7152166B2 (en) * | 2002-06-26 | 2006-12-19 | Microsoft Corporation | Digital rights management (DRM) encryption and data-protection for content on device without interactive authentication |
US7313814B2 (en) * | 2003-04-01 | 2007-12-25 | Microsoft Corporation | Scalable, error resilient DRM for scalable media |
BRPI0412722B1 (pt) * | 2003-07-29 | 2017-10-24 | Thomson Licensing | Key synchronization for wireless lan (wlan) |
JP2005150848A (ja) * | 2003-11-11 | 2005-06-09 | Nissan Motor Co Ltd | 車車間通信装置 |
EP1549010B1 (en) * | 2003-12-23 | 2008-08-13 | Motorola Inc. | Rekeying in secure mobile multicast communications |
JP4551202B2 (ja) * | 2004-12-07 | 2010-09-22 | 株式会社日立製作所 | アドホックネットワークの認証方法、および、その無線通信端末 |
JP4714482B2 (ja) * | 2005-02-28 | 2011-06-29 | 株式会社日立製作所 | 暗号通信システムおよび方法 |
JP4533258B2 (ja) * | 2005-06-29 | 2010-09-01 | 株式会社日立製作所 | アドホックネットワーク用の通信端末および通信制御方法 |
US7734050B2 (en) * | 2006-03-27 | 2010-06-08 | Nissan Technical Center North America, Inc. | Digital certificate pool |
JP4611929B2 (ja) * | 2006-05-09 | 2011-01-12 | 株式会社トヨタIt開発センター | 車車間通信システムおよび車車間通信方法 |
JP5016394B2 (ja) * | 2006-06-07 | 2012-09-05 | 株式会社日立製作所 | 無線制御セキュリティシステム |
JP2008060809A (ja) * | 2006-08-30 | 2008-03-13 | Toyota Infotechnology Center Co Ltd | 車車間通信方法、車車間通信システムおよび車載通信装置 |
JP4858088B2 (ja) * | 2006-10-31 | 2012-01-18 | 沖電気工業株式会社 | 車載通信装置及び車々間通信システム |
CA2681507C (en) * | 2007-03-19 | 2013-01-29 | Telcordia Technologies, Inc. | Vehicle segment certificate management using short-lived, unlinked certificate schemes |
US20090092252A1 (en) * | 2007-04-12 | 2009-04-09 | Landon Curt Noll | Method and System for Identifying and Managing Keys |
JP2009212850A (ja) * | 2008-03-04 | 2009-09-17 | Panasonic Electric Works Co Ltd | 暗号通信システム |
JP5163192B2 (ja) * | 2008-03-13 | 2013-03-13 | 株式会社デンソー | 無線通信システム及び無線通信方法 |
JP2010028637A (ja) * | 2008-07-23 | 2010-02-04 | Fujitsu Ltd | 基地局、移動局、通信制御方法 |
JP4670919B2 (ja) * | 2008-08-29 | 2011-04-13 | 沖電気工業株式会社 | 車々間通信装置、及び車々間通信装置による経路修復方法 |
WO2010026637A1 (ja) * | 2008-09-04 | 2010-03-11 | 富士通株式会社 | 送信装置、受信装置、送信方法および受信方法 |
JP4670932B2 (ja) * | 2008-09-30 | 2011-04-13 | 沖電気工業株式会社 | 車々間無線通信装置及び車々間通信方法 |
JP5077186B2 (ja) * | 2008-10-17 | 2012-11-21 | 富士通株式会社 | 通信装置、通信方法及び通信プログラム |
JP2010118731A (ja) * | 2008-11-11 | 2010-05-27 | Advanced Telecommunication Research Institute International | 無線装置、通信制御方法 |
JP4784669B2 (ja) * | 2009-03-11 | 2011-10-05 | 沖電気工業株式会社 | 車々間通信装置、車群管理方法、及び通信制御方法 |
-
2011
- 2011-05-19 JP JP2012515764A patent/JP5301034B2/ja active Active
- 2011-05-19 CN CN2011800033739A patent/CN102484791A/zh active Pending
- 2011-05-19 WO PCT/JP2011/002806 patent/WO2011145353A1/ja active Application Filing
-
2012
- 2012-11-19 US US13/680,918 patent/US20130195272A1/en not_active Abandoned
-
2013
- 2013-06-03 JP JP2013116768A patent/JP5341273B1/ja active Active
- 2013-06-03 JP JP2013116769A patent/JP5341274B1/ja active Active
- 2013-06-03 JP JP2013116770A patent/JP5362928B2/ja active Active
- 2013-08-27 JP JP2013175841A patent/JP5732626B2/ja active Active
-
2015
- 2015-02-03 JP JP2015019200A patent/JP5891384B2/ja active Active
- 2015-11-04 JP JP2015216481A patent/JP6037153B2/ja active Active
-
2016
- 2016-10-18 JP JP2016204090A patent/JP6273658B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2017085561A (ja) | 2017-05-18 |
JP5891384B2 (ja) | 2016-03-23 |
JP5301034B2 (ja) | 2013-09-25 |
US20130195272A1 (en) | 2013-08-01 |
JP6273658B2 (ja) | 2018-02-07 |
JP5341273B1 (ja) | 2013-11-13 |
JP6037153B2 (ja) | 2016-11-30 |
JP2013243676A (ja) | 2013-12-05 |
JP2014003686A (ja) | 2014-01-09 |
JP2013219804A (ja) | 2013-10-24 |
JP2013232909A (ja) | 2013-11-14 |
JP5732626B2 (ja) | 2015-06-10 |
CN102484791A (zh) | 2012-05-30 |
JP5362928B2 (ja) | 2013-12-11 |
JP2015111913A (ja) | 2015-06-18 |
WO2011145353A1 (ja) | 2011-11-24 |
JPWO2011145353A1 (ja) | 2013-07-22 |
JP2016040949A (ja) | 2016-03-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6273658B2 (ja) | 基地局装置 | |
JP6273561B2 (ja) | 端末装置 | |
JP5362925B2 (ja) | 路側機および車載器 | |
JP5384767B1 (ja) | 通信装置 | |
JP5991561B2 (ja) | 無線装置 | |
JP6074714B2 (ja) | 通信装置 | |
JP2014158105A (ja) | 端末装置 | |
JP6187888B2 (ja) | 処理装置 | |
JP5903629B2 (ja) | 無線装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
TRDD | Decision of grant or rejection written | ||
R151 | Written notification of patent or utility model registration |
Ref document number: 5341274 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |