JP5967822B2 - 車載通信システム及び装置 - Google Patents

Description

本発明は、車載通信システムに関し、例えば公開鍵暗号を用いた車載通信システムに適用可能な技術に関する。

近年、交通事故死者数削減を目指し、安全運転の支援を目的とした路車間／車車間通信の検討が進められている。路車間とは、路側機と車両との間を、車車間とは、車両と車両との間をいう。安全運転の支援に関わるサービスでは、一つの誤ったメッセージから大事故につながる可能性が高いため、正しい路側機又は車両に搭載された機器（車載器）が送ったメッセージであること、及び、正しい路側機又は車載器が送ったメッセージが、悪意ある者によって、改ざんされていないことを確認すること、すなわちメッセージの真正性／完全性を確保することが重要である。

メッセージの真正性／完全性を保証する仕組みとして、公開鍵暗号を用いた電子署名がある。公開鍵暗号は、秘密鍵と公開鍵という対になる二つの鍵を用いて暗号／復号化を行う方式である。秘密鍵は秘密に管理する必要があるが、公開鍵は公開してよいという特徴がある。したがって、公開鍵暗号を用いた電子署名では、メッセージを送信者がメッセージのハッシュ値（メッセージダイジェスト）を秘密鍵で暗号化し、署名を生成する。そして、メッセージ送信者はメッセージとともに署名を送信する。メッセージ受信者は、送信者の公開鍵を入手し、受信したところの署名を復号する。復号した値（ハッシュ値）と、受信したメッセージから生成したハッシュ値が等しいか否かで署名の検証を行う。

公開鍵暗号を用いた電子署名においては、公開鍵の正当性検証が問題となる。一般的には、認証局が公開鍵証明書を発行する。公開鍵証明書は、公開鍵と公開鍵の所有者情報などを結びつける証明書であり、証明書には署名がつけられている。証明書の署名生成に使う鍵は認証局の秘密鍵である。メッセージ受信者はメッセージ送信者の公開鍵証明書と認証局の公開鍵を入手し、公開鍵証明書の検証と署名検証とを行うことで公開鍵の正当性を検証する。この場合、認証局の公開鍵の正当性検証が問題になる。そこで、認証局の公開鍵にも公開鍵証明書を発行する。この公開鍵証明書には認証局自身の秘密鍵で生成した署名が付与される。認証局が階層構造になっている場合は、上位の認証局が下位の認証局の公開鍵証明書を発行する。

したがって、メッセージの署名を検証する際には、各認証局の公開鍵証明書に対しての検証、メッセージ送信者の公開鍵証明書に対する検証を行った後、メッセージの署名を検証する。すなわち、メッセージの署名を検証するためには、複数回の公開鍵証明書検証と署名検証が発生する。公開鍵証明書の検証においては、その証明書が有効期限内であるか、公開鍵証明書が改ざんされていないか（認証局の公開鍵によって公開鍵証明書の署名検証に成功するか）、その証明書が失効されていないか等が確認される。例えば、有効期限を過ぎていた場合、又は認証局の公開鍵を用いて署名検証に失敗した場合には、公開鍵証明書の検証において失敗したということになる。

それぞれの公開鍵証明書検証と署名検証とを実施するためには、比較的長い時間がかかる。一方、安全運転の支援を目的としたサービスでは、即応性が要求され、検証と署名検証に対して高速な処理が求められる。公開鍵証明書検証と署名検証に掛かる時間の短縮化を図るための技術として次の述べる特許文献に記載されたものがある。

特許文献１では、路車間通信において、公開鍵証明書検証に成功した認証局の公開鍵証明書が車載器に保存される。同じ認証局の公開鍵証明書を受信している間は、認証局の公開鍵証明書に対しての検証が省略され、メッセージ送信者（路側機）の公開鍵証明書に対する検証及びメッセージの署名の検証を行う。

特許文献２では、車車間通信において、メッセージ受信者が、メッセージ送信者の公開鍵証明書の検証に成功した場合、受信した公開鍵を、受信時刻、位置情報とともにメモリに保存する。同じ公開鍵を受信した場合、メッセージ送信者の公開鍵証明書の検証を省略する。保存した情報のうち、現在時刻が受信時刻から一定時間経過している公開鍵、又は現在位置が受信した位置情報から離れている場合は、登録した情報を削除する。

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

特許文献１及び２では、検証に成功した公開鍵証明書が保持される。しかしながら、検証に失敗した公開鍵証明書は保持されない。そのため、例えば不正な公開鍵を保持している機器（車載器又は路側機）からメッセージが頻繁に送信された場合、受信する度に検証を行い、処理に時間がかかるという課題がある。

その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

一実施の形態によれば、それに添付された公開鍵証明書の検証において失敗した機器の情報がメモリ（保持回路）に保持され、メッセージを受信したとき、当該メッセージに含まれている機器の情報が、保持されている機器の情報と一致するかの確認を実施し、一致する場合、公開鍵証明書の検証を実施しない。

前記一実施の形態によれば、先の検証で失敗した公開鍵証明書については、検証を実施しないので、処理時間が長くなることを防ぐことが可能となる。

車載器と路側機との関係を説明するための図である。 実施の形態に係わる車両に搭載される装置の構成を示すブロック図である。 認証局の構成を示す図である。 実施の形態に係わる車載器に保持されるデータの構造を示す図である。 実施の形態に係わる車載器に保持される認証局に関するデータの構造を示す図である。 実施の形態に係わるメッセージの構造を示す図である。 実施の形態に係わる車載器が、メッセージを受信した際の処理フローを示す図である。 実施の形態に係わる車載器が、認証局の公開鍵証明書を検証する際の処理フローを示す図である。 実施の形態に係わる車載器が、公開鍵証明書を処理する際のフローを示す図である。 実施の形態に係わる車載器が、認証局の公開鍵証明書を処理する際のフローを示す図である。 実施の形態に係わる車載器が、機器の公開鍵証明書を処理する際のフローを示す図である。 実施の形態に係わる車載通信システムのブロック図である。

≪実施の形態の概要≫
以下の説明において、同じ機能を果たす部分には、同じ記号が付されている。説明が省略されている部分については、同じ記号が付されている部分の説明を参照して頂きたい。

まず、図１２を用いて、実施の形態の概要を説明する。同図には、メッセージＭを受信し、受信したメッセージＭを処理する装置１２０１が示されている。同図において、符号１２４０は、他の装置からのメッセージを受信して、メッセージＭに含まれている情報を処理する処理ユニットである。また、符号１２３０は、メッセージＭに含まれている公開鍵証明書の検証を効率化するために設けられた検証失敗テーブルである。検証失敗テーブル１２３０は、情報を管理するためにメモリ（保持回路）に形成される。処理ユニット１２４０は、メッセージＭに含まれている公開鍵証明書の検証処理を行うユニット（同図では、“公開鍵証明書の検証処理”と記載している。）１２１０とメッセージＭに含まれているアプリケーションデータを用いた処理を実施するユニット（同図では、“アプリケーション実行”と記載している。）１２２０とを有する。処理ユニット１２４０は、図示しないマイクロプロセッサ（マイクロコンピュータ、ＣＰＵともいう。）と図示しないメモリとを有しており、メモリに格納されたプログラムをマイクロプロセッサが実行することにより、これらの機能（公開鍵証明書の検証処理と、アプリケーション実行）が実現される。図１２においては、図面が煩雑になるのを避けるために、「ユニット」と言う記載は省略されており、例えばアプリケーション実行のユニット１２２０は、アプリケーション実行１２２０として示されている。あとで図６を用いて説明するが、メッセージＭに含まれている公開鍵証明書には、メッセージＭを発信したもの（メッセージ発信者）の機器を特定する機器情報が含まれている。

検証失敗テーブル１２３０には、公開鍵証明書の検証において失敗した機器情報が格納されている。公開鍵証明書の検証処理１２１０では、受信したメッセージＭに含まれている機器情報と検証失敗テーブル１２３０に格納されている機器情報とを比較する。比較により、一致が確認された場合、公開鍵証明書の検証処理１２１０では、例えば、メッセージＭに含まれている認証局の公開鍵を用いた公開鍵証明書の署名検証を実行しない。これにより、次のメッセージを受信して、処理することが可能となる。言い換えるならば、メッセージの署名検証に掛かる時間が増加することを防ぐことが可能となる。

