JP5431623B2 - 通信装置 - Google Patents
通信装置 Download PDFInfo
- Publication number
- JP5431623B2 JP5431623B2 JP2013528917A JP2013528917A JP5431623B2 JP 5431623 B2 JP5431623 B2 JP 5431623B2 JP 2013528917 A JP2013528917 A JP 2013528917A JP 2013528917 A JP2013528917 A JP 2013528917A JP 5431623 B2 JP5431623 B2 JP 5431623B2
- Authority
- JP
- Japan
- Prior art keywords
- unit
- mac
- verification
- rsu
- 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
- 238000004891 communication Methods 0.000 title claims description 201
- 238000012545 processing Methods 0.000 claims description 217
- 238000012795 verification Methods 0.000 description 301
- 230000005540 biological transmission Effects 0.000 description 117
- 238000000034 method Methods 0.000 description 105
- 230000008569 process Effects 0.000 description 60
- 238000004364 calculation method Methods 0.000 description 29
- 238000010586 diagram Methods 0.000 description 15
- 238000004422 calculation algorithm Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 6
- 101000636109 Homo sapiens Ras suppressor protein 1 Proteins 0.000 description 4
- 102100030800 Ras suppressor protein 1 Human genes 0.000 description 4
- 238000006243 chemical reaction Methods 0.000 description 4
- 238000010276 construction Methods 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 101150053844 APP1 gene Proteins 0.000 description 3
- 101100055496 Arabidopsis thaliana APP2 gene Proteins 0.000 description 3
- 101100189105 Homo sapiens PABPC4 gene Proteins 0.000 description 3
- 102100039424 Polyadenylate-binding protein 4 Human genes 0.000 description 3
- 101100016250 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) GYL1 gene Proteins 0.000 description 3
- 102100038359 Xaa-Pro aminopeptidase 3 Human genes 0.000 description 3
- 101710081949 Xaa-Pro aminopeptidase 3 Proteins 0.000 description 3
- 238000013459 approach Methods 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 3
- 238000000926 separation method Methods 0.000 description 3
- 230000007704 transition Effects 0.000 description 3
- 101100172132 Mus musculus Eif3a gene Proteins 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000000717 retained effect Effects 0.000 description 2
- 101001137642 Homo sapiens Kinase suppressor of Ras 1 Proteins 0.000 description 1
- 102100021001 Kinase suppressor of Ras 1 Human genes 0.000 description 1
- 230000005856 abnormality Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000012538 light obscuration Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000008054 signal transmission Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000010977 unit operation Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
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/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
-
- 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
-
- 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]
-
- 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)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
Description
本発明は、通信技術に関し、特に共通鍵暗号方式によるセキュリティ処理を実行する通信装置に関する。
自動車向け無線通信の形態は、路車間通信、車車間通信(車路車間通信を含む)に大別される。いずれの通信も、交差点での出会い頭の衝突やコーナー先の渋滞による追突防止などに活用できる。例えば、車車間通信においてGPS(Global Positioning System)などによって現在の位置情報をリアルタイムに検出し、その位置情報を車載器同士で交換しあうことによって、交差点での衝突防止を図ることができる。路車間通信では、交差点や路側に路側機が設置され、この路側機から車載器に上記のような運転支援情報が送信される。無線通信は有線通信に比較して通信の傍受や第三者のなりすましによる不正な介入が容易であるため、無線通信ではそれらへの対策が有線通信より重要となる。
リアルタイム性を重視する必要がある路車間通信および車車間通信では、共通鍵暗号化方式を採用することが有力である。しかしながら、路車間通信および車車間通信を同じ共通鍵で運用すると、その鍵が漏洩した場合、路車間通信および車車間通信の両方のセキュリティが破れてしまう。
本発明はこうした状況に鑑みてなされたものであり、その目的は、共通鍵暗号化方式を用いた通信システムのセキュリティを効率的に向上させる技術を提供することにある。
上記課題を解決するために、本発明のある態様の通信装置は、複数の共通鍵が含まれた部分共通鍵テーブルを複数結合することによって形成されるべき共通鍵テーブルを管理する管理部と、管理部において管理されている共通鍵テーブルのうち、いずれかの共通鍵を使用することによって、データに対するセキュリティ処理を実行する処理部と、処理部においてセキュリティ処理がなされたデータを送信あるいは受信する通信部とを備える。管理部は、共通鍵テーブルに新たな部分共通鍵テーブルを追加することによって、共通鍵テーブルを更新する。
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
本発明によれば、共通鍵暗号化方式を用いた通信システムのセキュリティを効率的に向上させることができる。
(実施例1)
本発明の実施例の基礎となった知見は、次の通りである。なりすまし防止や秘匿性確保のための技術として暗号方式がある。暗号化方式には、大別すると公開鍵暗号化方式と共通鍵暗号化方式がある。前者では事前に送信元と受信先が鍵を共有する必要がないこと、送信元ごとに鍵を設定できることから後者よりセキュリティは高い。しかし、同じ暗号強度の場合、前者は後者に比べてデータ量が多く、かつ、処理負荷が大きいため実装コストが高くなる。すなわち、両者はトレードオフの関係にある。
本発明の実施例の基礎となった知見は、次の通りである。なりすまし防止や秘匿性確保のための技術として暗号方式がある。暗号化方式には、大別すると公開鍵暗号化方式と共通鍵暗号化方式がある。前者では事前に送信元と受信先が鍵を共有する必要がないこと、送信元ごとに鍵を設定できることから後者よりセキュリティは高い。しかし、同じ暗号強度の場合、前者は後者に比べてデータ量が多く、かつ、処理負荷が大きいため実装コストが高くなる。すなわち、両者はトレードオフの関係にある。
本発明を具体的に説明する前に、概要を述べる。本発明の実施例は、交差点や路側などに設置された基地局装置から車両に搭載された端末装置に、情報を提供するために実行される路車間通信、および車両に搭載された端末装置から他の車両に情報を提供するために実行される車車間通信を用いたITS(Intelligent Transport Systems)などの通信システムに関する。
ITSでは、IEEE802.11などの規格に類した無線通信を用いることが検討されている。そのような無線通信では、CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)とよばれるアクセス制御機能が使用されている。そのため、当該無線LANでは、基地局装置および複数の端末装置によって同一の無線チャネルが共有される。このようなCSMA/CAでは、キャリアセンスによって他のパケット信号が送信されていないことを確認した後に、パケット信号がブロードキャストにより送信される(以下、パケット信号のブロードキャストによる送信を「報知」という)。
車車間通信として、端末装置は、それが搭載されている車両の速度や位置などを示す車両情報を格納したパケット信号を報知する。そのパケット信号を受信した端末装置は、そのパケット信号に格納された情報をもとに車両の接近などを認識する。また、路車間通信として、基地局装置は、交差点情報および渋滞情報などが格納されたパケット信号を報知する。
交差点情報には、交差点の位置情報、基地局装置が設置された交差点の路線情報、撮影画像、交差点内の車両や歩行者の位置情報など、交差点の状況に関する情報が含まれる。端末装置は、この交差点情報をモニタに表示する。また、この交差点情報をもとに交差点の状況を認識し、出会い頭・右折・左折による、車両、自転車、歩行者との衝突防止を目的とした視覚情報あるいは音声メッセージをユーザに通知してもよい。渋滞情報には、基地局装置が設置された走路の混雑状況、道路工事、事故に関する情報が含まれる。端末装置は、この渋滞情報をもとに進行方向の渋滞をユーザに伝達する。また、その渋滞を迂回するための迂回路を提示してもよい。
図1は、本発明の実施例に係る通信システム500の構成を示す。これは、ひとつの交差点を上方から見た場合に相当する。通信システム500は、基地局装置20、第1車両100aに搭載された端末装置10a、第2車両100bに搭載された端末装置10bを含む。エリア202は基地局装置20の電波圏内を示し、エリア外204は基地局装置20の電波圏外を示す。図面の上側が「北」に対応し、第1車両100aは「南」から「北」に進んでおり、第2車両100bは「東」から「西」に進んでいる。基地局装置20は外部ネットワーク200を介して外部の装置と通信が可能である。
図2(a)−(d)は、通信システム500において規定されるスーパーフレームのフォーマットを示す。図2(a)は、スーパーフレームの構成を示す。スーパーフレームは、第1サブフレームから第Nサブフレームと示されるN個のサブフレームによって形成されている。例えば、スーパーフレームの長さが100msecであり、Nが8である場合、12.5msecの長さのサブフレームが規定される。Nは、8以外であってもよい。
図2(b)は、第1基地局装置20aによって生成されるスーパーフレームの構成を示す。第1基地局装置20aは、基地局装置20のうちの任意のひとつに相当する。第1基地局装置20aは、第1サブフレームの先頭部分に路車送信期間を設定する。また、第1基地局装置20aは、第1サブフレームにおいて路車送信期間に続いて車車送信期間を設定する。車車送信期間とは、端末装置10がパケット信号を報知可能な期間である。つまり、第1サブフレームの先頭期間である路車送信期間において第1基地局装置20aはパケット信号を報知可能であり、第1サブフレームの路車送信期間に後続する車車送信期間において端末装置10がパケット信号を報知可能であるように規定される。さらに、第1基地局装置20aは、第2サブフレームから第Nサブフレームに車車送信期間のみを設定する。
図2(c)は、第2基地局装置20bによって生成されるスーパーフレームの構成を示す。第2基地局装置20bは、第1基地局装置20aとは異なった基地局装置20に相当する。第2基地局装置20bは、第2サブフレームの先頭部分に路車送信期間を設定する。また、第2基地局装置20bは、第2サブフレームにおける路車送信期間の後段、第1サブフレーム、第3サブフレームから第Nサブフレームに車車送信期間を設定する。
図2(d)は、第3基地局装置20cによって生成されるスーパーフレームの構成を示す。第3基地局装置20cは、第1基地局装置20aや第2基地局装置20bとは異なった基地局装置20に相当する。第3基地局装置20cは、第3サブフレームの先頭部分に路車送信期間を設定する。また、第3基地局装置20cは、第3サブフレームにおける路車送信期間の後段、第1サブフレーム、第2サブフレーム、第4サブフレームから第Nサブフレームに車車送信期間を設定する。このように、複数の基地局装置20は、互いに異なったサブフレームを選択し、選択したサブフレームの先頭部分に路車送信期間を設定する。
図3(a)−(b)は、サブフレームの構成を示す。図3(a)に示すように、サブフレームは、路車送信期間、車車送信期間の順に構成される。路車送信期間では基地局装置20がパケット信号を報知し、車車送信期間では端末装置10がパケット信号を報知可能である。図3(b)は、路車送信期間におけるパケット信号(以下、RSU(Road Side Unit)パケットという)の配置を示す。図示のごとく、路車送信期間において、複数のRSUパケット信号が並べられている。ここで、前後のRSUパケット信号は、SIFS(Short Interframe Space)だけ離れている。
図4(a)−(f)は、通信システム500において規定される各レイヤのフレームのフォーマットを示す。図4(a)は、物理レイヤのフレームフォーマットを示す。図示のごとく、フレームには、PLCPプリアンブル、PLCPヘッダ、PSDU(Physical Layer Service Data Unit)、テールが順に配置される。図4(b)は、MACレイヤのフレームフォーマットを示す。このフレームは、図4(a)のPSDUに格納される。図示のごとく、フレームには、MACヘッダ、MSDU(MAC Layer Service Data Unit)、FCS(Frame Check Sequence)が順に配置される。図4(c)は、LLCレイヤのフレームフォーマットを示す。このフレームは、図4(b)のMSDUに格納される。図示のごとく、フレームには、LLCヘッダ、LSDU(LLC Layer Service Data Unit)が順に配置される。
図4(d)は、車車間・路車間共用通信制御情報レイヤのフレームフォーマットを示す。このフレームは、図4(c)のLSDUに格納される。図示のごとく、フレームには、IRヘッダ、APDU(Application Protocol Data Unit)が順に配置される。図4(e)は、セキュリティレイヤのフレームフォーマットを示す。このフレームは、図4(d)のAPDUに格納される。図示のごとく、フレームには、セキュリティヘッダ(Security Header)、ペイロード(Payload)、セキュリティフッタ(Security Footer)が順に配置される。図4(f)は、アプリケーションレイヤのフレームフォーマットを示す。このフレームは、図4(e)のSPDUに格納されており、アプリケーションデータによって構成される。以下では、フレームフォーマットのことをデータ構造ともという。
図5(a)−(b)は、セキュリティフレームのデータ構造の一例を示す。これは、基地局装置20から報知される路車間通信のパケット信号に含まれるセキュリティフレームに相当する。図5(a)は、図3(b)に示された複数のRSUパケットのうちの、先頭のRSUパケットのセキュリティフレームであり、図5(b)は、2番目以降のRSUパケットのセキュリティフレームである。図5(a)のデータ構造では、「バージョン・メッセージタイプ」、「MAC方式ヘッダ」に続いて、「MAC方式ペイロード」が配置され、最後に「MAC方式フッタ」が配置される。また、「MAC方式ヘッダ」には、「鍵情報」、「Nonce」、「ペイロード長」が含まれ、「MAC方式ペイロード」には、「公開鍵証明書」、「後続パケットの認証用ハッシュ値」、「アプリケーション」、「電子署名」が含まれる。「MAC方式フッタ」には、「MAC」が含まれる。さらに、「鍵情報」には、「マスタ鍵ID」、「暗号化通信鍵」が含まれ、「Nonce」には、「機器ID」と「乱数」が含まれる。
「バージョン・メッセージタイプ」はフレームフォーマットのバージョンをセットする。「メッセージ形式」は、データ認証方式を規定する認証タイプ(AT)と、「ペイロード」に対する保護の形式を指定するメッセージタイプ(MT)のふたつをセットする。「マスタ鍵ID」は、マスタ鍵を識別するための識別情報である。「暗号化通信鍵」は、マスタ鍵で暗号化した通信鍵である。この通信鍵は送信元で乱数生成する。「Nonse」は、通信鍵を用いた暗号化処理(暗号化あるいはMAC生成)において結果を攪乱するために用いる通信毎にユニークな値である。ここでは「乱数」と「機器ID」がセットされる。「機器ID」は、パケット信号の発信元である端末装置10あるいは基地局装置20に対して割り当てられた機器IDをセットする。ここで、機器IDは、端末装置10あるいは基地局装置20に対してユニークに付与された識別番号である。
「乱数」は、パケット信号の送信時に送信元が発生した乱数がセットされる。すなわち、パケット信号の発信毎にユニークな値がセットされる。ここでは、「乱数」としているが、乱数に変えてメッセージの発信日時を示すセットする「日時情報」にしてもよい。この場合、日時情報はパケット信号の発信毎にユニークである必要があるため、スーパーフレームの周期よりも細かい分解能が要求される。但し、精度は要求されない。「ペイロード長」は、「ペイロード」のバイト数がセットされる。
「公開鍵証明書」は、送信元の基地局装置20に固有の公開鍵に対する公開鍵証明書をセットする。公開鍵証明書は公開鍵とその公開鍵の所有主体を結びつける証明書である。公開鍵証明書には、署名者の識別情報、公開鍵証明書の識別情報(機器IDであってもよい)、有効期限、公開鍵(鍵生成アルゴリズム、サイズなどを含む)、署名者の署名などが含まれる。本実施例では、署名者は認証局(CA:Certificate Authority)とする。当該署名は、例えば、RSA、DSA(Digital Signature Algorithm)、ECDSA(Elliptic Curve−DSA)などの公開鍵暗号方式により生成される。本実施例では、ECDSAを採用する。「後続パケットの認証用ハッシュ値」は、後続のセキュリティフレーム、より詳細には後続のセキュリティフレームの「アプリケーション」に対するハッシュ値のリストをセットする。「アプリケーション」には、路車間アプリケーションデータがセットされる。
「電子署名」は、「後続パケットの認証用ハッシュ値」、「アプリケーションデータ」に対する署名がセットされる。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。さらに、署名をセットした後、MAC値が、導出されて「MAC」にセットされる。この例では、MACの演算対象は「MAC方式ヘッダ」の「Nonce」と「ペイロード長」と「MAC方式ペイロード」であり、暗号化の対象は「MAC方式ペイロード」と「MAC方式フッタ」である。
図5(b)のデータ構造では、「バージョン・メッセージタイプ」、「MAC方式ヘッダ」に続いて、「MAC方式ペイロード」が配置され、最後に「MAC方式フッタ」が配置される。「MAC方式ヘッダ」と「MAC方式フッタ」の構造は、図5(a)と同一なので説明を省略する。また、「MAC方式ペイロード」には、「証明書ダイジェスト」、「アプリケーションデータ」が含まれる。「証明書ダイジェスト」は、送信元の基地局装置20に固有の公開鍵に対する公開鍵証明書のダイジェストがセットされる。ここではダイジェストとして公開鍵証明書のボディ、すなわち、公開鍵証明書の署名の対象部に対するハッシュ値、例えば、SHA−224、SHA−225によって求められた値、あるいはその一部を当てるとするが、公開鍵証明書に含まれる署名、署名の一部、公開鍵、証明書の識別情報(例えば、シリアル番号)、または/かつ機器IDをダイジェストとして代用してもよい。さらに、ダイジェストとして機器IDを代用とする場合、図示しない「送信元機器ID」にセットされている機器IDと同一で値であれば「ダイジェスト」を省略してもよい。MAC値が、導出されて「MAC」にセットされる。図5(a)と同様に、MACの演算対象は「MAC方式ヘッダ」の「Nonce」と「ペイロード長」と、「MAC方式ペイロード」である。暗号化の対象は「MAC方式ペイロード」と「MAC方式フッタ」である。
図6は、セキュリティフレームのデータ構造の別の一例を示す。これは、端末装置10から報知される車車間通信のパケット信号に含まれるセキュリティフレームに相当する。車車間通信では、路車間通信と比較して大きなサイズのパケット信号が送信できないこと、報知されるパケット信号の総数が多いこと、情報の精度が路車間送信のパケット信号に含まれる情報より低いことなどから、公開鍵暗号方式が使用されない。その代わりに、共通鍵暗号方式によるMAC(Message Authentication Code)を使用して、パケット信号に含まれる情報の完全性を認証する。このデータ構造では、MAC方式ヘッダとして、「バージョン」、「メッセージ形式」、「鍵ID」、「機器ID」、「乱数」、「ペイロード長」が配置され、その後に「MAC方式ペイロード」として「機器管理コード」、「車車間アプリケーション」が配置され、最後にMAC方式ペイロード方式フッタとして「MAC」が配置される。
「鍵ID」は、端末装置10と基地局装置20間、あるいは、ある端末装置10と他の端末装置10の間で事前に共有されている通信鍵を指定するための識別情報である鍵IDをセットする。「機器ID」は、パケット信号の発信元である端末装置10に対して割り当てられた機器IDをセットする。ここで、機器IDは、端末装置10に対してユニークに付与された識別番号である。
「乱数」は、パケット信号の送信時に送信元が発生した乱数がセットされる。すなわち、パケット信号の発信毎にユニークな値がセットされる。ここでは、「乱数」としているが、乱数に変えてメッセージの発信日時を示すセットする「日時情報」にしてもよい。この場合、日時情報はパケット信号の発信毎にユニークである必要があるため、スーパーフレームの周期よりも細かい分解能が要求される。但し、精度は要求されない。「ペイロード長」には、「MAC方式ペイロード」のバイト数がセットされる。「アプリケーション」には、車車間アプリケーションデータがセットされる。図5(a)と同様に、MACの演算対象は、「MAC方式ヘッダ」の「Nonce」と「ペイロード長」と「MAC方式ペイロード」であり、暗号化の対象は、「MAC方式ペイロード」と「MAC方式フッタ」である。また、図5(a)−(b)、図6のセキュリティフレームにおいて「アプリケーション」に先行して配置されるデータが、図4の「セキュリティヘッダ」に「アプリケーション」に続いて配置されるデータが、図4の「セキュリティフッタ」に相当する。また、以降では、MAC方式ペイロードを単にペイロードとよぶものとする。
図7は、基地局装置20の構成を示す。基地局装置20は、アンテナ21、RF部22、変復調部23、MACフレーム処理部24、セキュリティ処理部25、データ生成部26、ネットワーク通信部27、記憶部28および制御部29を備える。セキュリティ処理部25は暗復号部251、暗号部252および鍵更新部253を含む。
MACフレーム処理部24、セキュリティ処理部25、データ生成部26、ネットワーク通信部27、記憶部28および制御部29の構成は、ハードウエア的には、任意のプロセッサ、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ハードウエアとソフトウエアの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
RF部22は、受信処理として、端末装置10および他の基地局装置20からのパケット信号をアンテナ21にて受信する。RF部22は、受信した無線周波数のパケット信号に対して周波数変換を実行し、ベースバンドのパケット信号を生成する。RF部22は、ベースバンドのパケット信号を変復調部23に出力する。一般的に、ベースバンドのパケット信号は、同相成分と直交成分によって形成されるため、ふたつの信号線が示されるべきであるが、図を簡略化するため、図7ではひとつの信号線だけを示している。RF部22は、受信系の構成要素として、図示しないLNA(Low Noise Amplifier)、ミキサ、AGC、A/D変換部などを含む。
RF部22は、送信処理として、生成したパケット信号を基地局装置20から送信する。RF部22は、変復調部23から入力されるベースバンドのパケット信号に対して周波数変換を実行し、無線周波数のパケット信号を生成する。RF部22は、RSU期間において、無線周波数のパケット信号をアンテナ21から送信する。RF部22は、送信系の構成要素として、図示しないPA(Power Amplifier)、ミキサ、D/A変換部などを含む。
変復調部23は、受信処理として、RF部22からのベースバンドのパケット信号に対して、復調を実行する。変復調部23は、復調した結果から、MACフレームをMACフレーム処理部24に出力する。また、変復調部23は、送信処理として、MACフレーム処理部24からのMACフレームに対して、変調を実行する。変復調部23は、変調した結果をベースバンドのパケット信号としてRF部22に出力する。
本実施例に係る通信システム500では、OFDM(Orthogonal Frequency Division Multiplexing)変調方式を採用する。この場合、変復調部23は受信処理としてFFT(Fast Fourier Transform)を実行し、送信処理としてIFFT(Inverse Fast Fourier Transform)を実行する。
MACフレーム処理部24は、受信処理として、変復調部23からのMACフレームから、セキュリティフレームを取り出し、セキュリティ処理部25に出力する。また、MACフレーム処理部24は、送信処理として、セキュリティ処理部25からのセキュリティフレームに対して、MACヘッダ、LLCヘッダおよびIR情報ヘッダを付加し、MACフレームを生成し、変復調部23に出力する。また、他の基地局装置20または端末装置10からのパケット信号が衝突しないようパケット信号の送受信タイミングを制御する。
ネットワーク通信部27は、外部ネットワーク200に接続される。ネットワーク通信部27は、外部ネットワーク200から工事や渋滞等に関する道路情報を受けつける。また、ネットワーク通信部27は、路車間通信用のマスタ鍵(以下、路車間マスタ鍵という)、暗号化更新鍵テーブルおよびテーブル更新鍵を受けつける。また、ネットワーク通信部27は、セキュリティ処理部25による処理結果を外部ネットワーク200へ出力したり、記憶部28に蓄積して、定期的に外部ネットワーク200へ出力したりする。
記憶部28は、種々の情報(例えば、路車間マスタ鍵、共通鍵テーブル、テーブル更新鍵)を記憶する。ここで、共通鍵テーブルは、部分共通鍵テーブルを複数結合することによって形成されている。また、部分共通鍵テーブルには、複数の共通鍵が含まれている。本実施例では、外部ネットワーク200から取得される道路情報、新しい路車間マスタ鍵、暗号化更新鍵テーブルおよびテーブル更新鍵、ならびに端末装置10から提供される機器IDおよび共通鍵テーブルID(以下適宜、テーブルIDという)を一時的に記憶する。制御部29は、基地局装置20全体の処理を制御する。データ生成部26は、センサやカメラ(図示されない)などからの情報や、記憶部28に記憶されている情報を利用してサービスアプリケーションデータを生成する。そして、サービスアプリケーションデータの内容によって、メッセージ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部25に出力する。
セキュリティ処理部25は、セキュリティフレームを生成または解釈する。セキュリティ処理部25は、送信処理として、データ生成部26からサービスアプリケーションデータを受け取ると、MACフレーム処理部24に出力すべきセキュリティフレームを、受け取ったサービスアプリケーションデータと記憶部28に記憶されているデータをもとに生成する。例えば、図5(a)−(b)に示す「MAC方式ペイロード」の「路車アプリケーション」に、データ生成部26から受け取ったサービスアプリケーションデータをセットし、そのデータ長をセキュリティヘッダのペイロード長にセットする。また、図5(b)に示す「MAC方式ペイロード」の「路車アプリケーション」に対するハッシュを演算し、図5(a)に示す「MAC方式ペイロード」の「後続パケットの認証用ハッシュリスト」にセットする。また、「MAC方式ペイロード」の「後続パケットの認証用ハッシュリスト」と「アプリケーション」に対する署名を演算し、「MAC方式ペイロード」の「電子署名」にセットする。また、「セキュリティヘッダの鍵情報の通信鍵に、マスタ鍵で暗号化された通信鍵(乱数)をセットする。また、当該通信鍵(乱数)を用いて生成されるメッセージ認証コード(MAC)を「セキュリティフッタにセットする。そして、その他のセキュリティヘッダを付加してセキュリティフレームを生成する。その後、指定されたメッセージ形式が認証付き暗号化データの場合、ペイロードおよびメッセージ認証コード(MAC)を当該通信鍵(乱数)を用いて暗号化することで、メッセージを秘匿することも可能である。
セキュリティ処理部25は、受信処理として、MACフレーム処理部24からのセキュリティフレームを受けつける。セキュリティ処理部25は、セキュリティフレームのうちのセキュリティヘッダの内容を確認する。メッセージタイプが認証付きデータである場合、暗復号部251にてメッセージの検証処理を実行する。メッセージタイプが認証付き暗号化データである場合、暗復号部251にてメッセージの復号処理を実行し、検証処理を実行する。なお、メッセージタイプが平文である場合、これらの処理は省略される。
セキュリティ処理部25は、暗復号部251、暗号部252および鍵更新部253を含む。ここでは、基地局装置20からのパケット送信に注目するため、送信処理として実行されるセキュリティフレームを生成する処理に注目する。受信処理として行われるセキュリティフレームを解釈する処理については、後述する端末装置10の受信処理と同じである。暗復号部251は、通信鍵を用いてペイロードを対象としたメッセージ認証コード(MAC)を生成する。メッセージ認証コード(MAC)は、AES(Advanced Encryption Standard)−CBC(Cipher Block Chaining)モードを利用したMACアルゴリズムを適用して生成される。なお、MACの生成には、Nonseやペイロード長も利用される。次いで、メッセージ形式が認証付き暗号化データの場合、通信鍵を用いてペイロードとセキュリティフッタの暗号化が行われる。暗号化は、AES_CTR(CounTeR)モードを適用する。本実施例では、暗復号部251は、メッセージ形式が認証付き暗号化データの場合には、通信鍵(乱数)を用いたAES−CCM(Counter with CBC−MAC)モードを適用したため、ペイロードに対するメッセージ認証コード(MAC)の付加およびペイロードとメッセージ認証コード(MAC)の暗号化を行う。なお、AES―CCMモードを適用せずに、ペイロードより暗号化を行った後、メッセージ認証コード(MAC)の付加を行ってもよいし、暗号化のみを行ってもよい。なお、ペイロードを対象としたメッセージ認証コードの生成、および、ペイロードとセキュリティフッタの暗号化には、通信鍵の他に、Nonceやペイロード長が利用される。CBC−MACおよびCCMモードのアルゴリズムによるものであり、Nonceの使用により、ペイロードと通信鍵が同じであっても、異なったメッセージ認証コード値、暗号化の結果が得られる。
暗号部252は、基地局装置20より端末装置10に対して送信する鍵を暗号化する。具体的には、暗復号部251で使用した通信鍵(乱数)を路車間マスタ鍵で暗号化する。また、暗号部252は、路車間通信で使用するマスタ鍵を更新する際、現マスタ鍵で新マスタ鍵を暗号化する。また、暗号部252は、車車間通信で使用する共通鍵テーブルを更新する際、現テーブル更新鍵で新テーブル更新鍵を暗号化する。鍵更新部253は、路車間マスタ鍵の更新処理を行う。また、端末装置10が保持すべき共通鍵テーブルの更新処理を行う。
図8は、車両100に搭載された端末装置10の構成を示す。端末装置10は、アンテナ11、RF部12、変復調部13、MACフレーム処理部14、セキュリティ処理部15、受信処理部161、通知部162、データ生成部17、記憶部18および制御部19を備える。セキュリティ処理部15は、暗復号部151、復号部152および鍵更新部153を含む。
MACフレーム処理部14、セキュリティ処理部15、受信処理部161、通知部162、データ生成部17、記憶部18および制御部19の構成は、ハードウエア的には、任意のプロセッサ、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ハードウエアとソフトウエアの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
アンテナ11、RF部12、変復調部13およびMACフレーム処理部14は、図2のアンテナ21、RF部22、変復調部23およびMACフレーム処理部24の構成および動作は基本的に共通する。以下、これらの構成要素については、相違点を中心に説明する。アンテナ11、RF部12、変復調部13およびMACフレーム処理部14は、メッセージ認証コードの付加や暗号化等のセキュリティ処理がなされたデータを格納したパケット信号を報知する。また、アンテナ11、RF部12、変復調部13およびMACフレーム処理部14は、共通鍵暗号方式によるセキュリティ処理がなされたデータを受信する。
受信処理部161は、セキュリティ処理部15から受け取ったデータと、データ生成部17から受け取った自車の車両情報にもとづき、衝突の危険性、救急車や消防車といった緊急車両の接近、進行方向の道路および交差点の混雑状況などを推定する。また、データが画像情報であれば通知部162に表示するよう処理する。
通知部162は、図示しないモニタ、ランプ、スピーカなどのユーザへの通知手段を含む。受信処理部161からの指示にしたがって、図示しない他の車両の接近などを当該通知手段を介して運転者に通知する。また、渋滞情報、交差点などの画像情報などをモニタに表示する。
データ生成部17は、図示しないGPS受信機、ジャイロスコープ、車速センサなどから供給される情報にもとづき、端末装置10が搭載された車両100の現在位置、進行方向、移動速度などを特定する。なお、現在位置は、緯度・経度によって示される。これらの情報の特定方法は一般的な公知の技術により実現可能であるため、ここでは説明を省略する。データ生成部17は、特定した情報をもとに他の端末装置10や基地局装置20に報知すべきデータを生成し、生成したデータ(以下、アプリケーションデータという)をセキュリティ処理部15に出力する。そして、アプリケーションデータの内容によって、メッセージ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部15に出力する。また、特定した情報を受信処理部161に自車の車両情報として出力する。
記憶部18は、種々の情報(例えば、路車間マスタ鍵、共通鍵テーブル、テーブル更新鍵)を記憶する。また、本実施例では基地局装置20から取得される道路情報、自己または他の端末装置10から取得される車両情報、ならびに基地局装置20から取得される暗号化新しい路車間マスタ鍵、暗号化更新共通鍵テーブルおよび暗号化テーブル更新鍵を保持する。前述のごとく、共通鍵テーブルは、複数の部分共通鍵テーブルを複数結合することによって形成されている。また、部分共通鍵テーブルには、共通鍵暗号方式における共通鍵が複数含まれている。制御部19は、端末装置10全体の処理を制御する。
セキュリティ処理部15は、セキュリティフレームを生成または解釈する。セキュリティ処理部15は、送信処理として、MACフレーム処理部14に出力すべきセキュリティフレームを、記憶部18に記憶されたデータをもとに生成する。例えば、図6に示す「MAC方式ペイロード」に車車間アプリケーションのデータをセットする。また、「MAC方式ヘッダ」の「鍵情報」の「鍵ID」に、メッセージ認証コード(MAC)生成に使用する通信鍵の鍵IDをセットし、「Nonce」に自己の機器IDと乱数をセットする。また、鍵IDによって共通鍵テーブルより選択された通信鍵を用いて生成されるメッセージ認証コード(MAC)をセキュリティフッタにセットする。通信鍵は、記憶部18に保持される1つの部分共通鍵テーブルから1つ任意選択される。どの部分共通鍵テーブルから選択するかは予め決められているものとする。
そして、その他のセキュリティヘッダを付加してセキュリティフレームを生成する。メッセージ形式が、認証付き暗号化データの場合、ペイロードおよびメッセージ認証コード(MAC)を当該通信鍵を用いて暗号化することで、メッセージを秘匿する。なお、メッセージタイプが平文である場合、これらの処理は省略される。このようにセキュリティ処理部15は、記憶部18に保持した共通鍵テーブルのうち、いずれかの共通鍵を使用することによって、データに対するセキュリティ処理を実行する。送信処理におけるセキュリティ処理とは、前述のごとく、メッセージ認証コードを生成することや、暗号化することである。
セキュリティ処理部15は、受信処理として、MACフレーム処理部14からのセキュリティフレームを受け付ける。セキュリティ処理部15は、セキュリティフレームのうちのセキュリティヘッダの内容を確認する。メッセージタイプが認証付きデータである場合、暗復号部151にてメッセージの検証処理を実行する。メッセージ形式が認証付き暗号化データである場合、暗復号部151にてメッセージの復号処理および検証処理を実行する。なお、メッセージ形式が平文である場合、これらの処理は省略される。つまり、メッセージタイプが認証付きデータまたはメッセージ形式が認証付き暗号化データである場合、セキュリティ処理部15は、図5(a)−(b)に示すセキュリティフレームを受け付けると、記憶部18に保持されたマスタ鍵によってセキュリティヘッダの暗号化通信鍵を復号して通信鍵を取り出す。図6に示すセキュリティフレームを受け付けると、鍵IDにしたがって、記憶部18に保持された共通鍵のうち、セキュリティフレームに対して使用された共通鍵を通信鍵として取り出す。そして取り出した通信鍵によって、セキュリティ処理の送信処理とは逆の受信処理を実行する。すなわち、メッセージタイプが認証付きデータの場合、「MAC方式ペイロード」に対するMACを生成し、「MAC」の値と比較する。一致すればメッセージの完全性が確認される。また、メッセージタイプが認証付き暗号化データの場合、「MAC方式ペイロード」および「MAC方式フッタ」を復号し、複合語の「MAC方式ペイロード」に対するMACを生成し、「MAC」の値と比較する。一致すればメッセージの完全性が確認される。また、図5(a)に示すセキュリティフレームでは、「電子署名」の検証を行う。検証に成功すれば、メッセージの発信元の真正性が確認できる。図5(b)に示すセキュリティフレームでは、「アプリケーション」のハッシュを演算し、同じグループの図5(a)に示すセキュリティフレームの「後続パケットの認証用ハッシュリスト」に含まれる自身に対するハッシュと比較する。同じグループの図5(a)に示すセキュリティフレームの署名検証に成功し、かつ、ハッシュ一致すれば、メッセージの発信元の真正性が確認される。セキュリティ処理の受信処理とは、メッセージの検証処理やメッセージの復号処理である。
セキュリティ処理部15は、暗復号部151、復号部152および鍵更新部153を含む。暗復号部151は、ペイロードに対するMACの生成と検証および、ペイロードとメッセージ認証コード(MAC)に対する暗号化および復号を行うことができる。すなわち、セキュリティヘッダのメッセージタイプのメッセージ形式にしたがった処理を行い、基地局装置20の暗復号部251と同等の機能を備える。したがって、送信処理は、基地局装置20の暗復号部251と同じであるため説明を割愛する。暗復号部151は、受信処理として、MACフレーム処理部14からセキュリティフレームを受け取る。メッセージ形式が認証付き暗号化データの場合、暗復号部151は、通信鍵を用いてペイロードとセキュリティフッタを復号する。そして、ペイロードに付加されたメッセージ認証コード(MAC)を検証する。メッセージ形式が暗号化データの場合、暗復号部151は、通信鍵を用いてペイロードを復号する。なお、復号および検証は送信側の暗号アルゴリズムに対応する復号アルゴリズムにより実行される。また、メッセージ形式が平文である場合、暗復号部151は復号および検証を実行しない。
復号部152は、基地局装置20から報知されるパケット信号に含まれる通信鍵(乱数)を路車間マスタ鍵で復号する。また、路車間通信で使用するマスタ鍵が更新される際、復号部152は基地局装置20から報知されるパケット信号に含まれる暗号化新マスタ鍵を現マスタ鍵で復号する。また、車車間通信で使用される共通鍵テーブルが更新される際、復号部152は基地局装置20から報知されるパケット信号に含まれる暗号化テーブル更新鍵を現テーブル更新鍵で復号する。
鍵更新部153は、自己(端末装置10)が保持すべき路車間マスタ鍵の更新処理および車車間通信用の共通鍵テーブルの更新処理を行う。前述のごとく、共通鍵テーブルは、複数の部分共通鍵テーブルによって形成されている。ここで、共通鍵テーブルを形成するために結合可能な部分共通テーブル数は予め定められている。鍵更新部153は、共通鍵テーブルに新たな部分共通鍵テーブルを追加することによって、共通鍵テーブルを更新する。
具体的に説明すると、結合可能な部分共通鍵テーブル数に達するまで、鍵更新部153は、共通鍵テーブルの更新のために、新たな部分共通鍵テーブルを追加する。そのため、共通鍵テーブルに含まれる共通鍵数は増加する。一方、結合可能な部分共通鍵テーブル数に達してから、鍵更新部153は、共通鍵テーブルの更新のために、共通鍵テーブルに既に含まれた部分共通鍵テーブルを新たな部分共通鍵テーブルによって置き換える。そのため、共通鍵テーブルに含まれる共通鍵数は一定である。なお、鍵更新部253においても、共通鍵テーブルは同様に更新される。
セキュリティ処理部15が、検証や復号を実行する際、メッセージ認証コードの生成や暗号化に通信鍵として使用された共通鍵を含め部分共通鍵テーブルを記憶部18に保持していない場合、その旨を鍵更新部153に出力する。鍵更新部153は、その旨を通知部162に通知させる。例えば、通知部162は、最新の共通鍵に対応していないことをモニタに表示したり、音声として出力したりする。ランプの点灯、エラーメッセージの表示、問い合わせを促すメッセージの表示によって、通知がなされてもよい。これによって、運転者は、記憶部18に保持される鍵テーブルに最新の部分共通鍵テーブルが含まれないこと、すなわち、現在の共通鍵が最新の共通鍵に対応していないこと認識する。さらに、マスタ鍵にも鍵IDが付与されているので、マスタ鍵が記憶部18に保持されていない場合、鍵更新部153は、その旨を通知する。周辺の端末装置10や基地局装置20が更新されることによって当該端末装置10との鍵の共有がなされなくなった場合に、運転者への通知がなされる。鍵更新部153は、メッセージ認証コードの生成や暗号化に使用された共通鍵を記憶部18に保持していない場合、基地局装置20や他の端末装置10に対して共通鍵の更新を要求する。これは、運転者からの指示によってなされてもよいし、自動的になされてもよい。
図9は、本実施例に係る通信システム500を用いた路車間通信における通常のメッセージ送受信手順を説明するための図である。基地局装置20の暗復号部251は、通信鍵とすべき乱数を発生させる。暗復号部251は、平文の送信データに対して当該通信鍵を用いて、メッセージ認証コード(MAC)を付加して、MAC付きの送信データを暗号化する。それとともに、暗号部252は当該通信鍵を路車間マスタ鍵を用いて暗号化する。これらの暗号化にはいずれも共通鍵暗号化方式が用いられる。セキュリティ処理部25は、暗号化送信データと暗号化通信鍵を格納したパケット信号を生成する。当該パケット信号は、MACフレーム処理部24および変復調部23を経て、RF部22からアンテナ21を介して外部に報知される。
端末装置10のRF部12は、当該パケット信号をアンテナ11を介して受信する。当該パケット信号は、変復調部13およびMACフレーム処理部14を経て、セキュリティ処理部15に渡される。復号部152は、当該パケット信号に格納された暗号化通信鍵を、基地局装置20と共通している路車間マスタ鍵で復号する。暗復号部151は、当該パケット信号に格納された暗号化送信データを、復号された通信鍵で復号し、MAC検証する。復号化およびMAC検証が成功したら、暗号化送信データは平文の送信データに復元される。
このメッセージ送受信方法には以下に示す様々なメリットがある。まず、動的に通信鍵を変えることができるので、後述する車車間通信におけるメッセージ送受信方法のように事前に複数の通信鍵を保持しておく必要がない。また、通信鍵として乱数を暗号化するため、通信路中から路車間マスタ鍵が漏洩するリスクが小さい。路車間マスタ鍵が漏洩しない限り、基本的に、システム運用管理機関や路車間サービス提供者は何もしなくてよい。また、路車間マスタ鍵が漏洩しても、マスタ鍵の更新の仕組みが知られない限り、通信鍵が漏洩するリスクは小さい。さらに、路車間通信により路車間マスタ鍵を更新することにより、漏洩リスクを低減できる。更新されるデータ量が少ないため、路車間マスタ鍵の更新は、路車間通信で十分に対応可能である。
図10は、本実施例に係る通信システム500を用いた路車間通信における路車間マスタ鍵の更新手順を説明するための図である。図示しない装置において、更新用の新しい路車間マスタ鍵を生成する。この更新用の新しい路車間マスタ鍵は、定期的に生成されてもよいし、路車間マスタ鍵の漏洩が発覚した場合に生成されてもよいし、その両方であってもよい。基地局装置20の鍵更新部253は、新しい路車間マスタ鍵を受けつけると、自己の路車間マスタ鍵を更新する。具体的には、現路車間マスタ鍵を、前路車間マスタ鍵として、受けつけた新しい路車間マスタ鍵を現路車間マスタ鍵として、記憶部28に記録する。
そして、更新後の一定期間、現路車間マスタ鍵(受けつけた新しい路車間マスタ鍵)をパケット信号に格納して報知するように制御する。暗号部252は、現路車間マスタ鍵(受けつけた新しい路車間マスタ鍵)を前路車間マスタ鍵を用いて暗号化する。この暗号化には共通鍵暗号化方式が用いられてもよいし、公開鍵暗号化方式が用いられてもよい。暗号化された新しい路車間マスタ鍵は、パケット信号に格納されて報知される。
端末装置10の復号部152は、当該パケット信号に格納された、暗号化された路車間マスタ鍵が格納されていると、自身の保持する現路車間マスタ鍵を用いて復号する。鍵更新部153は、復号部152より復号された路車間マスタ鍵を受け取ると、自身の保持する現マスタ鍵より、受け取った路車間マスタ鍵が新しい時に、原マスタ鍵を、受け取った路車間マスタ鍵に置き換え(記憶部18に保持される路車間マスタ鍵も更新する。)、この新しい路車間マスタ鍵を更新後の正当な路車間マスタ鍵とする。
図11は、本実施例に係る通信システム500を用いた車車間通信における通常のメッセージ送受信手順を説明するための図である。端末装置10の暗復号部151は、共通鍵テーブルに格納された複数の部分共通鍵テーブルを選択するとともに、選択した部分共通鍵テーブルからひとつの通信鍵をランダムに選択する。図11における鍵テーブルが共通鍵テーブルに相当する。図11におけるテーブル1、テーブル2が部分共通鍵テーブルに相当する。暗復号部151は、平文の送信データに対して当該通信鍵を用いてMACを生成し、MAC付きの送信データを暗号化する。セキュリティ処理部15は、暗号化送信データと、選択された通信鍵の鍵IDを格納したパケット信号を生成する。当該パケット信号は、MACフレーム処理部14および変復調部13を経て、RF部12からアンテナ11を介して外部に報知される。
別の端末装置10のRF部12は、当該パケット信号をアンテナ11を介して受信する。当該パケット信号は、変復調部13およびMACフレーム処理部14を経て、セキュリティ処理部15に渡される。暗復号部151は、当該パケット信号に格納された鍵IDにより特定される通信鍵を共通鍵テーブルから読み出し、当該パケット信号に格納された暗号化送信データを、当該通信鍵で復号し、MAC検証する。MAC検証が成功したら、暗号化送信データは平文の送信データに復元される。このような受信処理は、基地局装置20においてもなされる。
このメッセージ送受信方法には以下に示す様々なメリットがある。まず、静的に通信鍵を使用するため、上述した路車間通信におけるメッセージ送受信方法より、データ通信量を抑えられる。また、複数の通信鍵を保持しておくことにより、通信路中から通信鍵が漏洩するリスクを小さくできる。また、共通鍵テーブルが漏洩した場合、新バージョンの部分共通鍵テーブルを追加することにより、セキュリティ低下を抑えられる。
図12(a)−(b)は、共通鍵テーブルのフォーマットを示す。図12(a)は、初期状態の共通鍵テーブルを示す。図示のごとく、テーブルID=1のみに、K個の通信鍵が含まれる。K個の通信鍵のまとまりが、ひとつの部分共通鍵デーブルに相当する。図12(b)は、更新された状態の共通鍵テーブルを示す。図示のごとく、テーブルID=1と2のふたつの部分共通鍵テーブルが含まれる。また、鍵テーブルには、Current Table IDには送信処理に利用する部分共通鍵テーブルのテーブルIDがセットされている。図12(a)では、テーブルID=1の部分共通鍵テーブルが、図12(b)では、テーブルID=2の部分共通鍵テーブルから通信鍵として使用する共通鍵が選択される。
図13は、共通鍵テーブルの運用方法の一例を示す。図13では、共通鍵テーブルが、4つの部分共通鍵テーブルによって形成されているとする。初期状態(出荷時)には、端末装置10にはひとつの部分共通鍵テーブル(バージョン=1、テーブルID=1)が、Current Table IDをテーブルID=1が保持される。送信側の端末装置10はこの部分共通鍵テーブル(バージョン=1、テーブルID=1)からひとつの通信鍵を選択して、MAC生成および暗号化に使用する。なお、共通鍵テーブルを形成する部分共通鍵テーブルの数は4に限定されるものではない。また、初期状態(出荷時)に、端末装置10に複数の部分共通鍵テーブルが保持されていても良い。
この部分共通鍵テーブル(バージョン=1、テーブルID=1)に対して、新たな部分共通鍵テーブル(バージョン=2、テーブルID=2)が追加され、Current Table IDをテーブルID=2に変更される。送信側の端末装置10はCurrent Table IDで示される最新の部分共通鍵テーブル(バージョン=2、テーブルID=2)からひとつの通信鍵を選択して、MAC生成および暗号化に使用する。同様に、部分共通鍵テーブル(バージョン=3、テーブルID=3)、部分共通鍵テーブル(バージョン=4、テーブルID=4)の順に新たな部分共通鍵テーブルが追加される。
4つの部分共通鍵テーブルが端末装置10に保持された後、共通鍵テーブルを更新する場合、一番古い部分共通鍵テーブル(バージョン=1、テーブルID=1)に、新たな部分共通鍵テーブル(バージョン=5、テーブルID=1)が上書き(更新)される。以下、この処理が繰り返される。なお、図13において太線で囲われた部分共通鍵テーブルは、最新の部分共通鍵テーブルである。
本実施例の実施例によれば、共通鍵テーブルをまとめて更新するのではなく、部分共通鍵テーブルを追加するように更新するので、部分共通鍵テーブルの個別性を高めることができる。また、部分共通鍵テーブルの個別性が高められるので、一部の部分共通鍵テーブルが漏洩した場合であっても、共通鍵テーブルの全体が漏洩する可能性を低減できる。また、共通鍵テーブルの全体が漏洩する可能性が低減されるので、通信システムの安全性を向上できる。また、共通鍵テーブルをまとめて更新するのではなく、部分共通鍵テーブルを追加するように更新するので、更新時のデータ量を低減できる。
また、共通鍵テーブルのサイズを超えるまでは、部分共通鍵テーブルを追加し、共通鍵テーブルのサイズに達すると、部分共通鍵テーブルを置き換えるので、共通鍵テーブルのサイズを制限できる。また、共通鍵を記憶していない場合、その旨を運転者に通知するので、共通鍵の更新を運転者に促すことができる。また、共通鍵を記憶していない場合、共通鍵の更新を要求するので、新たな共通鍵を使用可能にできる。
以上、本発明の実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
基地局装置20から報知される路車間通信のパケット信号に含まれるセキュリティフレームが次のように構成されてもよい。図14(a)−(b)は、セキュリティフレームのデータ構造のさらに別の一例を示す。図5(a)−(b)の変形例であり、図14(a)は、図3(b)に示された複数のRSUパケットのうちの、先頭のRSUパケットのセキュリティフレームであり、図5(a)に相当し、図14(b)は、2番目以降のRSUパケットのセキュリティフレームであり、図5(b)に相当する。先頭のRSUパケットの「フレームの認証用ハッシュ値」には、グループを構成するすべてのセキュリティフレームの「アプリケーション」に対するハッシュ値を配置したリストをセットする。電子署名の対象は「フレームの認証用ハッシュ値」のみである。これによって処理の単一化、先頭のRSUパケットのアプリケーションデータの通信喪失による欠落によって、「フレームの認証用ハッシュ値」に対する電子署名の検証ができなくなることが防止されるとともに、早期に署名検証処理を始めることができる。なお、図5(a)では、アプリケーションデータに先行して配置される「バージョン・メッセージ」、「MAC方式ヘッダ」、「公開鍵証明書」、「パケットの認証用ハッシュ値」、「電子署名」がセキュリティヘッダに、アプリケーションデータに続いて配置される「MAC方式フッタ」がセキュリティフッタとなる。図5(b)では、「バージョン・メッセージ」、「MAC方式ヘッダ」、「証明書ダイジェスト」がセキュリティヘッダに、アプリケーションデータに続いて配置される「MAC方式フッタ」がセキュリティフッタとなる。
通信鍵を双方鍵テーブルから選択される場合、あるいは双方マスタ鍵で暗号化されて送付される場合もある。
(実施例2)
本発明の実施例の基礎となった知見は、次の通りである。通信内容の秘匿性を確保するには、通信データに対して暗号方式を利用したメッセージ認証を行う手法が有効である。暗号方式には、大別すると公開鍵暗号化方式と共通鍵暗号化方式がある。前者は後者と比較し、セキュリティは高いがデータ量が多く、かつ、処理負荷が大きいため実装コストが高くなる。すなわち、両者はトレードオフの関係にある。路車間通信では、車車間通信より公共性が強いため、なりすましやデータ改ざんを防ぐ要請がより大きくなる。そこで、路側機から車載器に、公開鍵証明書および電子署名付きのデータを格納したパケット信号を報知するシステムが検討されている。
本発明の実施例の基礎となった知見は、次の通りである。通信内容の秘匿性を確保するには、通信データに対して暗号方式を利用したメッセージ認証を行う手法が有効である。暗号方式には、大別すると公開鍵暗号化方式と共通鍵暗号化方式がある。前者は後者と比較し、セキュリティは高いがデータ量が多く、かつ、処理負荷が大きいため実装コストが高くなる。すなわち、両者はトレードオフの関係にある。路車間通信では、車車間通信より公共性が強いため、なりすましやデータ改ざんを防ぐ要請がより大きくなる。そこで、路側機から車載器に、公開鍵証明書および電子署名付きのデータを格納したパケット信号を報知するシステムが検討されている。
しかしながら、すべてのパケット信号に含まれる公開鍵証明書および電子署名の検証を実行するには高速な処理が必要となり、端末装置に高速のハードウエアを搭載する必要性が発生する。これらの検証処理には公開鍵暗号方式が用いられるため、演算量が多くなり回路規模が増大し、コストアップする要因となる。さらには処理遅延によって適切なタイミングで情報を得ることができず、ユーザが適切なタイミングでサービスを享受できなくなる。本発明はこうした状況に鑑みてなされたものであり、その目的は、セキュリティを向上させつつ、パケット信号を受信する際の処理負荷を軽減させる技術を提供することにある。
ここで、路車間通信として、基地局装置は、交差点情報および渋滞情報などが格納されたパケット信号を報知する。なお、「無線装置」は、基地局装置であってもよいし、端末装置であってもよい。
本発明の実施例に係る通信システム500の構成は、図1と同様であるので、ここでは説明を省略する。通信システム500において規定されるスーパーフレームのフォーマットは、図2(a)−(d)と同様である。基地局装置20は、1つまたは複数のサブフレームの先頭部分に路車送信期間を設定し、パケット信号を発信する。ここでは、説明を簡単にするため1つの基地局装置20は1つのサブフレームを使用して、パケット信号を送信するものとする。図2(b)において、第1基地局装置20aの電波到達距離内に配置される他の基地局装置20および端末装置10は、この期間にパケット信号を報知することはない。
このように、基地局装置20は、自身がパケット信号(情報)を報知するために1つのサブフレームの路車送信期間を独占することで、固有の報知期間をスーパーフレーム内に設けている。スーパーフレーム内に設定可能なサブフレームは有限(本実施の形態では8個)ではあるが、複数の基地局装置20の電波到達距離を考慮して、スーパーフレームを選択すれば、基地局装置20の設置台数を制限することはない。逆に、スーパーフレーム内のすべてのサブフレームに対して基地局装置20が設置されるものとは限らない。
サブフレームの構成は、図3(a)−(b)と同様である。図3では、1つの基地局装置20は、5つのRSUパケット、すなわちRSUパケット1、RSUパケット2、RSUパケット3、RSUパケット4、RSUパケット5を順に送信する。通信システム500において規定される各レイヤのフレームのフォーマットは、図4(a)−(f)と同様である。
図15は、端末装置10が送信する車車間通信のパケット信号のセキュリティレイヤのフレームフォーマットの詳細な構成例を示す。車車間通信では、大きなパケット信号が送信できないこと、報知されるパケット信号の総数が多いこと、情報の精度が路車間送信のパケット信号に含まれる情報より低いことなどから、公開鍵暗号方式は使用せず、共通鍵暗号方式によるMAC(Message Authentication Code)を使用して、パケット信号に含まれる情報の完全性を認証する。このデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ID」、「送信元機器ID」、「乱数」、「データ長」が配置され、その後に「ペイロード」が配置され、最後にセキュリティフッダとして「MAC」が配置される。ここで、「」は、セキュリティフレームを構成するフィールドを表している。
「バージョン」はフレームフォーマットのバージョンをセットする。「メッセージ形式」は、データ認証方式を規定する認証タイプ(AT)と、「ペイロード」に対する保護の形式を指定するメッセージタイプ(MT)の2つをセットする。図16は、「メッセージ形式」の詳細である。先頭の2ビットである認証タイプ(AT)は、1ビットの2つのフラグ情報MAC FlagとSIG Flagからなる。MAC Flagは、共通鍵暗号方式によるMAC認証に対応するか否かを示し、SIG Flagは、公開鍵暗号方式による署名認証に対応するか否かを示す。MAC認証のみに対応する車車間通信パケット信号では、MAC Flag=1、SIG Flag=0となる。メッセージタイプ(AT)は、いずれの形式も設定できる。メッセージタイプ(MT)は、平文データ形式(=0)、認証付きデータ形式(=1)および認証付き暗号化データ形式(=2)がある。
「鍵ID」は、基地局装置20と端末装置10間、あるいは、ある端末装置10と他の端末装置10の間で事前に共有されている通信鍵を指定するための識別情報である鍵IDをセットする。「送信元機器ID」は、パケット信号の発信元である端末装置10に対して割り当てられた機器IDをセットする。ここで、機器IDは、端末装置10あるいは基地局装置20に対してユニークに付与された識別番号である。
「乱数」は、パケット信号の送信時に送信元が発生した乱数がセットされる。すなわち、パケット信号の発信毎にユニークな値がセットされる。ここでは、「乱数」としているが、乱数に変えてメッセージの発信日時を示すセットする「日時情報」にしてもよい。この場合、日時情報はパケット信号の発信毎にユニークである必要があるため、スーパーフレームの周期よりも細かい分解能が要求される。但し、精度は要求されない。
「データ長」は、「ペイロード」のバイト数がセットされる。「ペイロード」には、アプリケーションデータがセットされる。「MAC」は、メッセージタイプ(AT)が、認証付きデータ形式(=1)または認証付き暗号化データ形式(=2)の場合に、MACの値がセットされる。
次に、図15のセキュリティフレームに対する暗号技術について説明する。ここでは、共通鍵暗号方式として、AES(Advanced Encryption Standard)を採用するものとする。具体的には、データ形式が認証付きデータ形式(=1)の場合には、CBC−MAC(Cipher Block Chaining − Message Authentication Code)を、認証付き暗号化データ形式(=2)である場合、CCM(Counter with CBC Mode)とする。なおCCMは、メッセージ認証にCBC−MACを、データ秘匿(暗号化)にCTR(CounTeR)モードを用いた暗号化認証モードである。処理を簡単化するために、データ形式が認証付きデータ形式(=1)におけるMACの演算対象および演算手順は、CCMにおけるMACの演算対象および演算手順に従うものとする。
「鍵ID」にセットされている鍵IDに当該通信鍵を用いて、MAC値を求める。CCMのCBC−MAC演算では、通信鍵を用いた暗号化において暗号結果を攪乱するために用いる通信毎にユニークな値であるnonceが、CBC−MAC演算およびCounterモードのCounterブロックに使用される。図15のセキュリティフレームでは、nonceとして、「送信元機器ID」と「乱数」に、それぞれセットされている機器IDと乱数を連結して使用する。この乱数は送信元の端末装置10において送信時に生成した乱数であり、乱数のデータ長の範囲でユニークさが保証されている。なお、nonceとして乱数のみを使用してもよい。MACの演算は、nonceとデータ長を、「ペイロード」にセットされているアプリケーションデータの先頭に連結したデータを対象として行う。
この例では、MACの演算対象は「機器ID」、「乱数」、「データ長」と「ペイロード」であり、暗号対象は、「ペイロード」および「MAC」である。自明ではあるが暗号化を行うのはMAC値を求めた後になる。
図17は、基地局装置20が送信する路車間通信パケット信号のセキュリティレイヤのフレームの詳細な構成例を示す。図17(a)は、図3のRSUパケット1のセキュリティフレームであり、図17(b)は、図3のRSUパケット2〜5のセキュリティフレームである。つまり、RSU期間の先頭のRSUパケットのセキュリティフレームは図17(a)に従い、同一のRSU期間にて送信される残りのRSUパケットのセキュリティフレームは図17(b)に従う。
図17(a)のデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ID」、「送信元機器ID」、「乱数」、「データ長」、「公開鍵証明書」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」が配置され、その後に「ペイロード」が配置され、最後にセキュリティフッダとして「電子署名」と「MAC」が配置される。「バージョン」、「メッセージ形式」、「鍵ID」、「送信元機器ID」、「乱数」、「ペイロード」および「MAC」については、図15のデータ構造のそれと同じなので説明を割愛する。但し、このデータ構造はMAC認証と署名認証に両対応するので、MAC Flag=1、SIG Flag=1となる。
「データ長」は、「公開鍵証明書」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」、「ペイロード」および「電子署名」の総バイト数がセットされる。「公開鍵証明書」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」、「ペイロード」および「電子署名」を1つのフィールドとしてとらえると、図15のセキュリティフレームと同一のデータ構造となる。
「公開鍵証明書」は、送信元の基地局装置20に固有の公開鍵に対する公開鍵証明書をセットする。公開鍵証明書は公開鍵とその公開鍵と対をなす秘密鍵の所有主体を結びつける証明書である。公開鍵証明書には、署名者の識別情報、機器ID、有効期限、公開鍵(鍵生成アルゴリズム、サイズなどを含む)、署名者の署名などが含まれる。本実施例では、署名者は認証局(CA:Certificate Authority)とする。当該署名は、たとえば、RSA、DSA(Digital Signature Algorithm)、ECDSA(Elliptic Curve−DSA)などの公開鍵暗号方式により生成される。本実施例では、ECDSAを採用する。
「フレーム番号」は、RSU期間に配置されるセキュリティフレームの順序、すなわちRSUパケット順序をセットする。フレーム番号が0スタートとすると、図17(a)のデータ構造を持つセキュリティフレームは、先頭に配置されるセキュリティフレームであることから、0をセットする。「最終フレーム番号」は、RSU期間に送信される最後のセキュリティフレームの番号、すなわち、RSU期間に配置されるRSUパケットの総数−1をセットする。図3に従う基地局装置20が送信したRSUパケットのセキュリティフレームの場合、4をセットする。また、フレーム番号が1スタートとしてもよい。この場合、図17(a)データ構造を持つセキュリティフレームの「フレーム番号」に1を、「最終フレーム番号」にRSU期間のフレーム総数をセットする。「フレーム認証リスト」は、後続のセキュリティフレームのデータに対する認証データのリストをセットする。
「電子署名」は、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」「認証データリスト」および「ペイロード」に対する署名がセットされる。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。なお、署名対象には「フレーム認証リスト」が含まれるため、このセキュリティフレームのメッセージタイプ(MT)によって、署名の必要性が判断できないので、認証タイプ(AT)=1の時は、「電子署名」に署名をセットする。次いで、メッセージタイプ(MT)が、認証付きデータ形式(=1)、または、認証付き暗号化データ形式(=2)の時は、署名をセットした後、MAC値を求め、「MAC」にセットする。そして、暗号化を行う。この例では、MACの演算対象は「機器ID」、「乱数」、「データ長」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」、「ペイロード」および「電子署名」であり、暗号対象は、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」、「認証データリスト」、「ペイロード」、「電子署名」および「MAC」である。
図17(b)のデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ID」、「送信元機器ID」、「乱数」、「データ長」、「ダイジェスト」、「フレーム番号」、「最終フレーム番号」が配置され、その後に「ペイロード」が配置され、最後にセキュリティフッダとして「MAC」が配置される。「バージョン」、「メッセージ形式」、「鍵ID」、「送信元機器ID」、「乱数」、「フレーム番号」、「最終フレーム番号」と「ペイロード」および「MAC」については、図17(a)のデータ構造のそれと同じなので説明を割愛する。
図3に従う基地局装置20が送信したRSUパケットのセキュリティフレームの場合、「最終フレーム番号」は、4をセットされる。RSUパケット2の「フレーム番号」は、1をセットされる。同様にRSUパケット3、RSUパケット4、RSUパケット5の「フレーム番号」は、それぞれ1、2、3、4がセットされる。「データ長」は、「ダイジェスト」、「フレーム番号」、「最終フレーム番号」、「ペイロード」および「電子署名」の総バイト数がセットされる。「ダイジェスト」、「フレーム番号」、「最終フレーム番号」および「ペイロード」を1つのフィールドとしてとらえると、図15のセキュリティフレームと同一のデータ構造となる。
「ダイジェスト」は、送信元の基地局装置20に固有の公開鍵に対する公開鍵証明書のダイジェストがセットされる。ここではダイジェストとして公開鍵証明書のボディ、すなわち、公開鍵証明書の署名の対象部に対するハッシュ値、例えば、SHA−224、SHA−225によって求められた値、あるいはその一部を当てるとするが、公開鍵証明書に含まれる署名、署名の一部、公開鍵または/かつ機器IDをダイジェストとして代用してもよい。さらに、ダイジェストとして機器IDを代用とする場合、「送信元機器ID」にセットされている機器IDと同一で値であれば「ダイジェスト」を省略してもよい。この例では、MACの演算対象は「機器ID」、「乱数」、「データ長」、「ダイジェスト」、「フレーム番号」、「最終フレーム番号」および「ペイロード」であり、暗号対象は、「フレーム番号」、「最終フレーム番号」、「ダイジェスト」、「ペイロード」および「MAC」である。
なお、1つの基地局装置20が複数の路車通信期間を使用する場合、後続のRSU期間に送信されるRSUパケットのセキュリティフレームを、全て図17(b)としてもよい。この場合、基地局装置20からスーパーフレームに送信されるRSUパケットのうち、先頭のRSUパケットのセキュリティフレームが図17(a)に、残りのRSUパケットのセキュリティフレームがすべて図17(b)に従う。
また、図4においてセキュリティフレームが、RSUパケットに収まるように説明したが、基地局装置20が複数のアプリケーションデータを連結して送信する場合、アプリケーションデータ単位で、セキュリティフレームを構成するようにしてもよい。この場合、基地局装置20からスーパーフレームに送信されるアプリケーションデータのうち、先頭に送信されるアプリケーションデータが、図17(a)に従ったセキュリティフレームの「ペイロード」にセットされ、残りのアプリケーションデータが、図17(b)に従った異なるセキュリティフレームの「ペイロード」にセットされる。この後、パケット単に分割され、RSUパケットとして送信される。
図18は、「フレーム認証リスト」にセットする、認証データのリストの構成例を示す。後続するセキュリティフレームのMAC値をフレーム番号順に並べたリストである。サイズは、(認証データのバイト数)×(総フレーム数−1)となる。セットされるMAC値は、図17(b)における「MAC」にセットされるMAC値と同じである。なお、MAC値でなく、ハッシュ値のリストとしてもよい。この場合、ハッシュ演算の対象は、「フレーム番号」、「最終フレーム番号」および「ペイロード」である。なお、「フレーム認証リスト」には、後続するセキュリティフレームのMAC値をフレーム番号順に並べたリストとしたが、MAC値に変えて、ハッシュ関数によるダイジェスト値をセットしてもよい。
図19は、端末装置10に4つのRSU用コア(RSU1用コア〜RSU4用コア)が搭載される場合において、各RSU用コアの処理例を示す。図16では車両100が「西」から「東」に進行する。車両100が通過するエリアの近傍には、5つの路側機(図16では第1基地局装置20a、第2基地局装置20b、第3基地局装置20c、第4基地局装置20d、第5基地局装置20e)が設置されている。
説明の便宜上、第1基地局装置20a、第2基地局装置20b、第3基地局装置20c、第4基地局装置20d、第5基地局装置20eは、図3に従ったRSUパケット送信するものとする。また、RSUパケット1のセキュリティフレームの公開鍵証明書の検証および署名検証処理を、単に署名検証と呼び、RSUパケット1〜5のセキュリティフレームに対するMAC認証処理を、MAC認証と呼ぶ。受信したRSUパケットのセキュリティフレームのメッセージタイプ(MT)が認証付き暗号化データ形式(=2)のとき、復号後に、署名検証およびMAC検証は実行される。
図19において、期間Tvは、基地局装置20からの電波が受信できずRSU用コアが処理を停止している期間を示し、期間Tcは署名検証を実行している期間を示し、期間TmはMAC検証を実行している期間を示し、期間Tmcは署名検証とMAC検証を平行して実行している期間を示す。期間Tvは車両100が、新たに第1基地局装置20aの電波圏内に入ると開始する。第1基地局装置20aの電波圏内に入り、RSUパケット1を受信すると、RSU1用コアは、第1基地局装置20aから報知されるRSUパケット1の署名検証を実行する。そして署名検証に成功すると、期間Tmに移行する。
期間Tmでは、RSU1用コアは受信したRSUパケットのMAC検証を実行し、MAC検証の結果を報告する。期間Tmに移行後、一定時間が経過してRSUパケット1を受信すると期間Tmcに移行する。期間Tmcでは、期間移行のきっかけとなったRSUパケット1に対する署名検証と、受信するRSUパケットのMAC検証を平行して行う。そして、MAC検証の結果を報告する。また、署名検証が成功すると再び期間Tmに戻る。車両100が第1基地局装置20aの電波圏外に出ると、期間Tvに移行する。その後、車両100が第5基地局装置20eの電波圏内に入り、第5基地局装置20eからのRSUパケット1を受信すると、再び期間Tcに移行し、第5基地局装置20eからのRSUパケット1の署名検証を実行する。以後の処理は第1基地局装置20aに対する処理と同じであるため説明を省略する。RSU2用コア〜RSU4用コアも、RSU1用コアと同様の処理を実行する。
図20は、基地局装置20の構成を示す。基地局装置20は、アンテナ21、RF部22、変復調部23、MACフレーム処理部24、セキュリティ処理部25、データ生成部26、ネットワーク通信部27、記憶部28および制御部29を備える。これは、図7と同様であるので、ここでは差異を中心に説明する。
ネットワーク通信部27は、外部ネットワーク200に接続される。ネットワーク通信部27は、外部ネットワーク200から工事や渋滞などに関する道路情報を受けつける。
また、ネットワーク通信部27は、セキュリティ処理部25による処理結果を外部ネットワーク200へ出力したり、記憶部28に蓄積して、定期的に外部ネットワーク200へ出力したりする。データ生成部26は、アプリケーションデータを生成する。たとえば、アプリケーションデータに道路情報をセットする。そして、アプリケーションデータの内容によって、データ形式を指定し、生成したアプリケーションデータと、そのデータ長をセキュリティ処理部25に出力する。記憶部28は、種々の情報を記憶する。制御部29は、基地局装置20全体の処理を制御する。
セキュリティ処理部25は、セキュリティフレームを生成または解釈する。本実施例では、基地局装置20からのパケット送信に注目するため、セキュリティフレームを生成する処理に注目する。セキュリティ処理部25は、MACフレーム処理部24に出力すべきセキュリティフレームを、データ生成部26から受け取ったアプリケーションデータ、認証局から受け取った秘密鍵、公開鍵証明書、通信鍵(共通鍵)などを利用して生成する。
セキュリティ処理部25は、署名部1251と、暗号部1252と、記憶部1253を含む。記憶部1253は、本実施例では図示しない認証局が発行する秘密鍵と、この秘密鍵と対をなす公開鍵を含む公開鍵証明書、公開鍵証明のダイジェスト、機器ID、複数の通信鍵を内部に格納している。このうち秘密鍵と公開鍵証明書を、基地局装置20に固有である。署名部1251は、ハッシュ関数を用い署名対象に対するハッシュ値の演算および記憶部1253が格納する秘密鍵と演算したハッシュ値を用いた署名対象に対する署名の生成をする。暗号部1252は、記憶部1253に格納された通信鍵の1つを選択してMAC演算を実行し、MAC対象に対するMAC値を求める。暗号部1252は、MAC演算に用いた通信鍵を用いて暗号対象の暗号化をする。
図21は、車両100に搭載された端末装置10の構成を示す。端末装置10は、アンテナ11、RF部12、変復調部13、MACフレーム処理部14、セキュリティ処理部15、受信処理部161、通知部162、データ生成部17、記憶部18および制御部19を備える。これは、図8と同様であるので、ここでは差異を中心に説明する。データ生成部17は、特定した情報を受信処理部161に自車の車両情報として出力する。記憶部18は、種々の情報を記憶する。制御部19は、端末装置10全体の処理を制御する。
セキュリティ処理部15は、セキュリティフレームを生成または解釈する。本実施例では、基地局装置20からのパケット受信に注目するため、そのパケット信号に格納されたセキュリティフレームを解釈する処理に注目する。セキュリティ処理部15は、検証部1151、復号部1152および記憶部1153を含む。記憶部は123は、本実施例では図示しない認証局が発行する認証用の公開鍵と、自身の機器ID、複数の通信鍵を内部に格納している。復号部1152は、セキュリティフレームの「鍵ID」により特定される通信鍵を記憶部1153から取得して、暗号対象を復号する。検証部1151は、ハッシュ関数を用いたハッシュ値の演算と、ハッシュ値および記憶部1153に格納されている認証用の公開鍵を用いて基地局装置20の公開鍵証明書の署名および署名の署名検証、および、セキュリティフレームの「鍵ID」により特定される記憶部1153に格納される通信鍵を用いて、MAC検証をする。なお、認証鍵は、認証局において公開鍵証明書の署名を生成するのに用いた秘密鍵と対をなす公開鍵である。
図22は、検証部1151の構成例を示す。構成例に係る検証部1151は、ハッシュ演算部1151a、ECDSA検証部1151b、ダイジェスト保持部1151c、MAC検証部1151d、検証制御部1151eを含む。この構成例では、各RSU用コアは、ダイジェスト保持部1151c、検証制御部1151eによって構成される。
ハッシュ演算部1151aは、ハッシュ関数を用いて公開鍵証明書および、図17(a)に従うセキュリティフレーム、すなわち、RSUパケット1の署名対象に対するハッシュ値を演算する。ECDSA検証部1151bは、基地局装置20から報知されるパケット信号に含まれる公開鍵証明書に含まれる署名を、記憶部1153に保持される認証鍵(公開鍵)を用いて検証し、RSUパケット1の署名を、RSUパケット1に含まれる公開鍵証明書の公開鍵を用いて実行する。認証鍵は予め組み込まれていてもよいし、安全な手段で事後的に取得し、記憶部1153に格納したものであってもよい。具体的には、ECDSA検証アルゴリスに従い、公開鍵とハッシュ演算部1151aで求めたハッシュ値と署名とを利用し検証をする。説明の便宜上、RSUパケット1に含まれる公開鍵証明書の検証と署名対象の検証をひとまとめとにしてRSU検証と呼ぶ。RSU検証の成功(承認ともいう)とは、双方の検証が承認されたことを意味する。
ダイジェスト保持部1151cは、RSU検証が公開鍵証明書および署名対象の検証が成功したセキュリティフレームの公開鍵証明書のダイジェスト、公開鍵、機器ID等を保持する。説明の便宜上、これらの情報をまとめてRSU検証情報と呼ぶ。ダイジェスト保持部1151cは、各RSU期間(サブスロット)毎にRSU検証情報を保持する。すなわち、RSU用コアの数だけRSU検証情報を保持する。公開鍵証明書のダイジェストとして、ここでは公開鍵証明書のハッシュ値を当てるとするが、公開鍵証明書のシリアル番号、公開鍵または/かつ機器IDをダイジェストとして代用してもよい。すなわち、受信したセキュリティフレームから公開鍵証明書あるいは公開鍵証明書と対をなす秘密鍵の所有主体が特定できる情報であればいかなる情報であっても良い。なお、公開鍵証明書のシリアル番号とする場合は、セキュリティフレームの公開鍵証明書のダイジェストを公開鍵証明書のシリアル番号に置き換える必要がある。このようにするとダイジェスト保持部1151cに保持するデータ量が削減される。MAC検証部1151dは、RSUパケット1〜5のMAC対象に対するMAC値を演算し、演算により求めたMAC値とセキュリティフレームの「MAC」にセットされているMAC値とを比較することでMAC検証を行う。両者が一致すると成功(承認ともいう)、不一致だと失敗(否認ともいう)となる。MAC検証には、記憶部1153に格納されている鍵IDで特定される通信鍵を用いる。ここでは路車間通信の受信にのみ着目して説明しているが、MAC検証部1151dは車車間通信の送受信の処理、すなわち図15のセキュリティフレームのMAC検証、MAC生成にも利用される。なお、MAC検証はECDSA検証に比べて高速で処理できる。ゆえに、MAC検証結果とアプリケーションデータを受信処理部161に対して同じタイミングで提供することができる。
RSU検証が成功すれば、当該RSUパケット1は当該認証局により証明された真性な基地局装置20であり、当該RSUパケット1は真性な基地局装置20から送信された正規のパケット信号である判断できる。しかしながら、このRSU署名には公開鍵暗号方式(本実施例ではECDSA)が用いられるため、すべてのRSUパケット1において公開鍵証明書の検証を実行すると処理負荷が増大する。そこで、一定の期間RSU検証を適宜、スキップする。
以下では特に断りがない限り、ダイジェスト保持部1151cにRSU検証情報に関する処理はパケット信号を受信したRSU期間に対応するRSU検証情報に対する処理である。検証制御部1151eは、基地局装置20から報知されるRSUパケット1を受信すると、ハッシュ演算部1151aに、そのRSUパケット1に含まれる公開鍵証明書のダイジェストの演算を指示する。ダイジェストが演算されると、検証制御部1151eは、演算されたダイジェストとダイジェスト保持部1151cに保持されるダイジェストとの比較をする。両者が異なる場合、検証制御部1151eは当該RSUパケット1に含まれる公開鍵証明書の検証を実行するようECDSA検証部1151bに指示する。公開鍵証明書の検証が成功した場合、検証制御部1151eは当該RSUパケット1の署名の検証を実行するようECDSA検証部1151bに指示する。引き続き署名検証が成功、すなわち、RSU検証が成功すると、検証制御部1151eは、ダイジェスト保持部1151cに保持されるRSU検証情報を検証したRSUパケット1のRSU検証情報に更新する。公開鍵証明書の検証が失敗または署名検証に失敗した(RSU検証の失敗、あるいは、否認ともいう)場合処理を終了する。両ダイジェストが対応(より厳密には、一致)する場合、当該パケット信号に含まれるRSU検証をスキップする。ただし、RSU検証後、予め定められた所定の期間が経過するとRSU認証を行いRSU検証情報の正当性を再確認する。すなわち、RSU検証後の一定期間は、公開鍵証明書のダイジェストの一致をもってRSU検証成功とみなす。しかしながら、ある基地局装置20から報知されたRSUパケット1のRSU検証が一度成功したからといって、そのまま放置すると損なわれるため一定期間毎にRSU検証を行い信頼性は高める。なお、RSUパケット1〜2に含まれるアプリケーションデータの真性および正当性は、両ダイジェストの一致とMAC検証の成功をもって承認と判定する。
次に、RUSパケットの検証について説明する。RSUパケットを受信すると、検証制御部1151eは、MAC検証部1151dに対してRSUパケットのMAC検証を指示する。MAC検証が成功(承認)すると、MAC検証部1151dは、ダイジェスト保持部1151cに保持されているRSU認証済みのダイジェストと、当該RSUパケットの公開鍵証明書のダイジェストの一致を確認する。当該RSUパケットの公開鍵証明書のダイジェストとは、RSUパケット1のとき、当該RSUパケットに含まれる公開鍵証明書を入力として、ハッシュ演算部1151aで算出したハッシュ値である。また、RSUパケット2〜5のとき、当該RSUパケットの「ダイジェスト」にセットされているダイジェストである。ダイジェスト保持部1151cに一致するダイジェストが保持されていると、MAC検証部1151dは当該RSUパケットの検証成功と判断し、承認を通知する。ダイジェスト保持部1151cに一致するダイジェストが保持されていないと、RSUパケットの改ざんはないが、送信先の基地局装置20の特定ができないと判断し、不定を通知する。MAC検証が失敗(否認)すると、検証制御部1151eは、否認を通知する。
このように判断することで、MAC検証終了後に検証結果を出力できるようになり車車間通信のパケットの検証結果とほぼ同等の遅延にて検証結果を提供できる。なお、車車間通信のパケットの検証は、MAC値の一致の確認のみであるため説明は詳細な省略する。
図23は、構成例に係る検証部1151が用いられる端末装置10のRSUパケットの受信処理を示すフローチャートである。RF部12はRSUパケットを受信する。このRSUパケットは変復調部13、MACフレーム処理部14を経て、セキュリティ処理部15に出力される。セキュリティ処理部15の検証部1151がRSUパケットを受け取ると処理が開始される。検証制御部1151eはRSUパケットを受け取るとMAC検証部1151dにMAC検証を開始するように指示する(S10)。そして受け取ったRSUパケットのフレーム番号を確認する(S11)。フレーム番号が0の場合(S11のY)、ハッシュ演算部1151aに当該RSUパケットに配置された公開鍵証明書のダイジェストの演算を指示する。指示を受けたハッシュ演算部1151aは公開鍵証明書のダイジェストを演算して求める(S12)。検証制御部1151eは、ハッシュ演算部1151aが演算して求めた公開鍵証明書のダイジェストと、ダイジェスト保持部1151cに保持される公開鍵証明書のダイジェストとの一致するを比較し、一致するか否か判定する(S13)。
ダイジェストが一致しない場合(S13のN)、検証制御部1151eはECDSA検証部1151bの動作状態をチェックする(S17)。ECDSA検証部1151bが待機中の場合(S17のY)、検証制御部1151eはECDSA検証部1151bに当該RSUパケットのRSU認証の開始を指示し(S14)、当該RSUパケットに対する処理を終了する。一方、ECDSA検証部1151bが稼働中の場合(S17のN)、検証制御部1151eはして受信されたRSUパケットのRSU検証を断念し、当該RSUパケットに対する処理を終了する。
ダイジェストが一致した場合(S13のY)、検証制御部1151eは当該ダイジェストを含むRSU検証情報がダイジェスト保持部1151cに保持されてからの経過時間を確認する(S16)。これはRSU検証が成功してからの経過時間を確認することになる。予め定めた所定の時間を経過している場合(S16のY)、当該RSUパケットのRSU検証を試みるためステップS17に移行する。ステップS11にてフレーム番号が0以外の場合(S11のN)、RSU検証は必要ないと判断し、当該RSUパケットに対する処理を終了する。予め定めた所定の時間を経過していない場合(S16のN)、処理は終了される。
図24は、ECDSA検証部1151bにおけるRSUパケットのRSU検証処理を示すフローチャートである。RSUパケット1を対象とする。ECDSA検証部1151bは検証制御部1151eからRSUパケットのRSU認証開始の指示を受けると、ECDSA検証部動作状態を稼働中に変更する(S30)。そして、記憶部1153に格納されている認証鍵を取得して当該RSUパケットに含まれる公開証明書の検証を行う(S31)。当該検証が成功した場合(S31のY)、当該公開鍵証明書に含まれる公開鍵を用いて、当該RSUパケットに含まれる署名の検証を行う(S32)。当該検証が成功した場合(S32のY)、ダイジェスト保持部1151cに格納されている、当該公開鍵証明書のダイジェストを含むRSU検証情報に上書きする(S33)。このとき経過時間はリセットされる。ステップS30にて当該RSUパケットに含まれる公開鍵証明書の検証が失敗した場合(S31のN)またはステップS31にて当該RSUパケットに含まれる署名の検証が失敗した場(S32のN)、当該RSUパケットを受信したRSU検証情報を破棄する(S35)。ステップS33またはステップS35が終了すると、ECDSA検証部動作状態を待機中に変更して(S34)、RSU検証の処理を終了する。
図25は、MAC検証部1151dにおけるRSUパケットのMAC検証処理を示すフローチャートである。MAC検証部1151dは検証制御部1151eからRSUパケットのMAC認証開始の指示を受けると、当該RSUパケットの鍵IDにしたがって記憶部1153に格納されている通信鍵を取得する(S40)。MAC検証部1151dは取得した通信鍵を用いて当該RSUパケットのMACの演算対象に対するMAC値を演算する(S41)。そして、演算によって得たMAC値と、当該RSUパケットに含まれるMAC値を比較する(S42)。2つのMAC値が一致する場合(S42のY)、当該RSUパケットがRSUパケット1のとき、ハッシュ演算部1151aから当該RSUパケットに含まれる公開鍵証明書のダイジェストを取得する(S43)。当該RSUパケットがRSUパケット2〜5のとき、当該RSUパケットに含まれるダイジェストを取り出す。ダイジェスト保持部1151cに保持される公開鍵証明書のダイジェストと取得したダイジェストの比較し、一致するか否か判定する(S44)。両者が一致する場合(S44のY)、MAC検証部1151dは当該RSUパケットの検証成功と判断し、受信処理部161に対して承認を通知する(S45)。両者が一致しない場合(S44のN)、MAC検証部1151dは送信先の基地局装置20の特定ができないと判断し、受信処理部161に対して不定を通知する(S47)。ステップS42において、MAC検証が失敗(否認)すると(S42のN)、MAC検証部1151dは受信処理部161に対して否認を通知する(S46)。ステップS47、S45またはS46のいずれかによって、受信処理部161に対する検証結果の通知によってMAC検証の処理が終了する。なお、検証結果の通知にあわせて、RSUパケットに含まれるアプリケーションデータは受信処理部161に提供される。なお、不定とは認証処理の結果が確定していない状態を指す。受信処理部161は、認証が不定のパケットに含まれるデータを、予め設定された規則にしたがい処理する。たとえば、認証されるまでそのデータに対する処理を停止していてもよいし、未認証である旨のフラグを立てて通知部162に渡してもよいし、メッセージに含まれる情報の重要度に応じて両者を使い分けしてもよい。通知部162は未認証である旨のフラグが立っている情報を受領した場合、未認証の情報であることをユーザに認識させる態様で、その情報をユーザに通知することができる。
安全性を高めるために、基地局装置20の受信圏にいる場合であっても、予め定めた期間毎にRSU検証を行うようにしている。具体的には、ECDSA検証部1151bが検証後の時間経過を確認し、ダイジェスト保持部1151cに、ダイジェストが保持されている場合であっても、RSU検証後予め定めた所定の時間を経過したときは、RSU検証を行うことを示した。他に、ダイジェスト保持部1151cに保持されるダイジェストを、一定時間経過後に削除するようにしてもよい。また、両者を併用してもよい。併用する場合は、ECDSA検証部1151bが再度RSU検証を行うまでの経過時間に対して、ダイジェスト保持部1151cからダイジェスト削除するまでの経過を長くする必要がある。
以下では、これまでの認証(以下、「認証1」という)とは別の認証(以下、「認証2」という)を説明する。なお、認証2の説明において認証1の説明と重複する部分については、適宜説明を省略する。
図26は、端末装置10が送信する車車間通信のパケット信号のセキュリティレイヤのフレームフォーマットの詳細な構成例を示す。車車間通信では、大きなパケット信号が送信できないこと、報知されるパケット信号の総数が多いこと、情報の精度が路車間送信のパケット信号に含まれる情報より低いことなどから、公開鍵暗号方式は使用せず、共通鍵暗号方式によるMAC(Message Authentication Code)を使用して、パケット信号に含まれる情報の完全性を認証する。このデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ID」、「送信元機器ID」、「乱数」、「データ長」が配置され、その後にペイロードとして「機器管理コード」、「アプリケーションデータ」が配置され、最後にセキュリティフッダとして「MAC」が配置される。ここで、「」は、セキュリティフレームを構成するフィールドを表している。
「機器管理コード」は、端末装置10の稼働状態を他の端末装置10および基地局装置20に通知するための状態コードをセットする。「APPデータ」には、アプリケーションデータがセットされる。「MAC」は、メッセージタイプ(AT)が、認証付きデータ形式(=1)または認証付き暗号化データ形式(=2)の場合に、MACの値がセットされる。
図27は、基地局装置20が送信する路車間通信パケット信号のセキュリティレイヤのフレームの詳細な構成例を示す。図27(a)は、図3のRSUパケット1のセキュリティフレームであり、図27(b)は、図3のRSUパケット2〜5のセキュリティフレームである。つまり、RSU期間の先頭のRSUパケットのセキュリティフレームは図27(a)に従い、同一のRSU期間にて送信される残りのRSUパケットのセキュリティフレームは図27(b)に従う。
図27(a)のデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ID」、「送信元機器ID」、「乱数」、「データ長」、「公開鍵証明書」、「メッセージID」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」が配置され、その後にペイロードとして「機器管理情報」と「APPデータ」が配置され、最後にセキュリティフッダとして「電子署名」と「MAC」が配置される。「バージョン」、「メッセージ形式」、「鍵ID」、「送信元機器ID」、「乱数」、「APPデータ」および「MAC」については、図26のデータ構造のそれと同じなので説明を割愛する。但し、このデータ構造はMAC認証と署名認証に両対応するので、MAC Flag=1、SIG Flag=1となる。
「データ長」は、「公開鍵証明書」、「フレーム番号」、「メッセージID」、「最終フレーム番号」、「フレーム認証リスト」、「機器管理」、「APPデータ」および「電子署名」の総バイト数がセットされる。「公開鍵証明書」、「フレーム番号」、「メッセージID」、「最終フレーム番号」、「フレーム認証リスト」、「機器管理」、「APPデータ」および「電子署名」を1つのフィールドとしてとらえると、図26のセキュリティフレームと同一のデータ構造となる。
「メッセージID」は、基地局装置20が送信する毎に付ける送信固有の番号であり、1つのスーパーフレームで送信される全てRSUパケットに同じ値がセットされる。例えば、送信毎にインクリメントするカウント値である。
「機器管理」は、基地局装置20から任意の端末装置10に異常や指示を通知、データの提供を行うためのフィールドであり、「機器管理コード」、「対象機器ID」、「パラメータ長」、「パラメータ」が配置される。「機器管理コード」は、端末装置10への通知、データ提供を表すコードがセットされる。このコードは図26の「機器管理コード」にセットされるコードと同じ体系化にあり、状態通知なのかは通知・データ提供なのかはMSBの1ビットで識別されるものとする。すなわち、MSBが0のときは状態通知コードとして図26のセキュリティフレームで使用する。MACが1のときは通知・データ提供コードとして図27(a)のセキュリティフレームで使用する。通知・情報提供コードは、その値によってオプションフィールドを配置する。「パラメータ長」、「パラメータ」がオプションフィールドであり、データ提供時に使用する。「対象機器ID」は、通知あるいは、データ提供を行う端末装置10の機器IDをセットする。不特定に端末装置10に対して通知やデータ提供を行うときは、オール0をセットする。「パラメータ長」は、「パラメータ」のバイト数である。「パラメータ」は、提供するデータをセットする。
「電子署名」は、「メッセージID」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」「認証データリスト」、およびペイロードに対する署名がセットされる。署名は「公開鍵証明書」に含まれる公開鍵と対をなす秘密鍵を用いて生成された署名である。なお、署名対象には「フレーム認証リスト」が含まれるため、このセキュリティフレームのメッセージタイプ(MT)によって、署名の必要性が判断できないので、認証タイプ(AT)=1の時は、「電子署名」に署名をセットする。次いで、メッセージタイプ(MT)が、認証付きデータ形式(=1)、または、認証付き暗号化データ形式(=2)の時は、署名をセットした後、MAC値を求め、「MAC」にセットする。そして、暗号化を行う。この例では、MACの演算対象は「機器ID」、「乱数」、「データ長」、「メッセージID」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」、ペイロードおよび「電子署名」であり、暗号対象は、「メッセージID」、「フレーム番号」、「最終フレーム番号」、「フレーム認証リスト」、「認証データリスト」、ペイロード、「電子署名」および「MAC」である。
図27(b)のデータ構造では、セキュリティヘッダとして「バージョン」、「メッセージ形式」、「鍵ID」、「送信元機器ID」、「乱数」、「データ長」、「ダイジェスト」、「フレーム番号」、「最終フレーム番号」が配置され、その後にペイロードとして「APPデータ」が配置され、最後にセキュリティフッダとして「MAC」が配置される。「バージョン」、「メッセージ形式」、「鍵ID」、「送信元機器ID」、「乱数」、「メッセージID」、「フレーム番号」、「最終フレーム番号」と「APPデータ」および「MAC」については、図27(a)のデータ構造のそれと同じなので説明を割愛する。
図3に従う基地局装置20が送信したRSUパケットのセキュリティフレームの場合、「最終フレーム番号」は、4をセットされる。RSUパケット2の「フレーム番号」は、1をセットされる。同様にRSUパケット3、RSUパケット4、RSUパケット5の「フレーム番号」は、それぞれ1、2、3、4がセットされる。「データ長」は、「ダイジェスト」、「メッセージID」、「フレーム番号」、「最終フレーム番号」、ペイロードおよび「電子署名」の総バイト数がセットされる。「ダイジェスト」、「メッセージID」、「フレーム番号」、「最終フレーム番号」およびペイロードを1つのフィールドとしてとらえると、図26のセキュリティフレームと同一のデータ構造となる。
「ダイジェスト」は、送信元の基地局装置20に固有の公開鍵に対する公開鍵証明書のダイジェストがセットされる。ここではダイジェストとして公開鍵証明書のボディ、すなわち、公開鍵証明書の署名の対象部に対するハッシュ値、例えば、SHA−224、SHA−225によって求められた値、あるいはその一部を当てるとするが、公開鍵証明書に含まれる署名、署名の一部、公開鍵または/かつ機器IDをダイジェストとして代用してもよい。さらに、ダイジェストとして機器IDを代用とする場合、「送信元機器ID」にセットされている機器IDと同一で値であれば「ダイジェスト」を省略してもよい。この例では、MACの演算対象は「機器ID」、「乱数」、「データ長」、「ダイジェスト」、「メッセージID」、「フレーム番号」、「最終フレーム番号」およびペイロードであり、暗号対象は、「メッセージID」、「フレーム番号」、「最終フレーム番号」、「ダイジェスト」、ペイロードおよび「MAC」である。
なお、1つの基地局装置20が複数の路車通信期間を使用する場合、後続のRSU期間に送信されるRSUパケットのセキュリティフレームを、全て図27(b)としてもよい。この場合、基地局装置20からスーパーフレームに送信されるRSUパケットのうち、先頭のRSUパケットのセキュリティフレームが図27(a)に、残りのRSUパケットのセキュリティフレームがすべて図27(b)に従う。
また、図4においてセキュリティフレームが、RSUパケットに収まるように説明したが、基地局装置20が複数のアプリケーションデータを連結して送信する場合、アプリケーションデータ単位で、セキュリティフレームを構成するようにしてもよい。この場合、基地局装置20からスーパーフレームに送信されるアプリケーションデータのうち、先頭に送信されるアプリケーションデータが、図27(a)に従ったセキュリティフレームの「APPデータ」にセットされ、残りのアプリケーションデータが、図27(b)に従った異なるセキュリティフレームの「APPデータ」にセットされる。この後、パケット単に分割され、RSUパケットとして送信される。
図18は、「フレーム認証リスト」にセットする、認証データのリストの構成例を示す。後続するセキュリティフレームのMAC値をフレーム番号順に並べたリストである。サイズは、(認証データのバイト数)×(総フレーム数−1)となる。セットされるMAC値は、図27(b)における「MAC」にセットされるMAC値と同じである。なお、MAC値でなく、ハッシュ値のリストとしてもよい。この場合、ハッシュ演算の対象は、「メッセージID」「フレーム番号」、「最終フレーム番号」およびペイロードである。
説明の便宜上、すべての基地局装置20は、図3に従ったRSUパケット送信するものとする。また、RSUパケット1のセキュリティフレームの公開鍵証明書の検証および署名検証処理を、単に署名検証と呼び、RSUパケット1〜5のセキュリティフレームに対するMAC認証処理を、MAC認証と呼ぶ。受信したRSUパケットのセキュリティフレームのメッセージタイプ(MT)が認証付き暗号化データ形式(=2)のとき、復号後に、署名検証およびMAC検証は実行される。
図28は、検証部1151構成例を示す。構成例に係る検証部1151は、ハッシュ演算部1151a、ECDSA検証部1151b、RSU検証情報保持部1151f、MAC検証部1151d、検証制御部1151eを含む。
RUS検証結果の格納について説明する。RSUパケットを受信すると、検証制御部1151eは、RSU検証情報保持部1151fに保持されているRSU検証情報に含まれるダイジェストと、当該RSUパケットの公開鍵証明書のダイジェストの一致を確認する。当該RSUパケットの公開鍵証明書のダイジェストとは、RSUパケット1のとき、当該RSUパケットに含まれる公開鍵証明書を入力として、ハッシュ演算部1151aで算出したハッシュ値である。また、RSUパケット2〜5のとき、当該パケットの「ダイジェスト」にセットされているダイジェストである。RSU検証情報保持部1151fに一致するダイジェストが保持されていると、検証制御部1151eは当該ダイジェストを含むRSU検証情報から、検証結果とメッセージIDを取得する。そして、当該RSUパケットの検証結果として、MAC検証結果と取得した検証結果とメッセージIDを受信処理部161に通知する。
このようにMAC検証の結果と、直前に行った同じ基地局装置20から送信されたRSUパケットのRSU検証結果とそのRSUパケットの識別情報であるメッセージIDを、RSUパケットの検証結果として通知することで、MAC検証終了後に検証結果を出力できるようになり車車間通信のパケットの検証結果とほぼ同等の遅延にて検証結果を提供できる。データの活用の有無は受信処理部161にて判断する。なお、車車間通信のパケットの検証は、MAC値の一致の確認のみであるため説明は詳細な省略する。
図29は、構成例に係る検証部1151が用いられる端末装置10のRSUパケットの受信処理を示すフローチャートである。RF部12はRSUパケットを受信する。このRSUパケットは変復調部13、MACフレーム処理部14を経て、セキュリティ処理部15に出力される。セキュリティ処理部15の検証部1151がRSUパケットを受け取ると処理が開始される。検証制御部1151eはRSUパケットを受け取るとMAC検証部1151dにMAC検証を開始するように指示する(S110)。そして受け取ったRSUパケットのフレーム番号を確認する(S111)。フレーム番号が0の場合(S111のY)、ハッシュ演算部1151aに当該RSUパケットに配置された公開鍵証明書のダイジェストの演算を指示する。指示を受けたハッシュ演算部1151aは公開鍵証明書のダイジェストを演算して求める(S112)。検証制御部1151eは、ハッシュ演算部1151aが演算して求めた公開鍵証明書のダイジェストと、RSU検証情報保持部1151fに保持される公開鍵証明書のダイジェストとを比較し、一致するか否か判定する(S113)。
ダイジェストが一致しない、または、ダイジェストが一致して検証結果がデータ否認またはRSU否認の場合(S113のN)、検証制御部1151eはECDSA検証部1151bの動作状態をチェックする(S117)。ECDSA検証部1151bが待機中の場合(S117のY)、検証制御部1151eはECDSA検証部1151bに当該RSUパケットのRSU認証の開始を指示し(S114)、当該RSUパケットに対する処理を終了する。一方、ECDSA検証部1151bが稼働中の場合(S117のN)、検証制御部1151eはして受信されたRSUパケットのRSU検証を断念し、当該RSUパケットに対する処理を終了する。
ダイジェストが一致し、かつ、検証結果がRSU承認の場合(S113のY)、検証制御部1151eは当該ダイジェストを含むRSU検証情報がRSU検証情報保持部1151fに保持されてからの経過時間を確認する(S116)。これはRSU検証が成功してからの経過時間を確認することになる。予め定めた所定の時間を経過している場合(S116のY)、当該RSUパケットのRSU検証を試みるためステップS14に移行する。ステップS111にてフレーム番号が0以外の場合(S111のN)、RSU検証は必要ないと判断し、当該RSUパケットに対する処理を終了する。予め定めた所定の時間を経過していない場合(S116のN)、処理は終了される。
図30は、ECDSA検証部1151bにおけるRSUパケットのRSU検証処理を示すフローチャートである。RSUパケット1を対象とする。ECDSA検証部1151bは検証制御部1151eからRSUパケットのRSU認証開始の指示を受けると、ECDSA検証部動作状態を稼働中に変更する(S130)。そして、記憶部1153に格納されている認証鍵を取得して当該RSUパケットに含まれる公開証明書の検証を行う(S131)。当該検証が成功した場合(S131のY)、当該公開鍵証明書に含まれる公開鍵を用いて、当該RSUパケットに含まれる署名の検証を行う(S132)。当該検証が成功した場合(S132のY)、RSU検証結果をRSU承認としたRSU検証情報によって、RSU検証情報保持部1151fに格納されているRUS検証情報に上書きする(S133)。このとき経過時間はリセットされる。当該RSUパケットに含まれる署名検証が失敗した場合(S132のN)、RSU検証結果をデータ否認としたRSU検証情報によって、RSU検証情報保持部1151fに格納されているRUS検証情報に上書きする(S134)。またはステップS131にて当該RSUパケットに含まれる公開鍵証明書の検証が失敗した場(S131のN)、RSU検証結果をRSU否認としたRSU検証情報によって、RSU検証情報保持部1151fに格納されているRUS検証情報に上書きする(S135)。ステップS133、ステップ134またはステップS135が終了すると、ECDSA検証部動作状態を待機中に変更して(S136)、RSU検証の処理を終了する。
図31は、MAC検証部1151dにおけるRSUパケットのMAC検証処理を示すフローチャートである。MAC検証部1151dは検証制御部1151eからRSUパケットのMAC認証開始の指示を受けると、当該RSUパケットの鍵IDにしたがって記憶部1153に格納されている通信鍵を取得する(S140)。MAC検証部1151dは取得した通信鍵を用いて当該RSUパケットのMACの演算対象に対するMAC値を演算する(S141)。そして、演算によって得たMAC値と、当該RSUパケットに含まれるMAC値を比較する(S142)。2つのMAC値が一致する場合(S142のY)、当該RSUパケットがRSUパケット1のとき、ハッシュ演算部1151aから当該RSUパケットに含まれる公開鍵証明書のダイジェストを取得する。当該RSUパケットがRSUパケット2〜5のとき、当該RSUパケットに含まれるダイジェストを取り出す。RSU検証情報保持部1151fに保持される公開鍵証明書のダイジェストと取得したダイジェストの比較し、一致するか否か判定する(S143)。
両者が一致する場合(S143のY)、MAC検証部1151dは当該RSUパケットのMAC検証結果(承認)とRSU検証情報保持部1151fに保持されるRSU検証結果とメッセージIDを受信処理部161に対して通知する(S144)。両者が一致しない場合(S143のN)、当該RSUパケットのMAC検証結果(承認)とRSU検証否認を受信処理部161に対して通知する(S145)。ステップS142において、MAC検証が失敗(否認)すると(S142のN)、公開鍵証明書のダイジェストが一致すれば(S146のY)、MAC検証部1151dは当該RSUパケットのMAC検証結果(否認)とRSU検証情報保持部1151fに保持されるRSU検証結果とメッセージIDを受信処理部161に対して通知する(S147)。
両者が一致しない場合(S146のN)、当該RSUパケットのMAC検証結果(否認)とRSU検証否認を受信処理部161に対して通知する(S148)。ステップS144、S145、S147またはS148のいずれかによって、受信処理部161に対して検証結果が通知されるとMAC検証の処理が終了する。なお、検証結果の通知にあわせて、RSUパケットに含まれるアプリケーションデータは受信処理部161に提供される。受信処理部161は、2つの検証結果に基づいて、受け取ったアプリケーションデータを、予め設定された規則にしたがい処理する。たとえば、双方が認証された場合のみアプリケーションデータを採用してもよいし、2つの検証結果にうち、1つが承認で他方が否認または不定のとき、未認証である旨のフラグを立てて通知部162に渡してもよいし、メッセージに含まれる情報の重要度に応じて両者を使い分けしてもよい。
通知部162は未認証である旨のフラグが立っている情報を受領した場合、未認証の情報であることをユーザに認識させる態様で、その情報をユーザに通知することができる。なお、機器管理情報は重要データ扱いであることが望ましい。この場合、受信処理部161は危機管理情報を取り出したRSUパケットのメッセージIDと機器管理情報とMAC検証結果を保持し、後続のRSUパケットに対するアプリケーションデータとともに提供されるRSU認証結果とメッセージデータを手確認して保持している機器管理情報を採用するかどうかを決定する。2つのメッセージIDが一致して、RSU認証が承認のとき危機管理情報を採用する。メッセージIDが一致してRSU認証が承認でないとき、および、保持するメッセージIDを受け取ったメッセージIDを追い越したとき、保持している機器管理情報は破棄される。このようにすることで、重要なデータは、RSU認証によって承認されたRSUパケットらのみ取り出せるようにすることができる。
以上で説明した認証1は、次のようにまとめられてもよい。
(1)路側機(RSU)の送信エリアに達した車載器がエリアに到達したとき署名検証(公開鍵証明書とフレームへの署名検証、以下、RUS認証と呼ぶ)を行い、その後MAC検証(以下、フレーム認証と呼ぶ)のみに切り換える。
(2)通信エリアへの到達は、RSU認証済みのRSUの公開鍵証明書のダイジェスト(公開鍵証明書のボディのハッシュ値またはその一部、あるいは、公開鍵証明書の公開鍵またはその一部、証明書の識別番号、付与対象の識別情報(機器ID)等)の一致。
(3)RSU認証済み路側機のダイジェスト確認とMAC検証結果をもって、フレームを承認する。
(4)RUS認証の有効時間を設定し、一定期間毎に再認証を行う。再認証処理の期間は先のRSU認証の結果を持ってMAC検証結果は正当とする。
(1)路側機(RSU)の送信エリアに達した車載器がエリアに到達したとき署名検証(公開鍵証明書とフレームへの署名検証、以下、RUS認証と呼ぶ)を行い、その後MAC検証(以下、フレーム認証と呼ぶ)のみに切り換える。
(2)通信エリアへの到達は、RSU認証済みのRSUの公開鍵証明書のダイジェスト(公開鍵証明書のボディのハッシュ値またはその一部、あるいは、公開鍵証明書の公開鍵またはその一部、証明書の識別番号、付与対象の識別情報(機器ID)等)の一致。
(3)RSU認証済み路側機のダイジェスト確認とMAC検証結果をもって、フレームを承認する。
(4)RUS認証の有効時間を設定し、一定期間毎に再認証を行う。再認証処理の期間は先のRSU認証の結果を持ってMAC検証結果は正当とする。
また、認証2は、次のようにまとめられてもよい。
(1)MAC検証を随時行う。
(2)RSUから送信されるフレームとRSU認証済みRSUの公開鍵証明書のダイジェストが一致する場合、MAC検証結果に付加して通知する。
(3)RSU認証によって承認された路側機のダイジェスト情報を保持する。RUS認証は、定期的に更新する。
(1)MAC検証を随時行う。
(2)RSUから送信されるフレームとRSU認証済みRSUの公開鍵証明書のダイジェストが一致する場合、MAC検証結果に付加して通知する。
(3)RSU認証によって承認された路側機のダイジェスト情報を保持する。RUS認証は、定期的に更新する。
以下では、これまで説明した処理をレイヤとの関連で説明する。図32(a)は、基地局装置20において、図32(b)は端末装置10において規定されるレイヤの構成を示す。図32(a)の基地局装置20における送信処理のレイヤ構成を説明する。アプリケーションレイヤは、データ生成部26またはネットワーク通信部27に含まれる。具体的には、基地局装置20の記憶部(図示なし)に事前に保持されている道路線形情報やセンサ設置情報、基地局装置20と併設された信号機の灯消情報、あるいは基地局装置20の周辺に設置されたセンサによって検知された車両や人の位置や移動などを示すセンサ情報など基地局装置20から発信されるアプリケーションデータに対応するアプリケーションレイヤはデータ生成部26に含まれる。工事情報、落下物情報、渋滞情報あるいは緊急車両などの交通管制センタからネットワークを介してお供されるアプリケーションデータに対応するアプリケーションレイヤはネットワーク通信部27に含まれる。分離処理層、パケット管理層、セキュリティ管理層は、図20のセキュリティ処理部25に含まれ、無線送信層は、図20のRF部22、変復調部23、MACフレーム処理部24に含まれる。
図32(b)の端末装置10における受信処理のレイヤ構成を説明する。アプリケーションレイヤは、図20の受信処理部161に含まれ、分離処理層、パケット管理層、セキュリティ管理層は、図20のセキュリティ処理部15に含まれ、無線受信層は、図20のRF部12、変復調部13、MACフレーム処理部14に含まれる。
アプリケーションレイヤには、1種類あるいは複数種類アプリケーションによって構成される。ここでは、3種類のアプリケーションAPP1、APP2およびAPP3によって構成され、それぞれがアプリケーションデータD1、D2、およびD3を提供するものとする。分割処理層には、送信対象となるアプリケーションデータがアプリケーションレイヤより入力される。図33(a)−(e)は、基地局装置20における送信処理の各レイヤにおける処理の概要を示す。なお、横軸は時間を示す。図33(a)は、分割処理層に入力されるアプリケーションデータを示す。分割処理層は、複数のアプリケーションから入力されたアプリケーションデータを送信順序に並べ、それぞれのアプリケーションデータのサイズと下位の各層、特にセキュリティ管理層によって付加されるヘッダあるいはフッダといた付加データのサイズを考慮して、それを送信可能なサイズに分割する。図33(b)は、分割処理層によって分割されたデータの系列を示す。例えば、D1は、D1(i)とD2(ii)に分割される。分割されたデータのそれぞれには、ELヘッダが付加される。図32に戻る。ELヘッダは、受信時に分割されたアプリケーションデータを再構成するための結合情報が含まれている。分割処理層は、分割したデータをパケット管理層に出力する。
パケット管理層は、分割されたデータのうち、先頭に現在の日時を送信日時として付加する。送信日時はリプレイス攻撃対策として付加する。図33(c)は、パケット管理層によって、送信日時が付加されたデータの系列を示す。図32に戻る。パケット管理層は、送信日時が付加されたデータをセキュリティ管理層に出力する。セキュリティ管理層は、送信日時が付加されたデータに対してセキュリティ処理を実行する。図33(d)は、セキュリティ処理がなされたデータを示す。例えば、MACヘッダ、公開鍵証明書、HASHリスト、署名、MAC、ダイジェストが、データに付加される。これは、図17(a)−(b)に対応する。なお、HASHリストは、図17(a)におけるフレーム認証リストに相当する。HASHリストは、データ単位に生成されるので、D1(i)、D1(ii)等のそれぞれに対して生成されたハッシュ値を含む。図32に戻る。セキュリティ管理層は、セキュリティ処理がなされたデータをパケット管理層に出力し、パケット管理層は、これを無線送信層に出力する。無線送信層は、各データをパケット信号に格納し、パケット信号を報知する。図33(e)は、パケット信号を示す。ここで、SL1、SL2等は、前述の路車送信期間を示し、P1、P2等は、パケット信号を示す。
端末装置10の受信処理は、図33における処理を(e)から(b)に逆順で進み、ELヘッダを参照してアプリケーションデータD1、D2およびD3を再構成して、それぞれを対応するアプリケーションAPP1、APP2およびAPP3に出力する。
(実施例3)
次に、本発明の実施例3を説明する。実施例3は、データを分割する状況下において、セキュリティ処理を簡易にすることを目的とする。これまでは、データを分割してからHASHリストを生成していた。前述のごとく、HASHリストのサイズは、分割されたデータの数に依存する。つまり、当該サイズは、可変値であり、固定値ではない。そのため、HASHリストのサイズが大きくなることによって、ひとつのパケット信号に格納できなくなった場合に、さらにデータを分割し、HASHリストが再度作成される。このような処理を簡易にするために、実施例3に係る基地局装置は、データを分割する前にHASHリストを生成し、HASHリストが付加されたデータを分割する。データの数は入力時に認識されるので、HASHリストのサイズは、その時点で固定される。その結果、分割処理においてHASHリストのサイズは、固定値と見なされるので、処理が簡易になる。実施例3に係る通信システム500は、図1と同様のタイプであり、基地局装置20は、図20と同様のタイプであり、端末装置10は、図21と同様のタイプである。以下では、差異を中心に説明する。
次に、本発明の実施例3を説明する。実施例3は、データを分割する状況下において、セキュリティ処理を簡易にすることを目的とする。これまでは、データを分割してからHASHリストを生成していた。前述のごとく、HASHリストのサイズは、分割されたデータの数に依存する。つまり、当該サイズは、可変値であり、固定値ではない。そのため、HASHリストのサイズが大きくなることによって、ひとつのパケット信号に格納できなくなった場合に、さらにデータを分割し、HASHリストが再度作成される。このような処理を簡易にするために、実施例3に係る基地局装置は、データを分割する前にHASHリストを生成し、HASHリストが付加されたデータを分割する。データの数は入力時に認識されるので、HASHリストのサイズは、その時点で固定される。その結果、分割処理においてHASHリストのサイズは、固定値と見なされるので、処理が簡易になる。実施例3に係る通信システム500は、図1と同様のタイプであり、基地局装置20は、図20と同様のタイプであり、端末装置10は、図21と同様のタイプである。以下では、差異を中心に説明する。
図20において、セキュリティ処理部15は、複数種類のアプリケーションデータを入力する。セキュリティ処理部15は、複数種類のアプリケーションデータのそれぞれに対して、公開鍵暗号方式を使用することによって導出した各データの代表値が含まれたリストを生成する。ここでは、アプリケーションデータ毎にハッシュ関数を適用することによって、ハッシュ値が生成される。さらに、セキュリティ処理部25は、複数のアプリケーションデータのそれぞれに対するハッシュ値をまとめることによってHASHリストを生成する。この段階において、HASHリストは固定値となる。セキュリティ処理部25は、HASHリストと、複数種類のアプリケーションデータとを複数に分割する。その際、先頭のアプリケーションデータの前段にHASHリストが付加される。また、分割はアプリケーションプログラム単位になされる。さらに、MACフレーム処理部24は、分割結果のそれぞれをパケット信号に格納することによって、複数のパケット信号を生成する。変復調部23、RF部22は、複数のパケット信号を報知する。
図34(a)は、本発明の実施例3に係る基地局装置20において、図34(b)は端末装置10において規定されるレイヤの構成を示す。図32と同様に、ここでも、基地局装置20における送信処理のレイヤ構成を説明する。アプリケーションレイヤは、データ生成部26またはネットワーク通信部27に含まれる。拡張層、パケット管理層、上位セキュリティ管理層、下位セキュリティ管理層は、図20のセキュリティ処理部25に含まれ、無線送信層は、図20のRF部22、変復調部23、MACフレーム処理部24に含まれる。図34(b)の端末装置10における受信処理のレイヤ構成を説明する。アプリケーションレイヤは、図20の受信処理部161に含まれ、分離処理層、パケット管理層、セキュリティ管理層は、図20のセキュリティ処理部15に含まれ、無線受信層は、図20のRF部12、変復調部13、MACフレーム処理部14に含まれる。
図35(a)−(f)は、基地局装置20における送信処理の各レイヤにおける処理の概要を示す。図35(a)は、分割処理層に入力されるアプリケーションデータを示し、これは図33(a)と同一である。図35に戻る。拡張層は、入力したアプリケーションデータのうち、先頭に送信日時を付加する。図35(b)は、送信日時が付加されたアプリケーションデータの系列を示す。図34に戻る。拡張層は、送信日時が付加されたアプリケーションデータを上位セキュリティ管理層に出力する。
上位セキュリティ管理層は、送信日時が付加されたアプリケーションデータに対してセキュリティ処理を実行する。図35(c)は、セキュリティ処理がなされたデータを示す。例えば、公開鍵証明書、HASHリスト、署名、ダイジェストが、アプリケーションデータに付加される。図34に戻る。上位セキュリティ管理層は、セキュリティ処理がなされたアプリケーションデータを拡張層に出力する。
拡張層は、セキュリティ処理がなされたアプリケーションデータのサイズに応じて、それを分割する。図35(d)は、拡張層によって分割されたデータの系列を示す。図33(b)と同様に、D1は、D1(i)とD2(ii)に分割される。分割されたデータのそれぞれには、ELヘッダが付加される。図34に戻る。拡張層は、分割したデータをパケット管理層に出力し、パケット管理層は、これを下位セキュリティ管理層に出力する。
下位セキュリティ管理層は、分割されたデータに対してセキュリティ処理を実行する。図35(e)は、セキュリティ処理がなされたデータを示す。例えば、MACヘッダ、MACがデータに付加される。図34に戻る。下位セキュリティ管理層は、セキュリティ処理がなされたデータをパケット管理層に出力し、パケット管理層は、これを無線送信層に出力する。無線送信層は、各データをパケット信号に格納し、パケット信号を報知する。図35(f)は、パケット信号を示しており、これは、図33(e)と同一である。端末装置10の受信処理は、図35における処理を(e)から(b)に逆順で進み、ELヘッダを参照してアプリケーションデータD1、D2およびD3を再構成して、それぞれを対応するアプリケーションAPP1、APP2およびAPP3に出力する。
(実施例4)
これまでの実施例3に係る基地局装置20は、HASHリストと先頭のデータとを同一のパケット信号に格納しているが、これらを別のパケット信号に含めてもよい。つまり、セキュリティ処理部25は、複数種類のデータが含まれていないパケット信号にHASHリストを含める。そのため、データが含まれたパケット信号と、HASHリストが含まれたパケット信号とが別に生成される。図36(a)−(f)は、各レイヤにおける別の処理の概要を示す。これらは、図35(a)−(f)と同様に示されているので、差異のみを説明する。図36(c)は、セキュリティ処理がなされたデータを示す。ここで、HASHリストは、D1に連結されずに、別々に構成されている。
これまでの実施例3に係る基地局装置20は、HASHリストと先頭のデータとを同一のパケット信号に格納しているが、これらを別のパケット信号に含めてもよい。つまり、セキュリティ処理部25は、複数種類のデータが含まれていないパケット信号にHASHリストを含める。そのため、データが含まれたパケット信号と、HASHリストが含まれたパケット信号とが別に生成される。図36(a)−(f)は、各レイヤにおける別の処理の概要を示す。これらは、図35(a)−(f)と同様に示されているので、差異のみを説明する。図36(c)は、セキュリティ処理がなされたデータを示す。ここで、HASHリストは、D1に連結されずに、別々に構成されている。
図37(a)−(b)は、本発明の実施例4に係る路車間通信パケット信号に含まれるセキュリティフレームのデータ構造の一例を示す。図37(a)は、図35(c)における先頭のデータのフォーマットを示し、図37(b)は、図35(c)における2番目移行のデータのフォーマットを示す。ここで、図37(a)のMAC方式ペイロードと、図37(b)の署名方式ペイロードとが、署名・ハッシュ演算の対象になる。
図38は、本発明の実施例4に係る路車間通信パケット信号に含まれるセキュリティフレームのデータ構造の別の一例を示す。これは、図35(e)におけるデータのフォーマットを示す。ここで、MAC方式ペイロードがMACの対象であり、Nonce、ペイロード長、MAC方式ペイロードが暗号化の対象である。
本発明の実施例によれば、データを分割する前にHASHリストを生成するので、分割処理において、HASHリストを固定量のデータとして扱うことができる。また、HASHリストが固定量のデータとして扱われることによって、処理を簡易にできる。また、データが含まれたパケット信号とは別に、HASHリストが含まれたパケット信号を生成するので、HASHリストとは関係なく、データが含まれたパケット信号を生成できる。
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
本発明の一態様の概要は、次の通りである。本発明のある態様の通信装置は、複数の共通鍵が含まれた部分共通鍵テーブルを複数結合することによって形成されるべき共通鍵テーブルを管理する管理部と、管理部において管理されている共通鍵テーブルのうち、いずれかの共通鍵を使用することによって、データに対するセキュリティ処理を実行する処理部と、処理部においてセキュリティ処理がなされたデータを送信あるいは受信する通信部とを備える。管理部は、共通鍵テーブルに新たな部分共通鍵テーブルを追加することによって、共通鍵テーブルを更新する。
この態様によると、共通鍵テーブルをまとめて更新するのではなく、部分共通鍵テーブルを追加するように更新するので、部分共通鍵テーブルの個別性が高められ、一部の部分共通鍵テーブルが漏洩した場合であっても、共通鍵テーブルの全体が漏洩する可能性を低減できる。
管理部において管理される共通鍵テーブルを形成するために結合可能な部分共通テーブル数が定められており、管理部は、結合可能な部分共通鍵テーブル数に達するまで、共通鍵テーブルの更新のために、新たな部分共通鍵テーブルを追加し、結合可能な部分共通鍵テーブル数に達してから、共通鍵テーブルの更新のために、共通鍵テーブルに既に含まれた部分共通鍵テーブルを新たな部分共通鍵テーブルによって置き換えてもよい。この場合、共通鍵テーブルのサイズを超えるまでは、部分共通鍵テーブルを追加し、共通鍵テーブルのサイズに達すると、部分共通鍵テーブルを置き換えるので、共通鍵テーブルのサイズを制限できる。
本発明の別の態様もまた、通信装置である。この装置は、共通鍵暗号方式によるセキュリティ処理がなされたデータを受信する受信部と、共通鍵暗号方式における共通鍵を管理する管理部と、管理部において管理されている共通鍵のうち、受信部において受信したデータに対して使用された共通鍵によって、セキュリティ処理の受信処理を実行する処理部とを備える。管理部は、受信部において受信したデータに対して使用された共通鍵を未管理である場合、その旨を通知する。
この態様によると、共通鍵を記憶していない場合、その旨を運転者に通知するので、共通鍵の更新を運転者に促すことができる。
管理部は、受信部において受信したデータに対して使用された共通鍵を未管理である場合、共通鍵の更新を要求してもよい。この場合、共通鍵を記憶していない場合、共通鍵の更新を要求するので、新たな共通鍵を使用可能にできる。
管理部は、複数の共通鍵が含まれた部分共通鍵テーブルを複数結合することによって形成されるべき共通鍵テーブルを管理しており、共通鍵テーブルに新たな部分共通鍵テーブルを追加することによって、共通鍵テーブルを更新してもよい。
本発明のさらに別の態様は、端末装置である。この装置は、発信元固有の公開鍵証明書と公開鍵証明書に含まれる公開鍵で検証可能な署名と共通鍵暗号方式によるメッセージ認証子を付加した第1のパケット信号と、発信元固有の公開鍵証明書を特定有する情報と共通鍵暗号方式によるメッセージ認証子を付加した第2のパケット信号と、を受信して、検証を行う端末装置であって、無線装置から報知される複数のパケット信号を受信する受信部と、第1のパケット信号に含まれる署名を検証するための第1検証部と、第1のパケット信号または第2のパケット信号に含まれるメッセージ認証子を検証するための第2検証部と、第1検証部で検証された第1のパケット信号に含まれる公開鍵証明書のダイジェストを保持するダイジェスト保持部と、を備える。第1検証部は、第1のパケット信号を受信すると受信したパケット信号に含まれる公開鍵証明書と署名の検証とを行い、検証が成功すると該公開鍵証明書のダイジェストをダイジェスト保持部に保持させ、第2検証部は、第1のパケット信号または第2のパケット信号を受信すると受信したパケット信号に含まれるメッセージ認証子の検証を行い、受信したパケット信号に含まれる公開鍵証明書のダイジェストがダイジェスト保持部に保持され、かつ、検証に成功したとき、該パケット信号は正当であると通知する。
本発明のさらに別の態様もまた、端末装置である。この装置は、発信元固有の公開鍵証明書と公開鍵証明書に含まれる公開鍵で検証可能な署名と共通鍵暗号方式によるメッセージ認証子を付加した第1のパケット信号と、発信元固有の公開鍵証明書のダイジェストと共通鍵暗号方式によるメッセージ認証子を付加した第2のパケット信号と、を受信して、検証を行う端末装置であって、無線装置から報知される複数のパケット信号を受信する受信部と、第1のパケット信号に含まれる署名を検証するための第1検証部と、第1のパケット信号または第2のパケット信号に含まれるメッセージ認証子を検証するための第2検証部と、第1検証部で検証された第1のパケット信号に関する検証結果を保持する検証情報保持部と、を備える。第1検証部は、第1のパケット信号を受信すると受信したパケット信号に含まれる公開鍵証明書と署名の検証とを行い、少なくとも検証結果と該公開鍵証明書のダイジェストとを含む検証情報によって、検証情報保持される検証情報を更新し、第2検証部は、第1のパケット信号または第2のパケット信号を受信すると受信したパケット信号に含まれるメッセージ認証子の検証を行い、受信したパケット信号に含まれる公開鍵証明書のダイジェストに対応する検証情報が検証情報保持部に保持されるとき、メッセージ認証子の検証結果と共に検証情報保持部に保持される第1検証部における検証結果を添付して通知する。
本発明のさらに別の態様は、通信装置である。この装置は、複数種類のアプリケーションデータを受け取って、受け取ったアプリケーションデータの1つと発信元固有の公開鍵証明書と公開鍵証明書に含まれる公開鍵で検証可能な署名と共通鍵暗号方式によるメッセージ認証子を含む第1のメッセージと、受け取ったアプリケーションデータの1つと発信元固有の公開鍵証明書を特定有する情報と共通鍵暗号方式によるメッセージ認証子を含む第2のメッセージと、を送信する通信装置であって、第1のメッセージおよび1つ以上の第2のメッセージを1つのグループとして送信し、第1のメッセージは、1つのグループに属する第1のメッセージおよび1つ以上の第2のメッセージにそれぞれ含まれるアプリケーションデータに対するハッシュあるいはメッセージ認証子の認証用リストを含み、署名は認証用リストに対する署名であり、第1のメッセージのメッセージ認証子は、当該メッセージに含まれる公開鍵証明書とは認証用リストと署名とアプリケーションデータに対するものであり、第2のメッセージのメッセージ認証子は、当該メッセージに含まれる公開鍵証明書の特定情報とアプリケーションデータに対するものである。
第1のメッセージに含まれる公開鍵証明書とは認証用リストと署名とアプリケーションデータとメッセージ認証子を暗号化して、送信してもよい。
第2のメッセージの一部あるいは全てに対して、当該メッセージに含まれる公開鍵証明書の特定情報とアプリケーションデータとメッセージ認証子が暗号化して、送信してもよい。
第1のメッセージおよび第2のメッセージを、1つ以上のパケット信号にパケット信号へ分割して、送信してもよい。
認証用リストを含むパケット信号には、アプリケーションデータを含まない。
本発明のさらに別の態様もまた、通信装置である。この装置は、複数種類のデータを入力する入力部と、入力部において入力した複数種類のデータのそれぞれに対して導出した各データの代表値が含まれたリストを生成する生成部と、生成部において生成したリストと、入力部において入力した複数種類のデータとを複数のパケット信号へ分割する分割部と、分割部において分割した複数のパケット信号を報知する報知部と、を備える。
分割部は、複数種類のデータが含まれていないパケット信号にリストを含めてもよい。
10 端末装置、 11 アンテナ、 12 RF部、 13 変復調部、 14 MACフレーム処理部、 15 セキュリティ処理部、 17 データ生成部、 18 記憶部、 19 制御部、 20 基地局装置、 21 アンテナ、 22 RF部、 23 変復調部、 24 MACフレーム処理部、 25 セキュリティ処理部、 26 データ生成部、 27 ネットワーク通信部、 28 記憶部、 29 制御部、 100 車両、 151 暗復号部、 152 復号部、 153 鍵更新部、 161 受信処理部、 162 通知部、 200 外部ネットワーク、 202 エリア、 204 エリア外、 251 暗復号部、 252 暗号部、 253 鍵更新部、 500 通信システム。
本発明によれば、共通鍵暗号化方式を用いた通信システムのセキュリティを効率的に向上させることができる。
Claims (3)
- 複数の共通鍵が含まれた部分共通鍵テーブルを複数結合することによって形成されるべき共通鍵テーブルを管理する管理部と、
前記管理部において管理されている共通鍵テーブルのうち、いずれかの共通鍵を使用することによって、データに対するセキュリティ処理を実行する処理部と、
前記処理部においてセキュリティ処理がなされたデータを送信あるいは受信する通信部とを備え、
前記管理部は、共通鍵テーブルに新たな部分共通鍵テーブルを追加することによって、共通鍵テーブルを更新することを特徴とする通信装置。 - 前記管理部において管理される共通鍵テーブルを形成するために結合可能な部分共通テーブル数が定められており、
前記管理部は、結合可能な部分共通鍵テーブル数に達するまで、共通鍵テーブルの更新のために、新たな部分共通鍵テーブルを追加し、結合可能な部分共通鍵テーブル数に達してから、共通鍵テーブルの更新のために、共通鍵テーブルに既に含まれた部分共通鍵テーブルを新たな部分共通鍵テーブルによって置き換えることを特徴とする請求項1に記載の通信装置。 - 各部分共通鍵テーブルにはバージョン情報が割り当てられており、
前記管理部は、共通鍵テーブルに既に含まれた部分共通鍵テーブルのうち、一番古いバージョンの部分共通鍵テーブルを新たな部分共通鍵テーブルによって置き換えることを特徴とする請求項2に記載の通信装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013528917A JP5431623B2 (ja) | 2011-08-18 | 2012-08-10 | 通信装置 |
Applications Claiming Priority (8)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011179124 | 2011-08-18 | ||
JP2011179124 | 2011-08-18 | ||
JP2011205356 | 2011-09-20 | ||
JP2011205356 | 2011-09-20 | ||
JP2011213423 | 2011-09-28 | ||
JP2011213423 | 2011-09-28 | ||
PCT/JP2012/005114 WO2013024587A1 (ja) | 2011-08-18 | 2012-08-10 | 通信装置 |
JP2013528917A JP5431623B2 (ja) | 2011-08-18 | 2012-08-10 | 通信装置 |
Related Child Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013163290A Division JP5384768B1 (ja) | 2011-08-18 | 2013-08-06 | 通信装置 |
JP2013163289A Division JP5384767B1 (ja) | 2011-08-18 | 2013-08-06 | 通信装置 |
JP2013214093A Division JP5437528B1 (ja) | 2011-08-18 | 2013-10-11 | 通信装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP5431623B2 true JP5431623B2 (ja) | 2014-03-05 |
JPWO2013024587A1 JPWO2013024587A1 (ja) | 2015-03-05 |
Family
ID=47714924
Family Applications (6)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013528917A Active JP5431623B2 (ja) | 2011-08-18 | 2012-08-10 | 通信装置 |
JP2013163290A Active JP5384768B1 (ja) | 2011-08-18 | 2013-08-06 | 通信装置 |
JP2013163289A Active JP5384767B1 (ja) | 2011-08-18 | 2013-08-06 | 通信装置 |
JP2013214093A Active JP5437528B1 (ja) | 2011-08-18 | 2013-10-11 | 通信装置 |
JP2013256240A Active JP5884063B2 (ja) | 2011-08-18 | 2013-12-11 | 通信装置 |
JP2015202004A Active JP6112467B2 (ja) | 2011-08-18 | 2015-10-13 | 通信装置 |
Family Applications After (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013163290A Active JP5384768B1 (ja) | 2011-08-18 | 2013-08-06 | 通信装置 |
JP2013163289A Active JP5384767B1 (ja) | 2011-08-18 | 2013-08-06 | 通信装置 |
JP2013214093A Active JP5437528B1 (ja) | 2011-08-18 | 2013-10-11 | 通信装置 |
JP2013256240A Active JP5884063B2 (ja) | 2011-08-18 | 2013-12-11 | 通信装置 |
JP2015202004A Active JP6112467B2 (ja) | 2011-08-18 | 2015-10-13 | 通信装置 |
Country Status (2)
Country | Link |
---|---|
JP (6) | JP5431623B2 (ja) |
WO (1) | WO2013024587A1 (ja) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013024587A1 (ja) * | 2011-08-18 | 2013-02-21 | 三洋電機株式会社 | 通信装置 |
JP6335570B2 (ja) * | 2013-03-29 | 2018-05-30 | パナソニック株式会社 | 無線装置 |
JP2015050586A (ja) * | 2013-08-30 | 2015-03-16 | パナソニック株式会社 | 車載器 |
CN106164878B (zh) * | 2014-03-31 | 2020-02-14 | 飞力凯网路股份有限公司 | 信息处理装置、信息处理方法和程序 |
US20200412718A1 (en) * | 2018-03-20 | 2020-12-31 | Mitsubishi Electric Corporation | Monitoring and control system |
JP2021071413A (ja) * | 2019-10-31 | 2021-05-06 | 日本電気株式会社 | 衛星測位システム、地上受信機及び位置算出方法 |
US20220158843A1 (en) * | 2020-11-13 | 2022-05-19 | Ford Global Technologies, Llc | Diagnostic over ip authentication |
Family Cites Families (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3822997B2 (ja) * | 1998-03-19 | 2006-09-20 | 株式会社日立製作所 | 放送情報配信システム |
JP3688918B2 (ja) * | 1998-12-25 | 2005-08-31 | 株式会社東芝 | 放送受信装置 |
JP4637406B2 (ja) * | 2001-06-11 | 2011-02-23 | パナソニック株式会社 | フローティングカーデータ収集方法と、それを実施する装置 |
JP2004311000A (ja) * | 2003-03-24 | 2004-11-04 | Matsushita Electric Ind Co Ltd | 記録装置及び著作権保護システム |
JP4333351B2 (ja) * | 2003-12-05 | 2009-09-16 | 株式会社デンソー | 通信システム |
JP4619858B2 (ja) * | 2004-09-30 | 2011-01-26 | 株式会社日立製作所 | 分散環境における暗号鍵更新方法、暗号鍵更新システム、暗号鍵更新システムを構成する無線基地局 |
JP2006129080A (ja) * | 2004-10-28 | 2006-05-18 | Canon Inc | データ処理装置及びその方法 |
JP4959152B2 (ja) * | 2005-06-20 | 2012-06-20 | Kddi株式会社 | 認証システムおよび同システムにおける認証情報委譲方法 |
JP4680730B2 (ja) * | 2005-09-21 | 2011-05-11 | 株式会社トヨタIt開発センター | 路車間通信システム、車載端末、及び路車間通信方法 |
JP2008060809A (ja) * | 2006-08-30 | 2008-03-13 | Toyota Infotechnology Center Co Ltd | 車車間通信方法、車車間通信システムおよび車載通信装置 |
JP4869845B2 (ja) * | 2006-09-14 | 2012-02-08 | Kddi株式会社 | デジタル放送用コンテンツ配信装置、デジタル放送用コンテンツ認証システム、デジタル放送用コンテンツ認証方法およびプログラム |
JP4938409B2 (ja) * | 2006-10-13 | 2012-05-23 | Kddi株式会社 | デジタル放送用コンテンツ配信装置、デジタル放送用コンテンツ認証システム、デジタル放送用コンテンツ認証方法およびプログラム |
JP4540681B2 (ja) * | 2007-01-22 | 2010-09-08 | 株式会社日立製作所 | 通信セキュリティ保持方法及びその実施装置並びにその処理プログラム |
JP4861261B2 (ja) * | 2007-06-28 | 2012-01-25 | 株式会社東海理化電機製作所 | 車車間通信システム |
JP4930306B2 (ja) * | 2007-09-25 | 2012-05-16 | 株式会社デンソー | 車載通信装置 |
JP2009212850A (ja) * | 2008-03-04 | 2009-09-17 | Panasonic Electric Works Co Ltd | 暗号通信システム |
FR2936677A1 (fr) * | 2008-09-26 | 2010-04-02 | France Telecom | Distribution d'une fonction d'authentification dans un reseau mobile |
JP5548419B2 (ja) * | 2009-09-30 | 2014-07-16 | 富士通株式会社 | 署名生成装置、署名検証装置、署名生成方法、署名検証方法、署名生成プログラム、および署名検証プログラム |
JP4905578B2 (ja) * | 2010-04-22 | 2012-03-28 | 株式会社デンソー | 通信システム,送信機,受信機,送受信機 |
JP4905577B2 (ja) * | 2010-04-22 | 2012-03-28 | 株式会社デンソー | 通信システム,送信機,受信機,送受信機 |
JP5587239B2 (ja) * | 2011-04-19 | 2014-09-10 | 株式会社日立製作所 | 車車/路車間通信システム |
WO2013024587A1 (ja) * | 2011-08-18 | 2013-02-21 | 三洋電機株式会社 | 通信装置 |
JP2013256240A (ja) * | 2012-06-13 | 2013-12-26 | Napolex Co | 自動車用携帯機器ホルダ |
-
2012
- 2012-08-10 WO PCT/JP2012/005114 patent/WO2013024587A1/ja active Application Filing
- 2012-08-10 JP JP2013528917A patent/JP5431623B2/ja active Active
-
2013
- 2013-08-06 JP JP2013163290A patent/JP5384768B1/ja active Active
- 2013-08-06 JP JP2013163289A patent/JP5384767B1/ja active Active
- 2013-10-11 JP JP2013214093A patent/JP5437528B1/ja active Active
- 2013-12-11 JP JP2013256240A patent/JP5884063B2/ja active Active
-
2015
- 2015-10-13 JP JP2015202004A patent/JP6112467B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2014053923A (ja) | 2014-03-20 |
JP5384768B1 (ja) | 2014-01-08 |
JP6112467B2 (ja) | 2017-04-12 |
JP2014003650A (ja) | 2014-01-09 |
JPWO2013024587A1 (ja) | 2015-03-05 |
JP2014003651A (ja) | 2014-01-09 |
JP5437528B1 (ja) | 2014-03-12 |
JP2014096811A (ja) | 2014-05-22 |
WO2013024587A1 (ja) | 2013-02-21 |
JP5884063B2 (ja) | 2016-03-15 |
JP5384767B1 (ja) | 2014-01-08 |
JP2016054488A (ja) | 2016-04-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6112467B2 (ja) | 通信装置 | |
JP5362925B2 (ja) | 路側機および車載器 | |
JP6195260B2 (ja) | 処理装置 | |
JP6799563B2 (ja) | 受信装置、受信方法 | |
JP5991561B2 (ja) | 無線装置 | |
JP5895214B2 (ja) | 無線装置 | |
JP2014158105A (ja) | 端末装置 | |
JP6187888B2 (ja) | 処理装置 | |
JP5991560B2 (ja) | 無線装置 | |
JP5903629B2 (ja) | 無線装置 | |
JP2014158104A (ja) | 端末装置 | |
JP6183629B2 (ja) | 処理装置 | |
JP2015050586A (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: 20131105 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20131204 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5431623 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |