(57)【要約】  路側機や車載器同士の路車間通信や車車間通信を行なう際に、デジタル署名の検証や新鮮性の検証を含む配信情報の検証を効率化する。  他の通信装置から過去に受信した第一の認証情報と配信情報と第二の認証情報とを含む通信データの前記第二の認証情報の履歴を認証情報履歴として記憶する記憶部と、新たに受信した通信データである新通信データの第一の認証情報により前記新通信データの第二の認証情報の真正性を検証するとともに、前記新通信データの第二の認証情報と前記記憶部に記憶された前記認証情報履歴とを比較して前記新通信データの新鮮性を検証する認証処理部とを備える。
2014196181.tif 000002
【特許請求の範囲】
【請求項１】
他の通信装置から過去に受信した第一の認証情報と配信情報と第二の認証情報とを含む通信データの前記第二の認証情報の履歴を認証情報履歴として記憶する記憶部と、
新たに受信した通信データである新通信データの第一の認証情報により前記新通信データの第二の認証情報の真正性を検証するとともに、前記新通信データの第二の認証情報と前記記憶部に記憶された前記認証情報履歴とを比較して前記新通信データの新鮮性を検証する認証処理部とを備えたデータ認証装置。
【請求項２】
前記配信情報のハッシュ値を演算するハッシュ値演算部を備え、
前記記憶部は、前記ハッシュ値演算部により演算した配信情報のハッシュ値を前記認証情報履歴の前記第二の認証情報に対応付けて記憶し、
前記認証処理部は、前記新通信データに含まれる配信情報のハッシュ値及び第二の認証情報と前記記憶部に記憶された前記認証情報履歴とを比較して前記新通信データの新鮮性を検証する請求項１記載のデータ認証装置。
【請求項３】
前記第二の認証情報は、公開鍵暗号に基づくデジタル署名である請求項１または２記載のデータ認証装置。
【請求項４】
前記第二の認証情報は、共通鍵暗号に基づくＭＡＣ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）である請求項１記載のデータ認証装置。
【請求項５】
他の通信装置から過去に受信した第一の認証情報と配信情報と第二の認証情報とを含む通信データの前記第二の認証情報の履歴を認証情報履歴として記憶する記憶ステップと、
新たに受信した通信データである新通信データの第一の認証情報により前記新通信データの第二の認証情報の真正性を検証するとともに、前記新通信データの第二の認証情報と前記記憶部に記憶された前記認証情報履歴とを比較して前記新通信データの新鮮性を検証する認証処理ステップとを備えたデータ認証方法。
【請求項６】
前記配信情報のハッシュ値を演算するハッシュ値演算ステップを備え、
前記記憶ステップは、前記ハッシュ値演算ステップにより演算した配信情報のハッシュ値を前記認証情報履歴の前記第二の認証情報に対応付けて記憶し、
前記認証処理ステップは、前記新通信データに含まれる配信情報のハッシュ値及び第二の認証情報と前記記憶ステップに記憶された前記認証情報履歴とを比較して前記新通信データの新鮮性を検証する請求項５記載のデータ認証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、路側機や車載器同士の路車間通信や車車間通信で用いられるデータ認証装置に関する。
【背景技術】
【０００２】
近年、放送型の路車間通信や車車間通信によって、路側に設置された路側機や車両に搭載された車載器から他の車載器に対して、交通渋滞や信号に関わる情報や車両の速度、位置など走行状態に関する情報、救急車等の緊急車両接近情報、隊列走行時の車両制御情報等（以下、これらをまとめて配信情報という）を送信して、安全運転や効率的な運転に役立てる運転支援システムが検討されている。【０００３】
このような運転支援システムのセキュリティ対策の例として、特許文献１に、公開鍵暗号アルゴリズムのデジタル署名を用いた路車間通信システムが開示されている。【０００４】
また、上記のような路車間通信システムでは、配信情報を含む通信データが再送される攻撃（リプレイ攻撃）への対処が必要である。その対処として通信データの新鮮性の検証がある。この新鮮性の検証では、既に受信した通信データを車両が保持しておき、車両が新たに受信した通信データについて、車両が保持している受信した通信データと比較して一致するかどうかを判定し、一致していれば既に受信したことのある通信データとして受理せず、そうでない場合は受け取ったことがない通信データとして受理するというような処理を行なう。しかしながら、この方法は、受信した通信データのサイズに応じたメモリ領域を必要とする。この問題に対して、新鮮性の検証に必要なメモリ領域の削減を目的として、ハッシュ関数を用いる方法がある。これは、受信した通信データに対して、ハッシュ関数を用いてハッシュ値を計算して保持しておき、通信データを新たに受信した際に、その通信データのハッシュ値を計算し、保持している既に受信した通信データのハッシュ値と一致するかどうかを検査し、一致した場合には、既に受信したことのあるデータとして受理せず、そうでない場合は受け取ったことがない通信データとして受理するものである。このようにハッシュ関数を用いることで、受信した通信データすべてを保持する必要はなく、ハッシュ値を保持することで対処できる。【０００５】
また、一般的に、デジタル署名の生成や検証の処理には、ハッシュ関数の処理が含まれる。署名生成の場合には、デジタル署名の対象となるデータのハッシュ値に対して公開鍵暗号の秘密鍵による演算などを行ない、署名検証の場合には、デジタル署名の対象となるデータのハッシュ値に対して、公開鍵暗号の公開鍵による演算などを行なう。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００７−８８７３７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来、多数の路側機や車両と通信する際には、非常に多くの配信情報を検証することになるため、配信情報の検証に要する処理ができるだけ少ないことが望ましい。特に、配信情報の検証として、少なくとも、デジタル署名の検証と、新鮮性の検証が行なわれる際に、ハッシュ関数による処理を２回以上行なわなければならない。【０００８】
この発明は、上記のような問題点を解決するためになされたもので、デジタル署名の検証や新鮮性の検証を含む配信情報の検証において、効率的な検証を実施し、処理能力のより低い装置での実現を目的とする。
【課題を解決するための手段】
【０００９】
上記で述べた課題を解決するため、本発明のデータ認証装置は、他の通信装置から過去に受信した第一の認証情報と配信情報と第二の認証情報とを含む通信データの前記第二の認証情報の履歴を認証情報履歴として記憶する記憶部と、新たに受信した通信データである新通信データの第一の認証情報により前記新通信データの第二の認証情報の真正性を検証するとともに、前記新通信データの第二の認証情報と前記記憶部に記憶された前記認証情報履歴とを比較して前記新通信データの新鮮性を検証する認証処理部とを備えることとしたものである。【００１０】
また、本発明のデータ認証方法は、他の通信装置から過去に受信した第一の認証情報と配信情報と第二の認証情報とを含む通信データの前記第二の認証情報の履歴を認証情報履歴として記憶する記憶ステップと、新たに受信した通信データである新通信データの第一の認証情報により前記新通信データの第二の認証情報の真正性を検証するとともに、前記新通信データの第二の認証情報と前記記憶部に記憶された前記認証情報履歴とを比較して前記新通信データの新鮮性を検証する認証処理ステップとを備えることとしたものである。
【発明の効果】
【００１１】
本発明によれば、署名検証で行なわれるハッシュ関数の演算結果を、署名検証と共に新鮮性の検証にも用いることで、従来、新鮮性の検証のために行なっていたハッシュ関数の演算が不要となり、従来２回行なわれていたハッシュ関数の演算を１回に削減することができる。これにより、処理負荷を軽減することができるという効果がある。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施の形態１に係るデータ認証装置の一実施例を示す構成図である。
【図２】通信装置間で配信される通信データのデータ構造を示す図である。
【図３】本発明の実施の形態１に係るデータ認証装置を用いた運転支援システムの構成を示す図である。
【図４】本発明の路車間通信システムの構成を示す図である。
【図５】本発明の路車間通信システムの通信データのデータ構造を示す図である。
【図６】本発明の実施の形態１に係る認証処理部４の構成の一例を示す図である。
【図７】本発明の実施の形態１に係る通信データ受信時の認証処理部４の動作を示すフローチャートである。
【図８】本発明の実施の形態２に係る認証処理部４の構成の一例を示す図である。
【図９】本発明の実施の形態２に係る通信データ受信時の認証処理部４の動作を示すフローチャートである。
【発明を実施するための形態】
【００１３】
実施の形態１．
実施の形態１では、配信情報の検証において、デジタル署名の検証におけるハッシュ関数の演算と新鮮性の検証におけるハッシュ関数の演算を統合して、配信情報の検証を行なう形態を示す。
図１は、本発明の実施の形態１に係るデータ認証装置の一実施例を示す構成図である。
路車間および車車間通信の場合、路側に設置される路側機は車両に搭載される車載器と通信し、車載器は路側機と他の車載器と通信する。以下、本実施形態では、路側機と車載器を総称して、通信装置として記載する。
【００１４】
図１において、通信装置１は、配信情報を含む通信データを他の通信装置６に送信し、他の通信装置６が送信した通信データを受信する通信装置である。通信装置１は、他の通信装置６に送信する通信データを生成し、他の通信装置６へ通信データを送信する通信部３、通信部３により他の通信装置６から受信した通信データ内に含まれる配信情報を処理する配信情報処理部２、受信側が送信側の正当性を確認する認証情報を、配信情報やあらかじめ格納されている鍵情報を用いて生成・検証するデータ認証装置としての認証処理部４、他の通信機器とＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ  Ｓｈｏｒｔ  Ｒａｎｇｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）や無線ＬＡＮなどの無線通信を行なう通信部３を備えている。認証処理部４には、認証処理部４が読み書き可能なメモリである記憶部５が設けられ、認証情報を生成・検証するために使用される鍵情報と、新鮮性の検証を行なうための情報として、過去に受信した認証情報の履歴である認証情報履歴が格納されている。
【００１５】
鍵情報は、例えば、公開鍵アルゴリズムによるデジタル署名を適用した場合は、認証局が発行した公開鍵証明書や公開鍵証明書に含まれる公開鍵に対応する秘密鍵、認証局の公開鍵証明書などであり、共通鍵アルゴリズムを適用した場合は、通信で使用する共通鍵や、使用する共通鍵を指定するIDなどである。
【００１６】
新鮮性の検証を行なうための情報は、配信情報のハッシュ値や、配信情報に付加されている署名の検証に使用した証明書のＩＤや、ハッシュ値、配信情報に付加されているＭＡＣ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）の検証に使用した鍵のＩＤなどである。
【００１７】
また、図示していないが、通信装置１には、現在の位置情報、日付や時間を表す日時情報が、通信装置１が搭載されている路側機や車両から入力されている。これらは、路側機や車両に設置されているＧＰＳ受信装置、ジャイロスコープや時計などで生成される。
【００１８】
次に、通信装置間で送受信される通信データのデータ構造について説明する。
図２は、通信装置間で配信される通信データのデータ構造を示す図である。
図２において、通信データは、第一の認証情報７、配信情報８、第二の認証情報９から構成され、この通信データが通信装置間で送受信される。
【００１９】
第一の認証情報７は、例えば、公開鍵アルゴリズムによるデジタル署名の場合は、当該通信装置１の公開鍵証明書や、公開鍵証明書を識別できるＩＤなどである。また、共通鍵アルゴリズムの場合は、一時的に利用するセッション鍵を共通鍵で暗号化したセッション鍵情報や、セッション鍵にメッセージ認証コードを追加したものを共通鍵で暗号化したセッション鍵情報などである。
【００２０】
第二の認証情報は、例えば公開鍵アルゴリズムの場合は、通信装置の秘密鍵によって生成された配信情報のデジタル署名などであり、共通鍵アルゴリズムの場合、セッション鍵によって生成されたメッセージ認証コードなどがある。
【００２１】
このようなデータ構造で、図２に示す通信データが送信される。なお、図示していないが、システムに応じて、通信データや配信情報を暗号化して送信してもよい。
【００２２】
次に、本発明の実施の形態１に係るデータ認証装置を用いた運転支援システムについて説明する
。
図３は、本発明の実施の形態１に係るデータ認証装置を用いた運転支援システムの構成を示す図である。
図３において、路側機１０は、周囲の車載器に配信情報を配信し、同様に車載器は、他の車載器に配信情報を配信する。このような運転支援システムにおいて、悪意のある利用者が車載器Ｃ１４や車載器Ｄ１５を悪用して、路側機１０や車載器（優先車両）１３になりすまし、他の車載器に対して偽の情報を配信して、混乱を引き起こしたり、交通事故を引き起こしたりすることが考えられる。従って、情報を配信している送信側、つまり、情報を配信している路側機や車載器の正当性を、受信側が確認できるセキュリティ手段が必要となるため、このセキュリティ手段として本発明のデータ認証装置を用いる。
以下、図４と図５を用いて、運転支援システムで用いられる路車間通信システムを説明する。
図４は、本発明の路車間通信システムの構成を示す図である。
図５は、本発明の路車間通信システムの通信データのデータ構造を示す図である。
図４の路車間通信システムでは、認証局１６が路側機１７に対して、路側機１７の証明書Ａ（公開鍵証明書Ａ）、及び認証局１６の証明書Ｂ（公開鍵証明書B）を発行する。路側機１７は、公開鍵証明書Ａを発行した認証局の公開鍵証明書Ｂを車載器１８に配信する。また、路側機１７は、図５に示すように、配信情報の署名２１（デジタル署名）を生成して、配信情報２０、配信情報の署名２１、及びその署名を検証できる公開鍵証明書Ａ１９を車載器１８に配信する。車載器１８は、受信した公開鍵証明書Ａ１９を認証局１６の公開鍵証明書Ｂで検証すると共に、配信情報の署名２１を公開鍵証明書Ａ１９で検証することにより、正当な路側機から配信された情報であることを確認する。車車間通信でも同様のセキュリティ対策は適用でき、緊急車両になりすました車載器から配信された情報や証明書を検証することで、一般の車載器が緊急車両になりすましていることが検出できる。
【００２３】
次に、図６、及び図７を用いて、通信装置１の認証処理部４の構成と、通信データ受信時の認証処理部４の処理フローについて説明する。
図６は、本発明の実施の形態１に係る認証処理部４の構成の一例を示す図である。
図７は、本発明の実施の形態１に係る通信データ受信時の認証処理部４の動作を示すフローチャートである。
【００２４】
まず、図６を用いて、認証処理部４の構成を説明する。
図６において、認証処理部４は、記憶部５、制御部２２、ハッシュ値演算部２４、署名検証部２６、ハッシュ値演算部２４への入力となるレジスタＡ２３、ハッシュ値演算部２４からの出力であり、署名検証部２６への入力となるレジスタＢ２５、署名検証部２６からの出力となるレジスタＣ２７から構成される。図６の認証処理部４は、配信情報を検証することに着目して記載しているが、通信データが暗号化されている場合には復号処理、通信データを生成する場合は、暗号化や署名生成（秘密鍵による演算）を行なう処理なども認証処理部４に含まれるが、図６では省略している。
【００２５】
次に、図７を用いて、通信データ受信時の認証処理部４の処理フローを説明する。
まず、ステップＳ１０1において、制御部２２は、通信データの検証を行なう際に、ハッシュ値演算部２４の入力レジスタＡ２３に署名対象のデータである配信情報をライトする。
次に、ステップＳ１０２において、制御部２２は、ハッシュ値演算部２４に対して演算開始を指示する。
次に、ステップＳ１０３において、ハッシュ値演算部２４は、演算が終了すると演算結果をレジスタＢ２５にライトする。
次に、ステップＳ１０４において、制御部２２は、ハッシュ値演算部２４の演算終了を、例えば、割り込みなどで検知し、レジスタＢ２５から演算結果（ハッシュ値）をリードする。
【００２６】
次に、ステップＳ１０５において、制御部２２は、ステップＳ１０３でレジスタＢ２５に設定されている情報以外で、署名検証に必要な情報をレジスタＢ２５にライトして設定する。
次に、ステップＳ１０６において、制御部２２は、署名検証部２６に対して演算開始を指示する。
次に、ステップＳ１０７において、署名検証部２６は、レジスタＢ２５に設定されている署名検証に必要な情報を読み出し、署名検証の演算を行ない、その演算結果をレジスタＣ２７にライトする。
【００２７】
次に、ステップＳ１０８において、制御部２２は、署名検証部２６の演算終了を、例えば、割り込みなどで検知し、レジスタＣ２７から演算結果をリードして読み出す。
次に、ステップＳ１０９において、制御部２２は、レジスタＣ２７から読み出した演算結果から、署名検証に成功しているか、失敗しているのかを判定し、成功している場合には、ステップＳ１１１へ進み、失敗している場合には、ステップＳ１１０へ進む。
次に、ステップＳ１１０において、制御部２２は、署名検証に失敗（真正性失敗）したことを、例えば、配信情報処理部２へ通知する。
【００２８】
一方、署名の検証が成功した場合には、ステップＳ１１１において、制御部２２は、ステップＳ１０４で取得したハッシュ値、及び現在検証中の通信データの署名と同じ組合せのデータが、記憶部５にあるかどうかを検索する。
その結果、ステップＳ１１２において、制御部２２は、同じ組合せのデータがある場合は、新鮮性の検証に失敗したものとしてステップＳ１１３へ進み、同じ組合せのデータがない場合には、新鮮性の検証に成功したものとしてステップＳ１１４へ進む。
次に、ステップＳ１１３において、制御部２２は、新鮮性の検証に失敗（新鮮性失敗）したことを、例えば、配信情報処理部２へ通知する。
【００２９】
一方、新鮮性の検証に成功した場合には、ステップＳ１１４において、制御部２２は、ステップＳ１０４で取得したハッシュ値と、現在検証中の通信データの署名の組合せを、記憶部５の認証情報履歴へ書き込む。
その後、ステップＳ１１３において、制御部２２は、通信データの検証が正常に終了したことを、例えば、配信情報処理部２へ通知して終了する。
【００３０】
なお、図７の処理フローは、新鮮性の検証と署名検証に着目しており、他の通信データの検証に必要な処理、例えば、証明書の検証などは、記載を省略している。
【００３１】
また、図６では、レジスタＡ２３、レジスタＢ２５、レジスタＣ２７を別のレジスタとして記載しているが、同一のレジスタであっても良い。また、ハッシュ値演算部２４や、署名検証部２６がソフトウェアで実現されている場合は、これらのレジスタは、メモリ領域、バッファなどに相当する。
【００３２】
また、図７の処理フローでは、署名の検証を行なった後に新鮮性の検証を行なっているが、署名の検証の前に新鮮性の検証を行なっても良い。そのようにすることで、新鮮性の検証に失敗した場合には、署名の検証を行なう必要がないので、全体として、通信データの検証失敗時の処理負荷を軽減することができる。
【００３３】
さらに、本発明は、デジタル署名のアルゴリズムや、そこで用いられるハッシュ関数のアルゴリズムであれば適用可能である。
【００３４】
以上のように、本実施の形態１の発明は、署名検証で行なわれるハッシュ関数の演算結果を、署名と共に新鮮性の検証にも用いることで、従来、新鮮性の検証のために行なっていたハッシュ関数の演算が不要となり、従来２回行なわれていたハッシュ関数の演算を１回に削減することができる。これにより、処理負荷を軽減することができる。
【００３５】
特に、ハッシュ関数の演算だけでなく、レジスタにライトする際にも時間を要するため、ハッシュ値演算部２４の出力レジスタと署名検証部２６の入力レジスタとを共用することで、更なる処理軽減が望める。
【００３６】
また、第一の認証情報７は、公開鍵証明書を識別するためのIDや、公開鍵証明書などの場合が想定される。従来技術では、通信データ全体に対してハッシュ値を計算しているため、攻撃者は、傍受した通信データの第一の認証情報７が公開鍵証明書であった場合にはIDに置き換えて、IDであった場合には公開鍵証明書に置き換えることで、全く同じ意味を持つ通信データであるのに対して、受信側に異なる通信データとして受け取らせることができる。つまり、受信側は、攻撃を受けたことを検知できない。
それに対して、本発明は、ハッシュ関数の入力は配信情報のみであり、第一の認証情報が置き換えられたとしても、同一の通信データであることを識別できる。
【００３７】
また、配信情報のハッシュ値と署名の組合せを新鮮性の検証に用いるため、デジタル署名が確率的暗号系の場合においては、同一の配信情報を受信側に受理させたいときには、同一の配信情報に対して、再度署名を生成し、それを用いて通信データを構成すれば、実現できる。また、新鮮性の検証に配信データのハッシュ値のみを用いることで、同様の効果を得ることもできる。
【００３８】
実施の形態２．
実施の形態１．では、データ認証としてデジタル署名を用いた場合について説明した。実施の形態２．では、データ認証として、ＭＡＣ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）を用いた場合について述べる。なお、図１、図２の説明は、実施の形態１．と同じであるため、省略する。
【００３９】
以下、図８、及び図９を用いて、通信装置１の認証処理部４の構成と、通信データ受信時の認証処理部４の処理フローについて説明する。
図８は、本発明の実施の形態２に係る認証処理部４の構成の一例を示す図である。
図９は、本発明の実施の形態２に係る通信データ受信時の認証処理部４の動作を示すフローチャートである。
【００４０】
まず、図８を用いて、認証処理部４の構成を説明する。
図８において、認証処理部４は、記憶部５、制御部２２、ＭＡＣ生成部２８、ＭＡＣ生成部２８への入力となるレジスタＡ２３、ＭＡＣ生成部２８からの出力となるレジスタＢ２５から構成される。なお、図８の認証処理部４は、配信情報を検証することに着目して記載しているため、通信データが暗号化されている場合には復号処理が認証処理部４に含まれるが、図８では省略している。
【００４１】
次に、図９を用いて、通信データ受信時の認証処理部４の処理フローを説明する。
まず、ステップＳ２０1において、制御部２２は、通信データの検証を行なう際に、ＭＡＣ生成部２８の入力レジスタＡ２３にＭＡＣ対象のデータである配信情報をライトする。
次に、ステップＳ２０２において、制御部２２は、ＭＡＣ生成部２８に対して演算開始を指示する。
次に、ステップＳ２０３において、ＭＡＣ生成部２８は、演算が終了すると演算結果をレジスタＢ２５にライトする。
【００４２】
次に、ステップＳ２０４において、制御部２２は、ＭＡＣ生成部２８の演算終了を、例えば、割り込みなどで検知し、レジスタＢ２５から演算結果をリードする。
その後、ステップＳ２０５において、制御部２２は、レジスタＢ２５から読み出した演算結果から、署名検証に成功しているか、失敗しているのかを判定し、成功している場合には、ステップＳ２０７へ進み、失敗している場合には、ステップＳ２０６へ進む。
次に、ステップＳ２０６において、制御部２２は、署名検証に失敗（真正性失敗）したことを、例えば、配信情報処理部２へ通知する。
【００４３】
一方、署名の検証が成功した場合には、ステップＳ２０７において、制御部２２は、通信データから取得したＭＡＣ値、もしくはステップＳ２０４で取得したＭＡＣ値（これらは同一の値である）と同じＭＡＣ値が、記憶部５にあるかどうかを検索する。
その結果、ステップＳ２０８において、制御部２２は、同じＭＡＣ値がある場合は、新鮮性の検証に失敗したものとしてステップＳ２０９へ進み、同じＭＡＣ値がない場合には、新鮮性の検証に成功したものとしてステップＳ２１０へ進む。
【００４４】
次に、ステップＳ２０９において、制御部２２は、新鮮性の検証に失敗（新鮮性失敗）したことを、例えば、配信情報処理部２へ通知する。
一方、新鮮性の検証に成功した場合には、ステップＳ２１０において、制御部２２は、ＭＡＣ値を記憶部５の認証情報履歴へ書き込む。
その後、ステップＳ２１１において、制御部２２は、通信データの検証が正常に終了したことを、例えば、配信情報処理部２へ通知して終了する。
【００４５】
なお、図９の処理フローは、新鮮性の検証と署名検証に着目しており、他の通信データの検証に必要な処理、例えば、セッション鍵の復号などは、記載を省略している。
【００４６】
また、図８では、レジスタＡ２３、レジスタＢ２５を別のレジスタとして記載しているが、同一のレジスタであっても良い。また、ＭＡＣ生成部２８がソフトウェアで実現されている場合は、これらのレジスタは、メモリ領域、バッファなどに相当する。
【００４７】
また、図９の処理フローでは、ＭＡＣの検証を行なった後に新鮮性の検証を行なっているが、ＭＡＣの検証の前に新鮮性の検証を行なっても良い。そのようにすることで、新鮮性の検証に失敗した場合には、ＭＡＣの検証を行なう必要がないので、全体として、通信データの検証失敗時の処理負荷を軽減することができる。
【００４８】
以上のように、新鮮性の検証で行なわれるハッシュ関数の演算をＭＡＣに置き換えることで、ハッシュ関数の演算自体を削減することができ、処理負荷を軽減することができる。
【符号の説明】
【００４９】
１  通信装置、２  配信情報処理部、３  通信部、４  認証処理部、５  記憶部、６  他の通信装置、７  第一の認証情報、８  配信情報、９  第二の認証情報、１０  路側機、１１  車載器Ａ、１２  車載器Ｂ、１３  車載器（優先車両）、１４  車載器Ｃ（悪意）、１５  車載器Ｄ（悪意）、１６  認証局、１７  路側機、１８  車載器、１９  公開鍵証明書Ａ、２０  配信情報、２１  配信情報の署名、２２  制御部、２３  レジスタＡ、２４  ハッシュ値演算部、２５  レジスタＢ、２６  署名検証部、２７  レジスタＣ、２８  ＭＡＣ生成部。
【図１】
2014196181.tif 000003
【図２】
2014196181.tif 000004
【図３】
2014196181.tif 000005
【図４】
2014196181.tif 000006
【図５】
2014196181.tif 000007
【図６】
2014196181.tif 000008
【図７】
2014196181.tif 000009
【図８】
2014196181.tif 000010
【図９】
2014196181.tif 000011
【手続補正書】
【提出日】平成27年11月12日(2015.11.12)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００２９
【補正方法】変更
【補正の内容】
【００２９】
一方、新鮮性の検証に成功した場合には、ステップＳ１１４において、制御部２２は、ステップＳ１０４で取得したハッシュ値と、現在検証中の通信データの署名の組合せを、記憶部５の認証情報履歴へ書き込む。その後、ステップＳ１１５において、制御部２２は、通信データの検証が正常に終了したことを、例えば、配信情報処理部２へ通知して終了する。
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
配信情報のハッシュ値を演算するハッシュ値演算部と、
他の通信装置から過去に受信した第一の認証情報と配信情報と第二の認証情報とを含む通信データの前記第二の認証情報の履歴を認証情報履歴として記憶し、前記ハッシュ値演算部により演算した配信情報のハッシュ値を前記認証情報履歴の前記第二の認証情報に対応付けて記憶する記憶部と、
新たに受信した通信データである新通信データの第一の認証情報により前記新通信データの第二の認証情報の真正性を検証するとともに、前記新通信データに含まれる配信情報のハッシュ値及び第二の認証情報と前記記憶部に記憶された前記認証情報履歴とを比較して前記新通信データの新鮮性を検証する認証処理部と
を備えたデータ認証装置。
【請求項２】
前記第二の認証情報は、公開鍵暗号に基づくデジタル署名である請求項１記載のデータ認証装置。
【請求項３】
前記第二の認証情報は、共通鍵暗号に基づくＭＡＣ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）である請求項１記載のデータ認証装置。
【請求項４】
配信情報のハッシュ値を演算するハッシュ値演算ステップと、
他の通信装置から過去に受信した第一の認証情報と配信情報と第二の認証情報とを含む通信データの前記第二の認証情報の履歴を認証情報履歴として記憶し、前記ハッシュ値演算ステップにより演算した配信情報のハッシュ値を前記認証情報履歴の前記第二の認証情報に対応付けて記憶する記憶ステップと、
新たに受信した通信データである新通信データの第一の認証情報により前記新通信データの第二の認証情報の真正性を検証するとともに、前記新通信データに含まれる配信情報のハッシュ値及び第二の認証情報と前記記憶ステップに記憶された前記認証情報履歴とを比較して前記新通信データの新鮮性を検証する認証処理ステップと
を備えたデータ認証方法。
【国際調査報告】
2014196181.tif 000012
2014196181.tif 000013
2014196181.tif 000014
2014196181.tif 000015