特に制限されないが、この実施の形態では、公開鍵証明書の検証において成功した機器の情報（機器情報）が、検証成功テーブル１２５０に格納される。検証成功テーブル１２５０は情報を格納するためにメモリ（保持回路）に形成される。受信したメッセージＭに含まれている機器情報と、検証成功テーブル１２５０に格納されている機器情報との比較が、公開鍵証明書の検証処理１２１０で実施される。検証成功テーブル１２５０に格納されている機器情報と、メッセージＭの機器情報とが一致した場合、受信したメッセージＭに含まれているアプリケーションデータを用いた処理が、アプリケーション実行１２２０において実行される。

受信したメッセージＭに含まれている機器情報が、検証失敗テーブル１２３０及び検証成功テーブル１２５０のそれぞれに格納されている機器情報と一致しなかった場合、公開鍵証明書の検証が行われる。公開鍵証明書の検証において失敗した場合には、検証失敗テーブル１２３０に格納されている機器情報の更新が可能となる様に、機器情報が検証失敗テーブル１２３０に供給出来る様にされている。一方、公開鍵証明書の検証において成功した場合には、検証成功テーブル１２５０に格納されている機器情報の更新が可能となる様に、機器情報が検証成功テーブル１２５０に供給出来る様にされている。これにより、検証失敗テーブル１２３０及び検証成功テーブル１２５０の更新が可能となる。更新は、例えば、時間的に経過している機器情報を、時間的に新しい機器情報によって書き換えることにより実施される。これにより、検証失敗テーブル１２３０及び検証成功テーブル１２５０を形成するところのメモリに容量の制限がある場合も、メモリを効率的に活用することが可能となる。

≪実施の形態≫
図１には、車両間及び車両と路側機間の通信システムの構成が示されている。通信システム１００は、建物又は道路に設置される路側機（装置）１０１と車両に搭載される車載器（装置）１０２とを有している。路側機１０1は、車載器１０２との間で無線通信を行う装置である。この路側機１０１は、屋外に設置されていても良いし屋内に設置されていても良いし、道路に設置されていても良い。例えば、信号機や給油スタンドなどの装置に搭載されていても良い。図１において、各路側機１０１の通信可能な範囲は、破線で示している様に重なり合っていないが、勿論、重なり合ってもよい。一つの車載器１０２は、路側機１０１及び他の車載器１０２と無線通信を行う。車載器１０２は、車両以外の装置に搭載しても良いが、以下に述べる実施の形態では、車両に搭載された例を説明する。この無線通信により、車載器１０２を搭載した車両は、他の車載器からの通信により他の車両の状況を把握することが可能となり、路側機１０１からの通信により混雑状況等（）を把握することが可能となる。

図２には、車両に搭載される装置が示されており、特にメッセージの送信及び受信とセキュリティ処理を実施する車載器１０２の機能構成がブロック図で示されている。図１に示した複数の車載器１０２のそれぞれが、図２の構成を有しても良いし、１つの車載器１０２が図２の構成を有しても良い。

図２に示されている各機能は、マイクロコンピュータ（以下ＣＰＵとも称する）１０３、メモリ、通信装置、ＧＰＳ装置等で実現される。この場合、メモリに格納されたプログラムをＣＰＵ１０３が実行することにより、ＣＰＵ１０３が各機能を達成する。勿論、各機能は、別々の回路で達成する様にしても良い。本明細書においては、機能をユニットと称し、各機能が、ＣＰＵ１０３によりプログラムを実行することにより達成される場合も、個別の回路で達成される場合も含むものと理解されたい。例えば、後で説明する通信制御処理ユニット２１０は、通信装置により、その機能が達成される。また、署名生成／検証処理ユニット２２０、及び公開鍵証明書の検証結果の登録判定処理ユニット（以下、「登録判定処理ユニット」ともいう。）２３０のそれぞれは、ＣＰＵ１０３、及びそれを動作させるプログラム及びデータを格納した第１メモリ（図示せず）により達成される。同様に、走行情報取得処理ユニット２４０、時刻情報取得処理ユニット２５０のそれぞれは、ＧＰＳ装置１０５、ＣＰＵ１０３、及びそれを動作させるプログラム及びデータを格納した第１メモリにより達成される。公開鍵証明書の検証結果情報記憶ユニット（以下、「検証結果情報記憶ユニット」ともいう。）２６０、セキュリティ情報記憶ユニット２７０及び走行情報記憶ユニット２８０のそれぞれは、第２メモリ１０４により達成される。ＣＰＵ１０３は、１個のマイクロコンピュータではなく、複数のマイクロコンピュータでも良い。また、上記第２メモリ１０２についても、１個のメモリではなく、複数のメモリで有っても良い。前述した様に、各ユニットの機能は、ＣＰＵ１０３が記憶装置（図示しない第１メモリ）に格納されたプログラムを実行することにより、実現されるが、プログラムは、予め記憶装置（第１メモリ）に格納されていても良いし、必要に応じて、記憶媒体から、又は、通信を介して他の装置から導入される様にしてもよい。

前述した様に、車載器１０２は、通信制御処理ユニット２１０、署名生成／検証処理ユニット２２０、登録判定処理ユニット２３０、走行情報取得処理ユニット２４０、及び時刻情報取得処理ユニット２５０を有する。また、車載器１０２は、検証結果情報記憶ユニット２６０、セキュリティ情報記憶ユニット２７０、及び走行情報記憶ユニット２８０を有する。ここで、通信制御処理ユニット２１０、署名生成／検証処理ユニット２２０、登録判定処理ユニット２３０、走行情報取得処理ユニット２４０、及び時刻情報取得処理ユニット２５０は、それぞれ処理ユニット２１０，２２０，２３０，２４０，２５０ともいう。検証結果情報記憶ユニット２６０、セキュリティ情報記憶ユニット２７０、及び走行情報記憶ユニット２８０は、それぞれ記憶ユニット２６０，２７０，２８０ともいう。

通信制御処理ユニット２１０は、路側機１０１や他の車両に搭載された車載器１０２との間で通信するための処理を行う。署名生成／検証処理ユニット２２０は、路側機１０１又は他の車両に搭載された車載器１０２へ送信するメッセージの署名生成を実施する。また、署名生成／検証処理ユニット２２０は、通信制御処理ユニット２１０を介して、路側機１０１又は他の車載器１０２から受信したメッセージの署名の検証処理、及びメッセージ送信者と認証局の公開鍵証明書の検証処理を実施する。ここで、メッセージ送信者とは、路側機１０１及び他の車載器１０２をいう。

登録判定処理ユニット２３０は、署名生成／検証処理ユニット２２０で検証処理した公開鍵証明書の検証結果を車載器１０２が保持しておくか否かを判定し、保持する場合は検証結果情報記憶ユニット２６０に検証結果の情報を登録する。

走行情報取得処理ユニット２４０は、例えばＧＰＳ装置１０５を用いて、車載器１０２を搭載したところの車両の進行方向、現在位置、速度など走行に関する情報を取得する。時刻情報取得処理ユニット２５０は現在の時刻を取得する。

検証結果情報記憶ユニット２６０は、路側機１０１、他の車載器１０２、及び認証局の公開鍵証明書の検証結果と、登録判定に関するポリシーとを記憶する。同図では、検証結果情報記憶ユニット２６０は、検証成功機器テーブル２６１、検証失敗機器テーブル２６２、検証成功認証局テーブル２６３、検証失敗認証局テーブル２６４、及び設定情報２６５を有する。検証成功機器テーブル２６１は、公開鍵証明書の検証において成功した路側機又は車載器の情報を登録するテーブルである。検証失敗機器テーブル２６２は、公開鍵証明書の検証において失敗した路側機又は車載器の情報を登録するテーブルである。検証成功認証局テーブル２６３は、公開鍵証明書の検証に成功した認証局の情報を登録するテーブルである。検証失敗機器テーブル２６４は、公開鍵証明書の検証に失敗した認証局の情報を登録するテーブルである。設定情報２６５は、上記各テーブルに登録できる情報の最大数、登録判定に用いる各種閾値が設定されるテーブルである。検証成功機器テーブル２６１、検証失敗機器テーブル２６２、検証成功認証局テーブル２６３、及び検証失敗認証局テーブル２６４の詳細は、後で図４及び図５を用いて後述する。

セキュリティ情報記憶ユニット２７０は、この車載器１０２自身のセキュリティ情報を記憶するユニットである。セキュリティ情報記憶ユニット２７０には、公開鍵ペア２７２、公開鍵証明書２７１、及び認証局の公開鍵証明書２７３が格納される。公開鍵ペア２７２は、署名生成用の秘密鍵と署名検証用の公開鍵である。公開鍵はメッセージとともに、他の車両の車載器又は路側機へ送信され、このメッセージを受信した者（メッセージ受信者）が、受信したメッセージの署名検証に用いる。ここで、メッセージ受信者とは、他の車両に搭載された車載器又は路側機をいう。公開鍵証明書２７１は、メッセージ受信者が、受信した公開鍵を検証するためのものであり、認証局が発行する。公開鍵証明書２７１は、公開鍵証明書を識別する識別子（以下、ＩＤ：ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）、公開鍵、公開鍵所有者を識別する機器ＩＤ（メッセージの送信者の機器を識別するための識別子であり、本明細書では機器情報とも称する）、証明書を発行する認証局を識別する認証局ＩＤ、証明書の有効期限、証明書の署名方式、及び署名で構成される。

当該署名は認証局の秘密鍵を用いて生成され、メッセージ受信者は認証局の公開鍵を用いて、メッセージ送信者の公開鍵証明書を検証する。認証局の公開鍵証明書２７３は、公開鍵証明書を検証する公開鍵を検証するためのものである。

認証局は複数存在し、図３に示すように、階層構造でもよい。すなわち、上位認証局としてルート（ｒｏｏｔ）認証局３０１、その下位に複数の中間認証局３０２、更にその下位に複数の下位認証局３０３が設けられる様にしてもよい。この様な階層構造を取った場合、ルート認証局３０１が中間認証局３０２の公開鍵証明書を発行し、中間認証局３０２が下位認証局３０３の公開鍵証明書を発行する。ルート認証局３０１は自己の秘密鍵で署名した自己の公開鍵証明書を発行する。したがって、認証局が階層構造の場合は、認証局の公開鍵証明書２７３は複数存在する。勿論、上述した様な階層構造を取らなくても良いことは言うまでもない。

図２に戻り、走行情報記憶ユニット２８０は、走行情報取得処理ユニット２４０で取得した情報を記憶する。前述した検証結果記憶ユニット２６０、セキュリティ情報記憶ユニット２７０及び走行情報記憶ユニット２８０は、データの集合体であり、複数又は１つのメモリ（保持回路）に記憶（格納）される。このメモリは、同図では破線１０４で例示されている。

図４の（ａ）及び（ｂ）には、データの集合体である検証成功機器テーブル２６１と検証失敗機器テーブル２６２のデータ構造が示されている。図４の（ａ）に示されている検証成功機器テーブル２６１は、車載器１０２の検証結果情報記憶ユニット２６０に保持される。検証成功機器テーブル２６１には、署名生成／検証処理ユニット２２０が公開鍵証明書の正当性検証を実施した際に、正当性において成功した路側機１０１又は他の車載器１０２の情報が登録される。登録される情報（データ）は、メッセージ送信者の機器ＩＤ（同図では“機器ＩＤ”と記載されている。）４１１、検証結果有効時刻４１２及び公開鍵４１３を有する。機器ＩＤ４１１は、公開鍵証明書の正当性検証において、成功した路側機１０１又は車載器１０２を指す識別子である。検証結果有効時刻４１２は、公開鍵証明書の正当性検証において成功の機器として扱う時刻の期限を示す。公開鍵４１３は、公開鍵証明書の正当性検証に成功した路側機１０１又は車載器１０２の公開鍵を示す。同図では、機器ＩＤ４１１の例として、ＯＢＵ＿Ａ、ＯＢＵ＿Ｂ、ＲＳＵ＿Ａ・・・が示されている。公開鍵４１３の例として、ＫｏｂｕＣ、ＫｏｂｕＤ、ＫｒｓｕＣ・・・が示されている。また、検証結果有効時刻４１２の例として、２０１１／１１／１１／２７ １０：１０：１０．１００等が示されている。

図４の（ｂ）に示されている検証失敗機器テーブル２６２は、車載器１０２の検証結果情報記憶ユニット２６０に保持される。この検証失敗機器テーブル２６２には、署名生成／検証処理ユニット２２０が公開鍵証明書の正当性検証を実施した際に、公開鍵証明書の正当性検証に失敗した路側機１０１又は車載器１０２の情報が登録される。登録される情報は、機器ＩＤ４２１、公開鍵４２２、公開鍵証明書の署名（以下、「署名」ともいう。）４２３、検証結果有効時刻４２４を有する。機器ＩＤ４２１は、公開鍵証明書の正当性検証において失敗した路側機１０１又は車載器１０２の識別子である。公開鍵４２２は正当性検証において失敗した路側機１０１又は車載器１０２の公開鍵である。署名４２３は正当性検証において失敗した路側機１０１又は車載器１０２の公開鍵証明書にある署名である。検証結果有効時刻４２４は検証失敗の機器として扱う時刻の期限を示す。図４（ａ）と同様に、図４（ｂ）においては、ＯＢＵ＿Ｃ、ＯＢＵ＿Ｄ、ＲＳＵ＿Ｃ・・・が機器ＩＤ４２１の例として示されている。ＫｏｂｕＣ、ＫｏｂｕＤ、ＫｒｓｕＣ・・・が公開鍵４２２の例として示されている。また、公開鍵証明書の署名４２３は、例として、ＳｏｂｕＣ、ＳｏｂｕＤ、ＳｒｓｕＣ・・・が示されている。検証結果有効時刻４２４の例として、２０１１／１１／２７ １０：１０：１０．１００等が示されている。

図５の（ａ）及び（ｂ）には、データの集合体である検証成功認証局テーブル２６３と検証失敗認証局テーブル２６４のデータ構造が示されている。図５の（ａ）に示されている検証成功認証局テーブル２６３は、車載器１０２の検証結果情報記憶ユニット２６０に保持される。検証成功認証局テーブル２６３には、署名生成／検証処理ユニット２２０が公開鍵証明書の正当性検証を実施した際に、正当性検証において成功した認証局の情報が登録される。検証成功認証局テーブル２６３は、認証局を識別するための認証局ＩＤ５３１と、その認証局の公開鍵５３３と、検証結果有効時刻５３２を有する。認証局ＩＤ５３１は、公開鍵証明書の正当性検証において成功した認証局の識別子である。検証結果有効時刻５３２は正当性検証に成功した認証局として扱う時刻の期限を示す。

図５（ｂ）は、車載器１０２の検証結果情報記憶ユニット２６０が保持する検証失敗認証局テーブル２６４のデータ構成を示す図である。検証失敗認証局テーブル２６４には、署名生成／検証処理ユニット２２０が公開鍵証明書の正当性検証を実施した際に、公開鍵証明書の正当性検証において失敗した認証局の情報が登録される。検証失敗認証局テーブル２６４には、認証局ＩＤ５４１、公開鍵５４２、公開鍵証明書の署名（以下、「署名」ともいう。）５４３、検証結果有効時刻５４４を有する。認証局ＩＤ５４１は、公開鍵証明書の正当性検証において失敗した認証局の識別子である。公開鍵５４２は認証局ＩＤ５４１で指定される認証局の公開鍵である。署名５４３は認証局ＩＤ５４１で指定される認証局の公開鍵証明書にある署名である。検証結果有効時刻５４４は検証失敗の認証局として扱う時刻の期限を示す。

図５の（ａ）及び（ｂ）においても、認証局ＩＤ５３１、５４１、公開鍵５３３、５４２、検証結果有効時刻５３２、５４４及び署名５４３の例が示されている。例えば、図５（ａ）及び（ｂ）には、ＣＡ＿Ａ１等が認証局ＩＤ５３１、５４１として示され、ＫｃａＣ１等が公開鍵５３３、５４２として示されている。また、ＳｃａＣ１等が、署名５４３として例示され、２０１１／１１／２７ １０：１０：１０．００等が検証結果有効時刻５３２、５４４として例示されている。

図６は、路側機１０１又は車載器１０２が送信するメッセージのフォーマットの一例を示す。メッセージＭは、メッセージ送信者６１０、メッセージタイプ６２０、走行情報６３０、アプリケーションデータ６４０、セキュリティ情報６５０で構成される。メッセージ送信者６１０はメッセージ送信者の識別子であり、メッセージタイプ６２０はメッセージの種別を識別するものである。走行情報６３０は、メッセージ送信者の走行に関する情報であり、位置情報６３１、速度情報６３２、及び進行方向情報６３３を有する。メッセージ送信者６１０が路側機１０１の場合、走行情報６３０の位置情報６３１は、路側機１０１の設置位置、速度情報６３２は常に０、進行方向情報６３３も０を示す。アプリケーションデータ６４０は、メッセージ送信者がメッセージ受信者に届ける情報である。セキュリティ情報６５０は、メッセージの真正性／完全性を保証するための情報であり、公開鍵証明書６５１、認証局の公開鍵証明書６５２、及び署名６５３を有する。公開鍵証明書６５１はメッセージ送信者の公開鍵証明書であり、認証局の公開鍵証明書６５２は、公開鍵証明書６５１の正当性を検証するための公開鍵の証明書であり、署名６５３はメッセージの真正性／完全性を検証するためのものである。車載器１０２がメッセージ送信者の場合、公開鍵証明書６５１にはセキュリティ情報記憶ユニット２７０（図２）の公開鍵証明書２７１が、認証局の公開鍵証明書６５２にはセキュリティ情報記憶ユニット２７０（図２）の認証局の公開鍵証明書２７３が設定される。署名６５３は、セキュリティ情報記憶ユニット２７０（図２）内の公開鍵ペア２７２の秘密鍵を用いて生成される。

図７には、車載器１０２が図６に示すフォーマットを有するメッセージを受信した場合の、メッセージ認証の処理を示すフローが示されている。この処理は、前記した処理ユニット２２０，２３０，２４０，２５０（図２）が、前記した記憶ユニット２６０，２７０，２８０（図２）を用いながら、図示されていないプログラムを実行することにより達成される。

車載器１０２は、通信制御処理ユニット２１０を介してメッセージを受信すると、図７に示されているメッセージ認証を開始する（同図では“メッセージ認証開始”と記載されている。）。ステップ７１０において、セキュリティ情報６５０（図６）の公開鍵証明書６５１に記載されている（含まれている）機器ＩＤが、検証成功機器テーブル２６１（図２）に存在しているか否かの確認をする。図７では、“受信した機器が検証成功テーブルに登録されている”と記載されている。また、機器ＩＤが、検証成功機器テーブル２６１に存在している場合、機器ＩＤが、検証結果有効時刻内の機器ＩＤ４１１（図４の（ａ））として存在しているか否かの確認が、このステップ７１０において行われる。検証結果有効時刻内かどうかは時刻情報取得処理ユニット２５０から取得した現在の時刻が、検証結果有効時刻４１２より前の時刻であるかどうかで判定する。また、機器ＩＤが検証成功機器テーブル２６１に存在し、メッセージを受信した時刻が、検証結果有効時刻４１２よりも前の時刻である場合、公開鍵証明書６５１に記載されている（含まれている）公開鍵と検証成功機器テーブル２６１に登録されている公開鍵４１３が同じ値であるか否かの確認が、このステップ７１０において行われる。

受信したメッセージに含まれている機器ＩＤが、検証成功機器テーブル２６１に存在し、メッセージを受信した時刻が、検証結果有効時刻４１２よりも前の時刻であり、公開鍵証明書６５１に記載されている（含まれている）公開鍵と検証成功機器テーブル２６１に登録されている公開鍵４１３が同じ値の場合は、メッセージ送信者の公開鍵証明書の検証は成功であると見なす。この場合には、公開鍵証明書の検証に関する処理を省略し、ステップ７２０に進む。ステップ７２０は、署名の検証であり、メッセージの公開鍵証明書６５１に記載された（含まれた）公開鍵を使って、メッセージの署名６５３（図６）を検証し、メッセージ認証を終了する。すなわち、ステップ７２０では、署名を公開鍵で復号して得た値と、メッセージのハッシュ値とを比較し、一致するか否かの確認が実施される。メッセージ認証を終了した後（図７では、“メッセージ認証終了”と記載されている。）は、図７には示されていないが、署名検証結果に応じたメッセージ処理を実施する。署名検証に成功した場合は、このメッセージ処理において、アプリケーション実行１２２０（図１２）においてアプリケーションデータ６４０（図６）の処理が行われる。一方、署名検証に失敗した場合には、このメッセージ処理において、アプリケーション実行１２２０（図１２）においてアプリケーションデータの破棄が行われる。署名検証に失敗した場合のアプリケーションデータの破棄は、前述した様にアプリケーション実行１２２０で行うのではなく、公開鍵証明書の検証処理１２１０で行う様にしても良い。

一方、受信したメッセージに含まれている機器ＩＤが、検証成功機器テーブル２６１に検証結果有効時刻内の機器として存在しない場合、ステップ７３０に進む。ステップ７３０においては、検証失敗機器テーブル２６２（図２）に、検証結果有効時刻内の機器ＩＤ４２１（図４の（ｂ））として機器ＩＤが存在するか否かの確認が行われる。図７では“受信した機器が検証失敗機器テーブルに登録されている”と記載されている。なお、受信したメッセージに含まれている機器ＩＤが、検証成功機器テーブル２６１の機器ＩＤ４１１として存在しない場合、或いは機器ＩＤ４１１として存在していても、検証結果有効時刻内で無い場合もステップ７３０が実行される。

ステップ７３０で、機器ＩＤが検証失敗機器テーブル２６２に検証結果有効時刻内の機器として存在する場合は、次にステップ７４０が実行される。ステップ７４０では、受信したメッセージ内の公開鍵証明書６５１に含まれている公開鍵及び署名が、検証失敗機器テーブル２６２の公開鍵４２２（図４の（ｂ））及び公開鍵証明書の署名４２３（図４の（ｂ））と同じ値か否かを確認される（図７では“公開鍵と公開鍵証明書の署名が登録された値と異なる”と記載されている。）。同じ値の場合は、メッセージ送信者の公開鍵証明書は検証に失敗であるとし、メッセージの署名の検証に失敗と見なして、メッセージ認証を終了する。図７では“メッセージ認証終了”と記載されている。そして、メッセージの署名の検証において失敗した場合の処理を実行する。この場合には、例えば受信したメッセージを破棄する等の処理を実行する。一方、ステップ７４０での確認処理において、値が異なると判断した場合には、次にステップ７５０が実施される。また、ステップ７３０で、機器ＩＤが検証失敗機器テーブル２６２に存在しない場合も、次にステップ７５０が実施される。

この様に、受信したメッセージに含まれている機器ＩＤが、検証成功機器テーブル２６１に検証結果有効時刻内の機器として存在し、受信したメッセージに含まれている公開鍵が検証成功機器テーブル２６１に登録されている公開鍵と同じ場合には、公開鍵証明書の検証を省略してメッセージの認証を実施し、アプリケーションデータを用いた処理を実施することが出来るため、処理の負担低減を図ることが可能となる。また、受信したメッセージに含まれている機器ＩＤが、検証失敗機器テーブル２６２に検証結果有効時刻内の機器として存在する場合には、メッセージ送信者の公開鍵証明書は検証に失敗であると見なして、メッセージ認証を終了する。これにより、処理の負担を低減することが可能となる。

ステップ７５０では、メッセージ送信者及び認証局のそれぞれの公開鍵証明書の検証を実行する。図７では“公開鍵証明書の検証成功”と記載されている。このステップ７５０は、受信したメッセージに含まれている機器ＩＤが、検証成功機器テーブル２６１及び検証失敗機器テーブル２６２のいずれにも該当する機器ＩＤが存在しないため、送信者及び認証局のそれぞれの公開鍵証明書の検証を行うために設けられている。公開鍵証明書の検証の詳細については、図８を用いて後述するので、ここでは省略する。ステップ７５０で、公開鍵証明書の検証において、成功した場合はステップ７６０で、公開鍵証明書６５１（図６）に記載されている公開鍵を用いて、署名６５３（図６）の検証を行い、ステップ７７０へ進む。一方、ステップ７５０で公開鍵証明書の検証において失敗した場合は、メッセージの署名の検証に失敗したとして、ステップ７７０に進む。ステップ７７０では、ステップ７５０の公開鍵証明書の検証結果を、公開鍵証明書の検証結果情報記憶ユニット２６０（図２）に登録するか否かを判定し、判定結果に応じた処理を行う。このステップ７７０については、その詳細を図９から図１１を用いて後述するので、ここでは省略する。

次に図８を用いて、公開鍵証明書の検証について説明する。メッセージ送信者の公開鍵証明書を検証するために、認証局が図３の様に階層構造になっていた場合、ステップ８１０でルート認証局３０１までの認証パスを構築する。図８では“認証パスの構築”と記載されている。すなわち、下位認証局３０３、下位認証局３０３を承認している中間認証局３０２、中間認証局３０２を承認しているルート認証局３０１のパスを見つける。これを実施するために、ステップ８２０からステップ８９０では、認証パスに存在する認証局の下位認証局３０３からルート認証局３０１に向けて、メッセージＭに含まれている認証局の情報が、検証成功認証局テーブル２６３（図２）又は検証失敗認証局テーブル２６４（図２）に登録されているか否かを、順番に確認する。検証成功認証局テーブル２６３又は検証失敗認証局テーブル２６４に、登録されている場合は、登録されている認証局からルート認証局３０１までの公開鍵証明書の検証は、検証成功認証局テーブル２６３又は検証失敗認証局テーブル２６４に登録されている結果を利用する。この様にすることにより、認証局の検証に掛かる処理の負担の低減を図ることが可能となる。検証成功認証局テーブル２６３及び検証失敗認証局テーブル２６４のいずれにも登録されていない場合は、各認証局の公開鍵証明書の検証を実施する。

具体的には、ステップ８２０では、下位認証局３０３から順に確認していくための初期化処理を行っている。すなわち、変数ｉを０に設定し、認証パスに存在する認証局の数を、変数Ｎに設定する処理をステップ８２０で実施する。図８では、“ｉ＜−０ Ｎ＜−認証パスに存在する認証局の数”と記載されている。例えば、認証局の認証をしている認証局を特定し、特定した認証局が自分自身の場合がルート認証局３０１であると判定する。認証局の認証をしているところの認証局を、認証局の公開鍵証明書２７３で特定し、ルート認証局３０１と判定する迄の数を、ルート認証局迄の数Ｎとする。

ステップ８３０では、変数ｉと変数Ｎとの大小関係から、全ての認証局（認証パス上の認証局の全てを意味する）の公開鍵証明書を確認したかを調べる（図８では“ｉ＜Ｎ”と記載している。）。全ての認証局の公開鍵証明書を確認したが、検証成功認証局テーブル２６３又は検証失敗認証局テーブル２６４に登録されていなかった場合は、ステップ８９０を実施する。このステップ８９０では、いずれのテーブルに登録されている情報も流用することが出来ないため、全ての認証局の公開鍵証明書の検証とメッセージ送信者の公開鍵証明書の検証を行う。図８では“０番目からｉ−１番目までの認証局及びメッセージ送信者の公開鍵証明書の検証”と記載されている。

ステップ８３０で、全ての認証局の公開鍵証明書を確認済みでないと判断した場合は、ステップ８４０が実施される。ステップ８４０において、下位認証局からi番目（ｉ＝０，・・・,Ｎ−１，Ｎ：認証パスに存在する認証局の数）の認証局が、検証成功認証局テーブル２６３の認証局ＩＤ５３１（図５の（ａ））に登録されているか否かを確認する。図８では、ステップ８４０は、“ｉ番目の認証局は検証成功認証局テーブルに登録されている”と記載されている。ここで言う検証成功認証局テーブルに登録されているとは、認証局の公開鍵証明書６５２に記載されている（含まれている）認証局ＩＤが認証局ＩＤ５３１に存在し、現在の時刻が検証結果有効時刻５３２より前の時刻であり、認証局の公開鍵証明書６５２に記載されている（含まれている）公開鍵が公開鍵５３３と同じ値である場合である。登録されている場合は、ｉ番目からルート認証局までの認証局の公開鍵証明書の正当性は検証されたものと見なして、ステップ８９０を実施する。ステップ８９０では、０番目の認証局である下位認証局からｉ−１番目までの認証局の公開鍵証明書を検証する。

ステップ８９０において、いずれかの認証局の公開鍵証明書の検証に失敗した場合、又はメッセージ送信者の公開鍵証明書の検証に失敗した場合、公開鍵証明書の検証において失敗したとして、公開鍵証明書の検証処理を終了（図８では、公開鍵証明書の検証終了）する。

一方、ステップ８９０において、下位認証局からｉ−１番目までの全ての認証局の公開鍵証明書の検証に成功した場合は、メッセージ送信者の公開鍵証明書を検証し、その結果を公開鍵証明書の検証結果として処理を終了する。

前述したステップ８４０で、検証成功認証局テーブル２６３に登録されていない場合は、ステップ８５０が実施される。このステップ８５０においては、認証局が検証失敗認証局テーブル２６４に登録されているか否かを確認する。図８では、ステップ８５０は“ｉ番目の認証局が認証局失敗テーブルに登録されている”と記載されている。ここで言う認証局失敗テーブルに登録されているとは、認証局の公開鍵証明書６５２に記載されている（含まれている）認証局ＩＤが認証局ＩＤ５４１に存在し、現在の時刻が検証結果有効時刻５４４より前の時刻である場合である。この確認により、登録されていると判明した場合は、ステップ８７０が実施される。このステップ８７０においては、検証失敗認証局テーブル２６４（図２）に登録されている公開鍵５４２（図５の（ｂ））及び公開鍵証明書の署名５４３（図５の（ｂ））の値と、受信したメッセージに含まれている認証局の公開鍵証明書の公開鍵及び署名の値とが等しいか否かの確認が行われる。図８では、ステップ８７０は“公開鍵と公開鍵証明書の署名が同じ値である”と記載されている。等しいと確認された場合は、ｉ番目の認証局の公開鍵証明書の検証において失敗したと見なして、処理を終了する。一方、等しくないと確認された場合は、ステップ８８０でi番目からルート認証局までの公開鍵証明書の検証を行う。図８では、ステップ８８０は“ｉ番目からＮ−１番目までの認証局の公開鍵証明書の検証成功”と記載されている。このステップ８８０において、全ての認証局の公開鍵証明書の検証に成功した場合は、ステップ８９０で下位認証局である０番目からｉ−１番目までの認証局の公開鍵証明書の検証を行う。このステップ８９０での検証の結果を公開鍵証明書の検証結果として処理を終了する。また、前述したステップ８８０で、いずれかの認証局の公開鍵証明書の検証に失敗した場合には、公開鍵証明書の検証において失敗したとして処理を終了する。

なお、ステップ８６０は、認証局が、検証成功認証局テーブル２６３及び検証失敗認証局テーブル２６４に登録されていないとき、上位認証局が登録されているかどうかを確認するため、変数ｉの値を１インクリメントする。図８では、ステップ８６０は“ｉ＜−ｉ＋１”と記載されている。変数ｉをインクリメントして、次にステップ８３０へ戻る。

図９は、図７に示したステップ７７０の詳細フローを示す図である。メッセージ送信者である機器（路側機１０１又は車載器１０２）の公開鍵証明書の検証結果が検証成功機器テーブル２６１又は検証失敗機器テーブル２６２に登録されていない場合、今回の検証結果を登録するか否かの判定が行われる。

まず、ステップ９１０において、機器の公開鍵証明書の登録判定を行う。この登録判定については、その詳細を図１０を用いて後述するので、ここでは省略する。次に、ステップ９２０からステップ９８０で、機器の公開鍵証明書の検証において用いた全ての認証局の公開鍵証明書を登録するか否かの判定を行う。この実施の形態では、全ての認証局の公開鍵証明書を登録するか否かの判定を行う例を示すが、セキュリティポリシーに応じて一部の認証局の公開鍵証明書を登録するか否かを判定する様にしても良い。一部の認証局について判定する場合には、例えば特定の下位認証局の公開鍵証明書は登録しないと言う様なセキュリティポリシーを設定情報２６５（図２）に登録しておき、図１０に示したステップで、このセキュリティポリシーを判定条件として用いれば良い。

図９の説明に戻って、この実施の形態の説明を行う。まず、ステップ９２０で、下位認証局から順に確認していくための初期化処理を行っている。この初期化処理においては、図８で前述したステップ８２０と同様に、変数ｉに０を設定し、認証パスに存在する認証局の数を変数Ｎに設定する。ステップ９３０では、全ての認証局の公開鍵証明書を確認済みか調べる。図９では、ステップ９３０は“ｉ＜Ｎ”と記載されている。変数ｉが変数Ｎよりも大きな値の場合、全ての認証局の公開鍵証明書の確認が実施されたことになる。全ての認証局の公開鍵証明書の確認が実施されており、今回の公開鍵証明書の検証において、検証成功認証局テーブル２６３又は検証失敗認証局テーブル２６４に登録されている結果を用いた場合には、公開鍵証明書の検証を新たに実施していないことになる。このときには、新規に、検証成功認証局テーブル２６３又は検証失敗認証局テーブル２６４に登録する認証局の情報はないと判断し、処理を終了する。図９では“公開鍵証明書の検証結果の登録判定終了”と記載されている。

変数ｉが変数Ｎよりも小さな値の場合は、ステップ９４０にて、今回のｉ番目の認証局の公開鍵証明書の検証を、省略せずに実施したか否かを確認する。図９では、ステップ９４０は“今回の公開鍵証明書検証で公開鍵証明書の検証を実施した”と記載されている。検証を省略していた場合は、次にステップ９７０を実施する。ステップ９７０においては、変数ｉをインクリメントし、ステップ９３０へ戻り、次の認証局の登録判定を行う。一方、検証を省略していなかった場合は、次にステップ９５０が実施される。

ステップ９５０においては、ｉ番目の認証局の公開鍵証明書の検証結果が、既に検証成功認証局テーブル２６３又は検証失敗認証局テーブル２６４に登録されているか否かを、認証局ＩＤを基にした確認を実施する。図９では、ステップ９５０は“ｉ番目の認証局の公開鍵証明書は検証成功認証局テーブル検証失敗認証局テーブルに登録済み”と記載されている。該当する認証局ＩＤが登録されていない場合は、ステップ９６０へ移る。一方、既に登録されている場合は、ステップ９８０へ移る。このステップ９８０では、今回の検証結果と、テーブルに登録されている結果とが異なるか否かの判定が行われる。図９では、“今回の検証結果と登録結果が異なる”と記載されている。このステップ９８０において、異なると判断した場合は、ステップ９６０に進み、認証局の公開鍵証明書の検証結果の登録判定を行う。ステップ９８０では、今回受信した内容とテーブルに登録されている内容との比較が行われる。この比較により、異なると判断する例は、次の３例のいずれかの場合である。（１）今回受信した公開鍵と検証成功認証局テーブル２６３に登録されている公開鍵の値が異なる場合。（２）今回受信した公開鍵と検証失敗認証局テーブル２６４に登録されている公開鍵の値が異なる場合。（３）今回受信した公開鍵証明書の署名と検証失敗認証局テーブル２６４に登録されている公開鍵証明書の署名の値が異なる場合。

図１１には、前記したステップ９６０の詳細が示されている。すなわち、同図には、認証局の公開鍵証明書の検証結果の登録判定の処理フローが示されている。検証成功認証局テーブル２６３（図５（ａ））又は検証失敗認証局テーブル２６４（図５（ｂ））に、今回の検証結果を登録するか否かの判定は、公開鍵証明書の有効期間、信頼レベル、及び利用頻度の可能性で判定する。同図に示したステップ１１１０において、時刻情報取得処理ユニット２５０で現在の時刻を取得する。取得した現在の時刻が、公開鍵証明書の有効期限よりも所定時間より長いかを確認する。すなわち、公開鍵証明書の残りの有効期限が、所定時間より長いかを確認する。図１１ではステップ１１１０は、“証明書の有効時間が一定値以上ある”と記載されている。確認の結果として、有効期限が所定時間より短い場合は、認証局の公開鍵証明書の検証結果の登録判定を終了する。これに対して、所定時間より長いことを確認した場合、ステップ１１２０を実行する。ステップ１１２０においては、上位認証局の信頼レベルを判定し、信頼レベルが所定レベルよりも下の場合は、認証局の公開鍵証明書の検証結果の登録判定を終了する。各認証局の信頼レベルは、設定情報２６５に登録されている。例えば、認証局毎に信頼レベルを予め定め、認証局と定めた信頼レベルの対応表をテーブルとして、予め設定情報２６５に設ける。これにより、上位認証局の信頼レベルを判定することが可能となる。信頼レベルが所定レベル以上の場合は、ステップ１１３０を次に実行する。なお、図１１ではステップ１１２０は“信頼レベルが一定値以上である”と記載されている。

ステップ１１３０においては、認証局の公開鍵証明書の利用頻度が高いかどうかを判定する。例えば、認証局が地域ごとに存在し、車載器１０２の公開鍵証明書２７１は、車載器１０２を搭載した車両の所有者の居住地に存在する認証局から発行してもらう場合、走行情報取得処理ユニット２４０（図２）から現在の位置を取得し、現在の位置（地域）に存在する認証局である場合は、認証局の利用頻度が高いと判定する。また、走行情報記憶ユニット２８０（図２）に過去の走行履歴を保存しておく様にすれば、車載器１０２に記憶されている過去の走行履歴から、今回の行き先を予測し、行き先に沿った地域に存在するところの認証局の場合は、その認証局の利用頻度が高いと判定する。認証局の利用頻度の判定はこれに限ったものではなく、図示しないカーナビ（Automotive navigation system）と連携し、行き先を、カーナビから取得し、行き先に沿った地域に存在するところの認証局は利用頻度が高いとすることもできる。さらに、公開鍵証明書がアプリケーションごとに異なる認証局から発行される（アプリケーション毎に認証局が割り当てられている）場合は、車載器１０２に搭載されているアプリケーションを判断し、そのアプリケーションが起動されたとき、このアプリケーションに割り当てられた認証局の公開鍵証明書の利用頻度を高くする様にしても良い。ステップ１１１０からステップ１１３０のそれぞれの判定に用いた閾値（所定時間、所定レベルは、利用頻度が高いと判断するための所定頻度）は、設定情報２６５に予め登録される。なお、図１１ではステップ１１３０は“利用頻度が高い認証局の証明書である”と記載されている。

ステップ１１３０で利用頻度が高いと判定された認証局については、ステップ１１４０において検証結果有効時刻５３２、５４４を利用頻度から算出する。また、検証結果有効時刻５３２、５４４は、走行情報取得処理ユニット２４０で取得した現在の走行情報（位置情報、速度情報、進行方向情報）から、利用頻度が高いと判断した認証局が存在する地域に、車両（車載器１０２）が存在する期間を算出し、算出した期間を超える時間となる様に定めても良い。検証結果有効時刻５３２、５４４の算出方法はこれに限るものではなく、公開鍵証明書がアプリケーション毎に割り当てられた認証局から発行されている場合、アプリケーションの平均利用時間から算出してもよい。また、所定の時間情報を設定情報２６５に予め登録しておき、現在の時刻に所定の時間情報を加えて、新たな有効時刻を求め、求めた有効時刻を検証結果有効時刻５３２、５４４として設定する様にしてもよい。図１１では、ステップ１１４０は“検証結果有効期間の算出”と記載されている。

次にステップ１１５０において、今回の公開鍵証明書の検証結果を確認する。すなわち、公開鍵証明書の検証において成功したのか失敗したのかの確認が行われる。公開鍵証明書の検証において成功の場合は、次にステップ１１６０が実行される。ステップ１１６０においては、検証成功認証局テーブル２６３の更新が行われる。一方、検証において失敗の場合には、次にステップ１１７０が実行される。ステップ１１７０においては、検証失敗認証局テーブル２６４の更新が行われる。これらのステップ１１６０及びステップ１１７０における更新は、機器ＩＤが、検証成功認証局テーブル２６３及び検証失敗認証局テーブル２６４に登録されていない場合、又は既に登録されている公開鍵又は公開鍵証明書の署名と異なる公開鍵又は公開鍵証明書の署名であった場合に実施される。そのため、ステップ１１６０及びステップ１１７０の更新においては、検証成功認証局テーブル２６３及び検証失敗認証局テーブル２６４への新たな認証局ＩＤ、公開鍵、公開鍵証明書の署名及び検証結果有効時刻の追加も行われる。検証成功認証局テーブル２６３及び検証失敗認証局テーブル２６４はメモリで構成されているため、登録出来る情報量には制限がある。テーブルに登録出来る最大値の情報量に到達した場合、検証結果有効時刻５３２又は検証結果有効時刻５４４に基づいて、有効時刻が切れている情報があるかを確認し、ある場合はその情報を削除し、新しい検証結果を登録する（ステップ１１６０、１１７０）。有効時刻が切れている情報がない場合は、残りの有効時刻が一番短いものを削除し、新しい検証結果を登録する（ステップ１１６０、１１７０）。図１１では、ステップ１１５０は“検証成功の認証局である”、ステップ１１６０は“検証成功認証局テーブルの更新”、ステップ１１７０は“検証失敗認証局テーブルの更新”とそれぞれ記載されている。

図１０に、図９に示したステップ９１０の詳細を示す。機器の公開鍵証明書の検証結果を検証成功機器テーブル２６１又は検証失敗機器テーブル２６２（以下、「機器テーブル」という。）に登録するか否かの判定は、公開鍵証明書の有効期間、信頼レベル、及び利用頻度の可能性で判定する。図１０に示したステップ１０１０において、公開鍵証明書の有効期間が所定時間より長いかを確認する。同図では“公開鍵証明書の有効時間が一定値以上ある”と記載されている。公開鍵証明書の有効期間が所定時間より短い場合は機器テーブルへの登録は行わずに処理を終了する。同図では“機器の公開鍵証明書の検証結果の登録判定終了”と記載されている。これに対して、所定時間より長い場合には、次にステップ１０２０が実施される。ステップ１０２０で、公開鍵証明書を発行している認証局の信頼レベルを判定する。同図では“信頼レベルが一定値以上である”と記載されている。信頼レベルが所定レベルより低い場合は処理を終了する。認証局の信頼レベルは、前述したステップ１１２０と同様に設定情報２６５に登録されている。信頼レベルが不明な認証局の場合、どのように判定するかも設定情報２６５に登録されている。例えば信頼レベルが不明の場合には、信頼レベルは所定レベル以下であると見なして処理する様に設定する。この様にすることにより、検証成功機器テーブル２６３にも検証失敗機器テーブル２６４にも登録せず、再度、同じ機器ＩＤからメッセージを受信した場合は公開鍵証明書の検証をもう一度行う様にする。これにより、機器テーブルを構成するメモリを効率的に使うことが可能となる。

ステップ１０３０では、この車載器１０２を搭載した車両の走行情報取得処理ユニット２４０から車載器１０２（車両）の位置情報、速度情報、進行方向情報を取得する。同図では“進行方向が同じ又は近づいている”と記載されている。受信したメッセージＭ（図６）から、メッセージＭを発信した車両の進行方向情報６３３（図６）と、この車載器１０２を搭載した車両の進行方向情報とに基づいて、進行方向が互いに遠ざかっている場合は、機器テーブルに登録しないと判定する。そのため、この場合には、機器の公開鍵証明書の検証結果の登録判定終了の処理を行う。

一方、ステップ１０３０にて、進行方向が同じ又は近づいていると判定した場合には、次にステップ１０４０が実施される。ステップ１０４０においては、車載器１０２を搭載した車両の速度情報と、受信したメッセージＭの速度情報６３２（図６）から速度の差を求め、速度の差が所定値より大きいか否かの判断を行う。図１０では“速度の差が一定値以下である”と記載されている。速度の差が所定値より大きい場合には、機器テーブルに登録しない様に、機器の公開鍵証明書の検証結果の登録判定終了の処理を行う。これに対して、速度の差が所定値よりも小さい場合には、ステップ１０５０が実施される。これにより、1回しかメッセージを受信しない様な車載器（例えば、高速にすれ違う車載器１０２）の検証結果は登録しないため、機器テーブルの更新（追加）負荷を軽減することができる。

ステップ１０５０（図１０では“有効時間の算出”と記載されている。）においては、この車載器１０２を搭載した車両の位置情報と、受信したメッセージの位置情報６３１（図６）、ステップ１０３０及びステップ１０４０の情報（進行方向情報及び速度情報）に基づいて、検証結果有効時刻を算出する。

図１１を用いて、検証成功認証局テーブル２６３及び検証失敗認証局テーブル２６４（認証局テーブルという。）の更新（追加）を先に説明した。このときの説明から理解される様に、認証局テーブルの更新（追加）においては、利用頻度の可能性も更新（追加）するか否かの情報としていた。しかしながら、検証成功機器テーブル２６１、及び検証失敗機器テーブル２６２の更新（追加）については、利用頻度の可能性ではなく、進行方向情報及び速度情報に基づいて更新（追加）するか否かの情報としている。これにより、車両（路側機）が接近するか遠ざかるかで、機器テーブルの更新（追加）を実施することが可能となる。機器テーブルの更新（追加）については、進行方向情報及び速度情報ではなく、例えば、加速度や行き先情報を利用しても良いし、これら４種類の情報を適時組み合わせて、更新（追加）を決める様にしても良い。なお、進行方向情報及び速度情報も、利用頻度の可能性の判断基準の一つであると見なすことも出来る。

図１０に示したステップ１０６０では、機器の公開鍵証明書の検証結果を確認する。同図では“検証成功の機器である”と記載されている。すなわち、機器の公開鍵証明書の検証において成功したか否かを判定し、成功の場合にはステップ１０７０を実施させ、失敗の場合にはステップ１０８０を実施させる。ステップ１０７０では、検証成功機器テーブル２６１を更新（追加）する。一方、失敗の場合にはステップ１０８０で、検証失敗機器テーブル２６２を更新（追加）する。ステップ１０７０及びステップ１０８０は、前記したステップ１１６０及びステップ１１７０と同様に、追加する機器テーブルに最大値の情報が登録されているとき、検証結果有効時刻４１２又は検証結果有効時刻５２４から有効時刻切れの情報があるかを確認し、ある場合はその情報を削除し、新しい検証結果を登録する。有効時刻切れの情報がない場合は、残りの有効時刻が一番短いものを削除し、新しい検証結果を登録する。なお、図１０では、ステップ１０７０は“検証成功機器テーブルの更新”、ステップ１０８０は“検証失敗機器テーブルの更新”とそれぞれ記載されている。

前記した実施の形態では、機器テーブルに検証結果有効時刻を格納した例を説明したが、検証結果有効時刻の替わりに有効エリアを用いてもよい。例えば、機器テーブルにおいて、機器ＩＤに対応した有効エリアを設け、有効エリアから外れているか否かで、機器テーブルの更新（追加）を決める様にしても良い。勿論、テーブルに検証結果有効時刻と有効エリアの両者を格納する様にしても良い。

上述した実施の形態では、証明書の失効確認については明記していないが、証明書の失効を確認した場合も、公開鍵証明書の検証において失敗したと見なすことができる。従って、公開鍵証明書の検証において失敗とは、有効期限を過ぎていた場合、認証局の公開鍵を用いて署名検証に失敗した場合、及び証明書が失効している場合を含んでいると理解されたい。

以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。

１２１０ 公開鍵証明書の検証処理ユニット
１２２０ アプリケーション実行ユニット
１２３０ 検証失敗テーブル
１２４０ 処理ユニット
１２５０ 検証成功テーブル
Ｍ メッセージ

Claims (12)

1. 送信者を特定する機器情報と公開鍵と公開鍵証明書の署名とを有する公開鍵証明書と、公開鍵証明書の検証において成功したときに使われるべきデータとを含むメッセージを受ける処理ユニットと、
   前記処理ユニットによる公開鍵証明書の検証において失敗したメッセージに含まれている機器情報と公開鍵と公開鍵証明書の署名とを保持する第１保持回路と、
   を具備し、前記処理ユニットは、メッセージを受けたとき、該メッセージに含まれている機器情報が前記第１保持回路に保持されている機器情報と一致するか否かを確認し、一致するとき、
   前記第１保持回路に保持される公開鍵及び公開鍵証明書の署名と受信したメッセージに含まれる公開鍵及び公開鍵証明書の署名とが同じ場合は、メッセージの署名検証失敗として処理し、
   前記第１保持回路に保持される公開鍵及び公開鍵証明書の署名と受信したメッセージに含まれる公開鍵および公開鍵証明書の署名とが異なる場合は、受信した公開鍵証明書の検証を実施し、該公開鍵証明書の検証において成功した場合はメッセージの署名検証を行い、該公開鍵証明書の検証において失敗した場合はメッセージの署名検証失敗とし、
   メッセージ送信者の公開鍵証明書の検証結果が登録されていない場合は、公開鍵証明書及び署名の検証を実施する装置。
2. 公開鍵証明書の検証において成功したメッセージに含まれている機器情報を保持する第２保持回路を具備し、前記処理ユニットは、メッセージを受けたとき、該メッセージに含まれている機器情報が前記第２保持回路に保持されている機器情報と一致するか否かを確認し、一致するとき、該メッセージに含まれているデータを用いた処理を実行する請求項１の装置。
3. 公開鍵証明書に含まれている機器情報が、前記第１保持回路に保持されている機器情報及び上記第２保持回路に保持されている機器情報のそれぞれと一致しないとき、前記処理ユニットは公開鍵証明書に含まれている機器情報を、該公開鍵証明書の検証において失敗した場合は前記第１保持回路に保持させ、該公開鍵証明書の検証において成功した場合は前記第２保持回路に保持させる請求項２の装置。
4. 前記メッセージは、認証局を特定する識別情報と認証局の公開鍵と認証局の公開鍵証明書の署名とを含む認証局の公開鍵証明書を有し、
   前記処理ユニットによる認証局の公開鍵証明書の正当性検証において失敗した認証局を特定する識別情報と認証局の公開鍵と認証局の公開鍵証明書の署名とを保持する第３保持回路とを具備し、
   受信したメッセージに含まれる機器情報が、前記第１保持回路に保持されている機器情報及び上記第２保持回路に保持されている機器情報のそれぞれと一致しないとき、前記処理ユニットは、該メッセージに含まれる識別情報が、前記第３保持回路に保持されている識別情報と一致するか否かを確認し、一致するとき、
   前記第３保持回路に保持される認証局の公開鍵及び認証局の公開鍵証明書の署名と受信したメッセージに含まれる認証局の公開鍵及び認証局の公開鍵証明書の署名とが同じ場合は、認証局の公開鍵証明書の検証に失敗したとみなして処理し、
   前記第３保持回路に保持される認証局の公開鍵及び認証局の公開鍵証明書の署名と受信したメッセージに含まれる認証局の公開鍵および認証局の公開鍵証明書の署名とが異なる場合は、受信した認証局の公開鍵証明書の検証を実施する請求項２の装置。
5. 認証局の公開鍵証明書の正当性検証において成功した認証局を特定する識別情報を保持する第４保持回路とを具備し、
   前記処理ユニットは、受信したメッセージに含まれる識別情報が、前記第４保持回路に保持されている識別情報と一致するか否か確認し、一致するとき、受信したメッセージに含まれる公開鍵証明書の検証を実施する請求項４の装置。
6. 前記受信したメッセージに含まれる公開鍵証明書の検証において、成功したとき、該公開鍵証明書に含まれる機器情報を前記第２保持回路に保持させ、失敗したとき、該公開鍵証明書に含まれる機器情報を前記第１保持回路に保持させる請求項５の装置。
7. 前記処理ユニットは、受信したメッセージに含まれる識別情報が、前記第３保持回路及び第４保持回路のそれぞれに保持されている識別情報と一致しないとき、受信したメッセージに含まれる認証局の公開鍵証明書の正当性検証を実施し、正当性検証において成功した場合、認証局を特定する識別情報を前記第４保持回路に保持させ、正当性検証において失敗した場合、認証局を特定する識別情報を前記第３保持回路に保持させる請求項６の装置。
8. 送信者を特定する機器情報を含む公開鍵証明書と、認証局を特定する識別情報と認証局の公開鍵と認証局の公開鍵証明書の署名とを含む認証局の公開鍵証明書とを有するメッセージが供給される処理ユニットと、
   前記処理ユニットによる認証局の公開鍵証明書の正当性検証において失敗した認証局を特定する識別情報と認証局の公開鍵と認証局の公開鍵証明書の署名とを保持する第５保持回路とを具備し、
   受信したメッセージに含まれる識別情報が、前記第５保持回路に保持されている識別情報と一致するか否かを確認し、一致するとき、
   前記第５保持回路に保持される認証局の公開鍵及び認証局の公開鍵証明書の署名と受信したメッセージに含まれる認証局の公開鍵及び認証局の公開鍵証明書の署名とが同じ場合は、認証局の公開鍵証明書の検証に失敗したとみなして処理し、
   前記第５保持回路に保持される認証局の公開鍵及び認証局の公開鍵証明書の署名と受信したメッセージに含まれる認証局の公開鍵および認証局の公開鍵証明書の署名とが異なる場合は、受信した認証局の公開鍵証明書の検証を実施する装置。
9. 認証局の公開鍵証明書の正当性検証において成功した認証局を特定する識別情報を保持する第６保持回路とを具備し、
   前記処理ユニットは、受信したメッセージに含まれる識別情報が、前記第６保持回路に保持されている識別情報と一致するか否か確認し、一致するとき、受信したメッセージに含まれる公開鍵証明書の検証を実施する請求項８の装置。
10. 公開鍵を用いてメッセージ認証を行う車載通信システムであって、
    メッセージ送信者の公開鍵証明書の検証結果が、メモリに登録されているか否かを確認し、検証成功として登録されている場合は、公開鍵証明書の検証を省略し、メッセージの署名検証を行い、
    受信したメッセージに含まれる機器情報が検証失敗として登録されており、登録時の公開鍵及び公開鍵証明書の署名と受信したメッセージの公開鍵及び公開鍵証明書の署名の値が同じ場合は、メッセージの署名検証失敗として処理し、
    受信したメッセージに含まれる機器情報が検証失敗として登録されており、登録時の公開鍵及び公開鍵証明書の署名と受信したメッセージの公開鍵および公開鍵証明書の署名の値が異なる場合は、受信した公開鍵証明書の検証を実施し、該公開鍵証明書の検証において成功した場合はメッセージの署名検証を行い、該公開鍵証明書の検証において失敗した場合はメッセージの署名検証失敗とし、
    メッセージ送信者の公開鍵証明書の検証結果が登録されていない場合は、公開鍵証明書及び署名の検証を実施する車載通信システム。
11. 前記メッセージの送信者は、車両又は路側機である請求項１０の車両通信システム。
12. メッセージを送信する車両の走行情報、メッセージを送信する路側機の設置情報、メッセージを受信する車両の走行情報、メッセージを送信する車両又は路側機の公開鍵証明書の有効期限に関する情報及び公開鍵証明書の信頼レベルに関する情報のうちの少なくとも１つの情報を利用して、公開鍵証明書の検証結果を、メモリへ登録するか否かが判定される請求項１１の車載通信システム。

Images