特許 7214838 証明書ステータスの決定方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-01-20

(45)【発行日】2023-01-30

(54)【発明の名称】証明書ステータスの決定方法

(51)【国際特許分類】

   H04L 9/08 20060101AFI20230123BHJP

【ＦＩ】

H04L9/08 C

H04L9/08 F

【請求項の数】 14

(21)【出願番号】P 2021510230

(86)(22)【出願日】2019-07-27

(65)【公表番号】

(43)【公表日】2021-12-23

(86)【国際出願番号】 CN2019098056

(87)【国際公開番号】W WO2020042844

(87)【国際公開日】2020-03-05

【審査請求日】2021-04-06

(31)【優先権主張番号】201810976472.9

(32)【優先日】2018-08-25

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】521486206

【氏名又は名称】ホアウェイ クラウド コンピューティング テクノロジーズ カンパニー リミテッド

【氏名又は名称原語表記】Ｈｕａｗｅｉ Ｃｌｏｕｄ Ｃｏｍｐｕｔｉｎｇ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．， Ｌｔｄ．

【住所又は居所原語表記】Ｈｕａｗｅｉ Ｃｌｏｕｄ Ｄａｔａ Ｃｅｎｔｅｒ，Ｊｉａｏｘｉｎｇｇｏｎｇ Ｒｏａｄ，Ｑｉａｎｚｈｏｎｇ Ａｖｅｎｕｅ， Ｇｕｉ’ａｎ Ｎｅｗ Ｄｉｓｔｒｉｃｔ， Ｇｕｉｚｈｏｕ，５５００２５，Ｃｈｉｎａ

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133569

【弁理士】

【氏名又は名称】野村 進

(72)【発明者】

【氏名】李 ▲飛▼

(72)【発明者】

【氏名】朱 ▲錦▼涛

(72)【発明者】

【氏名】何 承▲東▼

(72)【発明者】

【氏名】白 涛

【審査官】中里 裕正

(56)【参考文献】

【文献】米国特許出願公開第２００５／０２７８５３４（ＵＳ，Ａ１）

【文献】国際公開第２０１８／１５０５４６（ＷＯ，Ａ１）

【文献】特開２０１６－２２０２５９（ＪＰ，Ａ）

【文献】国際公開第２０１５／１１１１０７（ＷＯ，Ａ１）

【文献】米国特許第０５７４５５７４（ＵＳ，Ａ）

【文献】米国特許出願公開第２００９／０１８７９８３（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１１／０２５８４３５（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／０８

(57)【特許請求の範囲】

【請求項1】

受信側によって、送信側によって送信されたメッセージを受信するステップであって、前記メッセージは前記送信側の証明書を含み、前記送信側の前記証明書は分類情報を含む、ステップと、
前記送信側の前記証明書に含まれる前記分類情報に基づいて前記受信側によって、格納された証明書失効リスト内の失効識別子のセットを決定するステップであって、前記失効識別子は、前記証明書失効リスト内の失効した証明書を識別するために使用され、前記失効識別子は、前記失効した証明書の分類情報を含み、前記セット内の前記失効識別子に含まれる前記分類情報は、前記送信側の前記証明書に含まれる前記分類情報と同じである、ステップと、
前記受信側によって、前記送信側の前記証明書の特徴情報を抽出し、前記送信側の前記証明書の前記特徴情報を、前記セット内の前記失効識別子に対応する前記失効した証明書の特徴情報と照合し、照合結果に基づいて前記送信側の前記証明書のステータスを決定するステップと
を含む、証明書ステータス決定方法。

【請求項2】

失効識別子に含まれる特徴情報が、前記失効識別子に対応する前記失効した証明書の第1の定義済みフィールドに含まれるNバイトの乱数であり、Nは0より大きい正の整数であり、
前記受信側によって、前記送信側の前記証明書の特徴情報を抽出する前記ステップは、
前記受信側によって、前記送信側の前記証明書の前記第1の定義済みフィールドからNバイトの乱数をインターセプトし、前記乱数を前記送信側の前記証明書の前記特徴情報として使用するステップ
を特に含む、
請求項1に記載の方法。

【請求項3】

失効識別子に含まれる特徴情報が、前記失効識別子に対応する前記失効した証明書に対してハッシュ演算が実行された後に取得されるMバイトのハッシュ値であり、Mは0より大きい正の整数であり、
前記受信側によって、前記送信側の前記証明書の特徴情報を抽出する前記ステップは、
前記受信側によって、前記送信側の前記証明書に対してハッシュ演算を実行し、次に前記取得した前記Mバイトのハッシュ値を前記送信側の前記証明書の前記特徴情報として使用するステップ
を特に含む、
請求項1に記載の方法。

【請求項4】

前記送信側の前記証明書の前記分類情報が、前記送信側の前記証明書の第2の定義済みフィールドに含まれる、請求項1から3のいずれか一項に記載の方法。

【請求項5】

前記第2の定義済みフィールドが、前記送信側の前記証明書の証明書識別子フィールド、前記証明書の領域フィールド、または前記証明書の証明書失効シリーズフィールドである、請求項4に記載の方法。

【請求項6】

前記分類情報が、レベル1分類情報およびレベル2分類情報を含む、請求項1から5のいずれか一項に記載の方法。

【請求項7】

前記分類情報に基づいて前記受信側によって、格納された証明書失効リスト内の失効識別子のセットを決定する前記ステップが、
前記受信側によって、前記送信側の前記証明書の前記レベル1分類情報に基づいて、前記証明書失効リスト内の第1の失効識別子のセットを決定するステップであって、前記第1の失効識別子の前記セット内の失効識別子に含まれるレベル1分類情報は、前記送信側の前記証明書の前記レベル1分類情報と同じである、ステップと、
前記受信側によって、前記送信側の前記証明書の前記レベル2分類情報に基づいて、前記第1の失効識別子の前記セットの中の第2の失効識別子のセットを決定するステップであって、前記第2の失効識別子の前記セット内の失効識別子に含まれるレベル2分類情報は、前記送信側の前記証明書の前記レベル2分類情報と同じである、ステップと
を特に含む、請求項6に記載の方法。

【請求項8】

前記分類情報に基づいて前記受信側によって、格納された証明書失効リスト内の失効識別子のセットを決定する前記ステップの前に、前記方法が、前記受信側によって、証明書失効サーバから前記証明書失効リストを取得するステップをさらに含む、請求項1から7のいずれか一項に記載の方法。

【請求項9】

前記受信側によって、証明書失効サーバから前記証明書失効リストを取得する前記ステップが、
前記受信側によって、前記証明書失効サーバから完全な証明書失効リストを取得するステップと、
前記受信側によって、前記証明書失効サーバから差分の証明書失効リストを取得するステップであって、前記差分の証明書失効リストは、追加された証明書失効リストおよび削除された証明書失効リストを含み、前記追加された証明書失効リストは、前記完全な証明書失効リストと比較して、追加された失効識別子を含み、前記削除された証明書失効リストは、前記完全な証明書失効リストと比較して、削除された失効識別子を含む、ステップと、
前記受信側によって、前記差分の証明書失効リストに基づいて、前記格納されている完全な証明書失効リストをリフレッシュするステップと
を特に含む、請求項8に記載の方法。

【請求項10】

照合結果に基づいて、前記送信側の前記証明書のステータスを決定する前記ステップが、
前記受信側が、照合により、前記セット内の前記失効識別子に対応する前記失効した証明書の前記特徴情報に、前記送信側の前記証明書の前記特徴情報と同じ特徴情報があると判断した場合、前記受信側によって、前記送信側の前記証明書が失効していると決定するステップ
を特に含む、請求項1から9のいずれか一項に記載の方法。

【請求項11】

照合結果に基づいて、前記送信側の前記証明書のステータスを決定する前記ステップが、
前記受信側が、照合により、前記セット内の前記失効識別子に対応する前記失効した証明書の前記特徴情報に、前記送信側の前記証明書の前記特徴情報と同じ特徴情報がないと判断した場合、前記受信側によって、前記送信側の前記証明書が失効していないと決定するステップ
を特に含む、請求項1から9のいずれか一項に記載の方法。

【請求項12】

前記受信側または前記送信側が車載ユニットまたは路側ユニットである、請求項1から11のいずれか一項に記載の方法。

【請求項13】

通信インタフェース、メモリ、およびプロセッサを備えるビークルツーエブリシング通信ユニットであって、
前記通信インタフェースは、前記ビークルツーエブリシング通信ユニットの外部の装置またはデバイスと通信するように構成され、
前記メモリはプログラムを格納するように構成され、
前記プロセッサは、前記メモリに格納された前記プログラムを実行するように構成され、前記プログラムが実行されると、前記ビークルツーエブリシング通信ユニットは、請求項1から12のいずれか一項に記載の方法を実行する、
ビークルツーエブリシング通信ユニット。

【請求項14】

コンピュータ命令を含むコンピュータ可読記憶媒体であって、前記コンピュータ命令がコンピュータ上で実行されると、前記コンピュータは請求項1から12のいずれか一項に記載の方法を実行することが可能になる、コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、2018年8月25日に中国国家知識産権局に提出され、「CERTIFICATE STATUS DETERMINING METHOD」と題された中国特許出願第201810976472．9号の優先権を主張し、その全体が参照により本明細書に組み込まれる。

【0002】

本出願は、通信分野、特に、ビークルツーエブリシング分野におけるデバイス間の通信中の証明書ステータス決定方法、装置、およびシステムに関連する。

【背景技術】

【0003】

ビークルツーエブリシング（Vehicle to Everything，V2X）は、車両間、車両と歩行者もしくはライダとの間、または車両とインフラストラクチャとの間の通信システムである。ビークルツーエブリシング通信は、大量のメッセージと高いメッセージ送受信頻度を特徴としている。例えば、車載ユニット（on－board unit，OBU）または路側ユニット（road side unit，RSU）は、車両の走行状態（速度、向き、方向）を説明するための協調認識メッセージ（cooperative awareness message，CAM）を定期的に（例えば、10Hz）送信するか、または特別なイベントが発生した場合、イベントタイプを説明するための分散型環境通知メッセージ（Decentralized Environmental Notification Message，DENM）を送信する。

【0004】

セキュリティのために、証明書は通常、通信システムでデータソース認証を実行するために使用される。例えば、送信側は送信されたメッセージに証明書を追加し、受信側はメッセージに含まれている証明書を検証し、これには、証明書が失効しているかどうかの検証も含まれる。従来のインターネット通信分野では、OCSP解決策が使用されている。具体的には、クライアントはオンライン証明書ステータスプロトコル（Online Certificate Status Protocol，OCSP）を使用して、OCSPサーバで証明書が失効しているかどうかをリアルタイムで問い合わせる。

【0005】

ビークルツーエブリシング通信では、データソース認証にも証明書が必要である。しかし、従来のOCSP解決策は、ビークルツーエブリシング通信シナリオでは利用できない。例としてCAMメッセージが使用される。車両は1秒間に10個のCAMメッセージをブロードキャストする。理論的には、車両を中心として1km以内のすべての車両が、ブロードキャストCAMメッセージを受信する。OCSP解決策が使用される場合、CAMメッセージを受信する各車両は、各CAMメッセージの証明書をリアルタイムで問い合わせる必要がある。これは、OCSPサーバのパフォーマンスとネットワーク帯域幅に大きな負担をかける。さらに、車両とOCSPサーバとの間の通信により、ビークルツーエブリシング通信に余分な遅延が発生する。

【0006】

したがって、ビークルツーエブリシング通信におけるリアルタイムおよびセキュリティ要件を満たすために、証明書が失効しているかどうかを判断するためのより効率的な方法が緊急に必要とされている。

【発明の概要】

【発明が解決しようとする課題】

【0007】

ビークルツーエブリシング通信におけるリアルタイムおよびセキュリティ要件を満たすために、本出願は、メッセージ受信側が証明書ステータスを迅速に確認できるようにするための方法を提供する。本出願の証明書ステータスは、証明書が失効しているかどうかを示す。

【課題を解決するための手段】

【0008】

本出願の実施形態は、証明書失効リストに基づく解決策を提供する。この解決策では、証明書の分類情報と証明書の特徴情報という2つの概念が提案されている。証明書の分類情報とは、証明書の発行時に証明書発行サーバによって証明書に割り当てられたカテゴリ情報を指し、証明書の分類に使用される。証明書の特徴情報は、1つの証明書を一意に識別するために使用され得る情報を指す場合がある。証明書の特徴情報は、証明書の発行時に証明書発行サーバによって証明書に割り当てられたnバイトの乱数の場合もあれば、証明書に対してハッシュ計算が実行された後にインターセプトされたnバイトの値の場合もある。

【0009】

本出願のこの実施形態では、証明書の定義済みフィールドは、証明書の分類情報を含み、証明書失効リストの定義済みフィールドは、失効した証明書の分類情報を含む。さらに、証明書の特徴情報が、証明書の発行時に証明書発行サーバによって証明書に割り当てられたnバイトの乱数である場合、可能な実装において、証明書の特徴情報は、証明書の定義済みフィールドに含まれ得る。失効した証明書の分類情報を記録することに加えて、証明書失効リストには、定義済みフィールドに失効した証明書の特徴情報をさらに含める必要がある。

【0010】

証明書失効リストは、証明書失効サーバによって生成および維持される。受信側や送信側などのビークルツーエブリシング通信ユニットは、証明書失効サーバから証明書失効リストを取得する。メッセージを受信した後、受信側は、格納されている証明書失効リストに基づいてメッセージを送信する送信側の証明書を検証し、証明書のステータスを決定する。証明書の定義済みフィールドは証明書の分類情報を含み、証明書失効リストの定義済みフィールドは失効した証明書の分類情報を含むため、受信側は、送信側の証明書に含まれる分類情報に基づく証明書失効リストの大量のレコードの検索範囲または照合範囲をすばやく絞り込んで、証明書の検証の速度と効率を向上させることができる。特に、受信側は、証明書失効リストで、送信側の証明書と同じ分類情報を有する失効した証明書のレコードセットを決定し、そして、セット内で、送信側の証明書と同じ特徴情報を有する失効した証明書のレコードをさらに決定する。一致するレコードがある場合、送信側の証明書は失効している。一致するレコードがない場合、送信側の証明書は失効していない。

【0011】

さらに、本出願の実施形態は、証明書失効指紋ライブラリに基づく解決策をさらに提供する。証明書失効サーバは、失効した証明書の指紋情報を証明書失効指紋ライブラリに記録する。受信側や送信側などのビークルツーエブリシング通信ユニットは、証明書失効サーバから証明書失効指紋ライブラリを取得する。受信側は、メッセージを受信した後、メッセージを送信する送信側の証明書の指紋情報を抽出し、格納されている証明書失効指紋ライブラリに基づいてメッセージを送信する送信側の証明書を検証し、証明書のステータスを決定する。通信効率を改善するために、本出願のこの実施形態では、証明書失効サーバは、証明書失効指紋ロケーションライブラリを維持し、ある期間に証明書失効指紋ライブラリに記録された変更を格納する。ビークルツーエブリシング通信ユニットは、証明書失効指紋ロケーションライブラリを取得して、格納されている証明書失効指紋ライブラリをリフレッシュする。証明書失効指紋ライブラリに基づく解決策の精度を向上させるために、本出願のこの実施形態は、受信側の誤検知を回避するために、証明書が失効しているかどうかを送信側が自己検証し、メッセージに含まれる証明書が証明書失効指紋ライブラリに一致するレコードがない証明書であることを保証する解決策をさらに提案する。

【0012】

本出願の特許請求の範囲に記載された方法と協力するために、受信側はまた、本出願の実施形態における証明書ステータス決定方法をサポートするために、対応する改善を行う必要がある。

【0013】

証明書失効リストに基づく解決策では、送信側から受信側に送信されるメッセージは、送信側の証明書を含む。送信側の証明書は分類情報を含んでいるため、受信側は送信側の証明書の分類情報を証明書失効リスト内の失効した証明書の分類情報と照合し、照合結果に基づいて送信側の証明書のステータスを決定し得る。

【0014】

証明書失効指紋ライブラリに基づく解決策では、送信側は、格納されている証明書失効指紋ライブラリに基づいて、証明書失効指紋ライブラリに一致するレコードがない証明書を決定し、送信されたメッセージで選択された証明書を使用する。

【0015】

可能な実装では、送信側は、送信側の任意の証明書の指紋情報を計算する。送信側が、証明書失効指紋ライブラリに証明書の指紋情報と一致する指紋情報がないと判断した場合、送信側は送信されたメッセージの証明書を使用する。

【0016】

別の可能な実装では、送信側は、送信側の任意の証明書の指紋情報を計算する。送信側が、証明書失効指紋ライブラリに証明書の指紋情報と一致する指紋情報があると判断した場合、送信側は、その証明書とは異なる第2の証明書を選択し、第2の証明書の指紋情報の計算を続行し、証明書失効指紋ライブラリに第2の証明書の指紋情報と一致する指紋情報があるかどうかを判断する。

【0017】

本出願の実施形態における方法は、受信側、送信側、証明書失効サーバ、およびビークルツーエブリシングサーバなどの装置に関する。したがって、本出願の実施形態は、前述の証明書検証方法を実施するための装置およびサーバをさらに提供する。

【0018】

さらに、本出願の実施形態は、コンピュータ可読記憶媒体をさらに提供する。コンピュータ可読記憶媒体は、命令を格納する。命令がコンピュータ上で実行されると、コンピュータは前述の証明書検証方法を実行できるようになる。

【0019】

最後に、本出願は、命令を含むコンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータ上で実行されると、コンピュータは前述の証明書検証方法を実行できるようになる。

【図面の簡単な説明】

【0020】

【図1】本出願の一実施形態による、ビークルツーエブリシングシステムのアーキテクチャ図である。

【図2】本出願の一実施形態による、ビークルツーエブリシング通信方法のフローチャートである。

【図3】本出願の一実施形態による証明書の分類の概略構造図である。

【図4】本出願の一実施形態による証明書失効方法のフローチャートである。

【図5】本出願の一実施形態による、証明書失効サーバから失効した証明書情報を取得するための方法のフローチャートである。

【図6】証明書失効指紋ライブラリのデータ構造の概略図である。

【図7】本出願の一実施形態による、証明書を自己検証するためのビークルツーエブリシング通信方法のフローチャートである。

【図8】本出願の一実施形態による証明書ステータス確認方法のフローチャートである。

【図9】本出願の一実施形態による装置の概略構造図である。

【発明を実施するための形態】

【0021】

ビークルツーエブリシング通信におけるリアルタイムおよびセキュリティ要件を満たすために、本出願の実施形態は、証明書が従来技術よりも高い効率で失効しているかどうかを判断するための方法を提供する。本出願の実施形態における証明書は、通信分野で使用されるデジタル証明書であることに留意されたい。

【0022】

図1は、本出願の一実施形態による、ビークルツーエブリシングシステムのアーキテクチャを示している。このシステムは、証明書発行サーバ、証明書失効サーバ、ビークルツーエブリシングサーバ、およびビークルツーエブリシング端末を含む。ビークルツーエブリシング端末はまた、ビークルツーエブリシング装置またはデバイス、例えば、車載ユニット、路側ユニット、または歩行者によって運ばれる通信装置であり得る。ビークルツーエブリシング端末は、証明書発行サーバから証明書を取得し、証明書失効サーバから証明書失効リスト（Certificate Revocation List，CRL）を直接的または間接的に取得する。CRLは、失効した証明書に関する情報を記録するために、証明書失効サーバによって生成される。ビークルツーエブリシング端末は、ビークルツーエブリシング端末のステータス、実行情報、および例外情報をビークルツーエブリシングサーバに報告する。ビークルツーエブリシングサーバは、証明書失効サーバにビークルツーエブリシング端末の証明書を失効させるように直接要求するか、または証明書発行サーバを使用して証明書失効サーバにビークルツーエブリシング端末の証明書を失効させるように要求することができる。

【0023】

図2は、本出願の実施形態による、ビークルツーエブリシング通信サービス手順の概略図である。通信手順は、異なる通信の役割に基づいて送信側と受信側として使用される2つのビークルツーエブリシング端末、装置、またはデバイスを含む。

【0024】

送信側は、ステップ101で送信されたメッセージに送信側の証明書を追加する。送信側から送信される証明書は、分類情報を含む。分類情報は、証明書の発行時に証明書発行サーバから証明書に割り当てられるカテゴリ情報であり、証明書の分類に使用される。本出願では、分類ディメンションは制限されない。地理的な向きがディメンションとして使用され得る。例えば、証明書発行サーバの地理的な向きが分類情報として使用される。あるいは、管理領域がディメンションとして使用されてもよい。例えば、証明書発行サーバの管理領域が分類情報として使用される。本出願では、分類情報のフォーマットと長さに制限はない。分類情報は、複数のレベルを含むマルチレベル分類情報であり得るか、または1レベル分類情報であり得る。分類情報は、複数の方法で伝達され得る。本出願のこの実施形態では、IEEE 1609．2規格で定義されたビークルツーエブリシング証明書フォーマットが、証明書内の分類情報を伝達するいくつかの可能な方法をリストするための例として使用される。
IEEE1609．2 CertificateBase｛
…
toBeSigned｛
id，
cracaId，
crlSeries，
region，
…｝
…，
｝

【0025】

方法1：分類情報は、証明書識別子IDフィールドを使用して伝達される。例として、2レベルの分類情報が使用される。証明書識別子IDフィールドのフォーマットは、「レベル1分類情報｜レベル2分類情報｜特徴情報」として定義され、ここで、「｜」は連結演算子である。証明書発行サーバの管理領域が分類情報として使用される場合、レベル1分類情報は、証明書発行サーバが位置する州に関する情報であり得、レベル2分類情報は、証明書発行サーバが位置する都市に関する情報であり得る。方法1では、特徴情報は、証明書が生成されるときに証明書発行サーバによって証明書に割り当てられ、かつ証明書を識別するために使用される情報であり、特徴情報は、証明書の任意の定義済みフィールドに記録され得る。可能な実装において、特徴情報は、乱数発生器を使用することによって生成されるnバイトの2進数であり得る。方法1では、分類情報が異なる2つの証明書の特徴情報が同じである可能性がある。レベル1分類情報の長さが1バイト、レベル2分類情報の長さが1バイト、nは1であると想定すると、証明書のIDの可能な値は「100010000001000111111110」であり、ここで、「10001000」は証明書のレベル1分類情報、「00010001」は証明書のレベル2分類情報、「11111110」は乱数である。

【0026】

方法2：分類情報はregionフィールドを使用して伝達される。Regionフィールドのフォーマットは、「レベル1分類情報｜レベル2分類情報」として定義される。

【0027】

方法3：分類情報は、crlSeries証明書失効シリーズフィールドを使用して伝達されるか、または分類情報は、cracaId証明書失効サーバ識別子とcrlSeriesフィールドを使用して伝達される。例えば、crlSeriesフィールドのフォーマットは、「レベル1分類情報｜レベル2分類情報」として定義される。あるいは、レベル1分類情報はcracaIdフィールドを使用して伝達され、レベル2分類情報はcrlSeriesフィールドを使用して伝達される。例えば、cracaIdフィールドは、証明書の失効を担当する証明書失効サーバの識別子を記録し、レベル1分類情報として使用される。crlSeriesフィールドは、証明書が失効するたびに証明書が属するCRLシリーズを記録し、レベル2分類情報として使用される。

【0028】

メッセージを処理する前に、ステップ102において、受信側は、最初に、ローカルに格納された証明書失効リストCRLに基づいて、証明書が失効しているかどうかを検証する。証明書が失効している場合、受信側はメッセージを直接破棄する。証明書を検証する前に、受信側は証明書失効サーバからCRLを直接または間接的に取得する。証明書に含まれる分類情報に対応して、受信側にローカルに格納されているCRLも、失効した証明書の分類情報を記録する必要がある。加えて、CRLは、失効した証明書の特徴情報をさらに記録する必要がある。失効した証明書の分類情報をCRLに記録するフィールドは、任意のフィールドであってよい。本出願では、説明を簡単にするために、失効した証明書の分類情報を記録するフィールドは一律に失効識別子と呼ばれ、失効識別子は、CRL内の1つの失効した証明書を一意に識別するために使用される。以下は、IEEE1609．2規格で定義されているCRLフォーマットである。失効識別子機能を有するフィールドは、CRLのIDフィールドであると想定される。さらに、IDフィールドは、失効した証明書の特徴情報を記録すると想定される。確かに、失効した証明書の特徴情報を記録するために、失効識別子フィールドとは異なる別のフィールドが選択されてもよい。
CrlContents：：＝SEQUENCE｛
…
typeSpecific CHOICE｛
…
entries SequenceOfHashBasedRevocationInfo｛
id，
…，
｝
｝
…，
｝
｝

【0029】

例として、2レベルの分類情報が使用される。CRLのIDフィールドのフォーマットは、「レベル1分類情報｜レベル2分類情報｜失効した証明書の特徴情報」として定義され、ここで、「｜」は連結演算子である。証明書の特徴情報は、nバイトの乱数の場合もあれば、証明書に対してハッシュ計算が実行された後にインターセプトされたnバイトの値の場合もあり、証明書の特徴情報は1つの証明書を一意に識別するために使用される。失効した証明書の特徴情報がnバイトの乱数である場合、nバイトの乱数は、失効した証明書の定義済みフィールドから抽出された情報であり得る。例えば、証明書が分類情報を含んでいる方法1に対応して、失効した証明書の識別子からnバイトの乱数がインターセプトされる。レベル1分類情報は、失効した証明書の証明書発行サーバが位置する州に関する情報であり得、レベル2分類情報は、失効した証明書の証明書発行サーバが位置する都市に関する情報である場合があり得る。レベル1分類情報の長さが1バイト、レベル2分類情報の長さが1バイト、nは1であると想定すると、CRL内のIDの可能な値は「100010000001000111111110」であり、ここで、「10001000」は失効した証明書のレベル1分類情報、「00010001」はレベル2分類情報、「11111110」は失効した証明書の識別子からインターセプトされた乱数である。

【0030】

前述の定義に基づいて、図2のステップ102で証明書を検証するとき、受信側は、送信側の証明書が失効しているかどうかを判断するために、受信した証明書に含まれる分類情報および受信した証明書の抽出された特徴情報を、CRL内の失効識別子と迅速かつ効率的に照合することができる。図3に示されるように、CRLリストに記録された失効識別子は、分類情報に基づいて、異なるセットおよびサブセットに分類され得る。受信側が受信した証明書に含まれるIDの値は「100010000001000111111110」であると想定される。受信側にローカルに格納されているCRLでは、失効識別子のレベル1分類情報は、レベル1分類情報－1とレベル1分類情報－2の2つのカテゴリに分類され得る。レベル1分類情報－1の値は「10001000」である。証明書が失効しているかどうかを受信側が検証する場合、レベル1分類情報がレベル1分類情報－1である失効識別子のみを照合して検索する必要がある。次に、受信側は、受信した証明書のIDに含まれるレベル2分類情報「00010001」に基づいて照合および検索範囲を絞り込み続け、レベル1分類情報は「00010001」の失効識別子である。同様に、マルチレベル分類情報がある場合、受信側は、異なるレベルの分類情報に基づいて、照合および検索が必要な範囲を徐々に絞り込み、最終的に、証明書の特徴情報に基づいて照合および検索が必要なサブセットを決定し、受信した証明書の特徴情報と失効識別子に含まれる特徴情報を照合する。一致するレコードがある場合、受信した証明書は失効していると判断される。一致するレコードがない場合、受信した証明書は失効していないと判断される。受信した証明書の分類情報がCRLにない場合は、受信した証明書が失効していないと直接判断される場合がある。

【0031】

本出願のこの実施形態では、受信側が受信した証明書の特徴情報の定義に同意する必要があり、失効した証明書の特徴情報であり、かつCRLの失効識別子に記録されている特徴情報の定義と一致していることに留意されたい。失効した証明書の特徴情報であり、CRLの失効識別子に記録されている特徴情報が、失効した証明書の識別子の指定された場所でのnバイトの乱数として定義されている場合、受信側は、証明書を検証するときに、受信した証明書の識別子から指定された場所でのnバイトの乱数を抽出する。失効した証明書の特徴情報であり、CRLの失効識別子に記録されている特徴情報が、失効した証明書に対してハッシュ計算が実行された後、指定された場所でのnバイトをインタープリトするものとして定義されている場合、受信側は、証明書を検証するときに、受信した証明書に対してハッシュ計算が実行された後、指定された場所でのnバイトをインターセプトする。

【0032】

前述の実施形態の方法から、証明書およびCRL失効識別子は分類情報を含み、証明書が失効しているかどうかを検証する際に、受信側は分類情報に基づいて検索および照合範囲を絞り込むことができることがわかる。大量のレコードがCRLに格納されている場合、受信側で証明書を検証する計算ワークロードが大幅に削減され得、証明書の検証の速度と効率が向上し、ビークルツーエブリシング通信のリアルタイムサービス要件が満たされる。

【0033】

図2の実施形態に記載されているように、CRLは、証明書失効サーバによって生成される。図4は、証明書失効サーバが証明書を失効させ、分類情報を含む失効識別子をCRLに追加する方法の概略フローチャートである。

【0034】

301および302：受信側が、ビークルツーエブリシングメッセージを受信し、ビークルツーエブリシングメッセージは、メッセージを送信する送信側の証明書を含む。受信側は例外があると判断し、例外には次のものが含まれる：メッセージの送信頻度が高すぎること、メッセージに含まれる署名情報が誤って検証されていること、または証明書が有効期間内にない。例外が発生した場合、証明書を含むビークルツーエブリシングメッセージがビークルツーエブリシングサーバに送信され、ビークルツーエブリシングサーバにセキュリティの決定と処理をさらに実行するように要求する。

【0035】

303：ビークルツーエブリシングサーバは、証明書を含むビークルツーエブリシングメッセージを受信し、ローカルポリシーに従って決定および意思決定を実行し、証明書を失効させる必要があると判断し、証明書失効サーバにメッセージを送信し、証明書失効サーバに証明書を失効させるように要求し、ここで、メッセージは証明書を運ぶ。ビークルツーエブリシングサーバは、証明書失効サーバにメッセージを直接送信して証明書の呼び出しを要求し得るか、または証明書発行サーバを使用してメッセージを証明書失効サーバに送信して、証明書を呼び出すように要求し得ることに留意されたい。例えば、ビークルツーエブリシングサーバに証明書失効サーバへの書き込み権限が付与されていない場合、ビークルツーエブリシングサーバは、証明書発行サーバを使用してメッセージを証明書失効サーバに送信する必要がある。

【0036】

304：証明書失効サーバは、ビークルツーエブリシングサーバの要求に基づいて失効識別子レコードをCRLに追加し、証明書のフォーマットに基づいて証明書の分類情報と特徴情報を抽出し、証明書の分類情報を追加された失効識別子に書き込む。証明書失効サーバが証明書の分類情報を抽出する方法は、図2に示される実施形態で説明される分類情報を伝達する方法に対応する。特に、図2に示す実施形態に記載の分類情報を伝達する3つの方法に対応して、証明書失効サーバは、証明書のIDフィールド、領域フィールド、またはcrlSeriesフィールドの分類情報を抽出し、その分類情報をCRLの追加された失効識別フィールドの分類情報として使用する。証明書失効サーバが証明書の特徴情報を抽出する方法は、図2に示される実施形態で説明される証明書のフォーマットに対応する。IDフィールドなどの証明書の定義済みフィールドに含まれるnバイトの乱数が証明書の特徴情報として使用される場合、証明書失効サーバは、証明書の定義済みフィールドからnバイトの乱数を抽出し、失効した証明書の特徴情報として乱数を使用する。その他の場合、証明書に対してハッシュ計算が実行された後、失効した証明書の特徴情報としてnバイトがインターセプトされる。失効識別子フィールドに分類情報と特徴情報の両方が記録される場合、情報は、「分類情報｜失効した証明書の特徴情報」のフォーマットで記録される。

【0037】

証明書の特徴情報と、失効した証明書の特徴情報であり、かつCRLに記録されている特徴情報とがそれぞれハッシュ値である場合、受信側と証明書失効サーバで使用されるハッシュアルゴリズムは一致している必要があることに留意されたい。特に、ステップ102で受信した証明書に対してハッシュ計算を実行するために受信側によって使用されるハッシュアルゴリズムは、ステップ304で失効した証明書に対してハッシュ計算を実行するために証明書失効サーバによって使用されるハッシュアルゴリズムと一致する。

【0038】

任意選択で、ステップ304で証明書失効サーバによって実行される証明書情報を抽出するための方法は、ステップ303で証明書を呼び出す要求が送信される前に、ビークルツーエブリシングサーバによってさらに実行され得る。言い換えれば、ステップ303の代替解決策として、ビークルツーエブリシングサーバは、証明書を含むビークルツーエブリシングメッセージを受信し、ローカルポリシーに従って決定および意思決定を実行し、証明書を失効させる必要があると決定する。ビークルツーエブリシングサーバは、証明書の分類情報と特徴情報を抽出し、証明書の抽出された分類情報および抽出された特徴情報を証明書失効サーバに送信して、証明書失効サーバに証明書の失効を要求する。

【0039】

上記は、図4のステップを参照して、失効した証明書をCRLに追加する手順を説明している。失効した証明書の記録は変化し続けるため、証明書失効サーバからCRLを取得した後、ビークルツーエブリシング通信ユニットはさらに、証明書失効サーバからCRLの変更情報を取得し、ローカルに格納されたCRLを更新する必要がある。

【0040】

図5は、本発明の実施形態による、ビークルツーエブリシング通信ユニットによってCRLを取得するための方法の概略フローチャートである。ステップ401に示すように、ビークルツーエブリシング通信ユニットは、事前設定されたトリガ条件に従って、証明書失効サーバからCRLを取得するようにアクティブに要求することができる。あるいは、証明書失効サーバは、事前設定されたポリシーまたはルールに従って、CRLをビークルツーエブリシング通信ユニットに直接ブロードキャストまたはユニキャストすることができる。具体的には、402のメッセージは、401のメッセージへの応答であってもよく、メッセージは、代替的に、証明書失効サーバによってアクティブにプッシュされたメッセージであってもよい。ステップ403および404に示されるように、ビークルツーエブリシング通信ユニットは、代替的に、別のビークルツーエブリシング通信ユニットからCRLを間接的に取得することができることに留意されたい。ビークルツーエブリシング通信ユニット2は、CRLを取得するビークルツーエブリシング通信ユニット1からCRLを取得することができ、404のメッセージは、403の要求への応答であり得る。あるいは、ビークルツーエブリシング通信ユニット1は、ブロードキャストまたはユニキャスト方式で、CRLをビークルツーエブリシング通信ユニット2にアクティブにプッシュすることができる。

【0041】

ビークルツーエブリシング通信ユニットがCRLを取得することをアクティブに要求するためのトリガ条件は、車両イグニッションが開始されるようなイベントトリガであってもよく、または定期的なタイマーが切れるような定期的なトリガであってもよく、または所定の領域もしくは所定の速度閾値に達するような特定の条件トリガであってもよい。

【0042】

証明書失効サーバまたはビークルツーエブリシング通信ユニットによって402または404のメッセージに含まれるCRLは、完全CRLまたは差分CRLの場合がある。完全CRLは、証明書失効サーバによって失効されたすべての証明書に関する情報を含み、差分CRLは、追加されたCRLと削除されたCRLの2つのリストを含む。追加されたCRLは、期間の終了時点に対応する完全CRLと、期間の開始時点に対応する完全CRLを比較することにより、ある期間に追加された失効した証明書に関する情報のみを含む。削除されたCRLは、期間の終了時点に対応する完全CRLと、期間の開始時点に対応する完全CRLを比較することにより、ある期間に低減された失効した証明書に関する情報のみを含む。差分更新解決策を使用する場合、最初に完全CRLを取得した後、ビークルツーエブリシング通信ユニットは、その後402または404のメッセージで差分CRLを取得し、ビークルツーエブリシング通信ユニットは、追加されたCRLと削除されたCRLの2つのリストに基づいて、ローカルに格納されたCRLをリフレッシュする必要がある。完全更新解決策が使用される場合、ビークルツーエブリシング通信ユニットは402または404のメッセージで完全CRLを取得し、ビークルツーエブリシング通信ユニットはローカルに格納されたCRLを受信した完全CRLに直接置き換える。

【0043】

前述の実施形態は、証明書失効サーバが、失効した証明書の分類情報および特徴情報を含むCRLを生成する方法、ビークルツーエブリシング通信ユニットが、証明書失効サーバから失効した証明書の分類情報および特徴情報を含むCRLを取得する方法、およびビークルツーエブリシング通信ユニットが、メッセージから証明書の分類情報と特徴情報を抽出し、分類情報と特徴情報をCRLのレコードと照合して、メッセージを受信するときにメッセージに含まれている証明書が失効しているかどうかを判断する方法について説明する。

【0044】

ビークルツーエブリシング端末の数が多く、ビークルツーエブリシングシステムで発行される証明書の数も多いため、それに応じて、失効した証明書の数も比較的多い。前述のCRL解決策に加えて、本出願のこの実施形態は、証明書失効指紋ライブラリに基づく解決策をさらに提案し、これにより、失効した証明書に関する情報をビークルツーエブリシング通信ユニットのストレージスペースに格納することによって引き起こされる影響を低減する。証明書失効指紋ライブラリは、長さがNで、0に初期化されるバイナリ配列である。証明書失効指紋ライブラリは、失効した証明書の指紋情報を記録する。失効した証明書の指紋情報は、長さがNのバイナリ配列において値が1であるビット情報であり、Nが0より大きい正の整数である。失効した証明書の指紋情報は、複数のアルゴリズムを使用して失効した証明書を計算することによって取得され得る。例えば、失効した証明書の指紋情報は、ハッシュ計算を実行することによって取得され得る。

【0045】

図6に示されるように、証明書失効指紋ライブラリは、長さが16で、0に初期化されるバイナリ配列であると想定される。図4に示す手順のステップ304において、証明書失効サーバが失効した証明書を記録する必要がある場合、証明書失効サーバは、3つのハッシュ関数を使用することによって、失効した証明書に対して別々にハッシュ計算およびマッピングを実行する（例えば、ハッシュ計算結果を使用して、指紋ライブラリ内のバイナリ配列の長さに対してモジュロ演算を実行する）。マッピングごとに値が生成される。各値は、バイナリ配列の1ビットに対応する。対応するビットが1に設定される。値が1である3ビットに関する情報は、失効した証明書の指紋情報である。

【0046】

図2に示される方法手順では、受信側は、証明書を含むビークルツーエブリシングメッセージを受信し、証明書の指紋情報を計算し、証明書失効指紋ライブラリ内の証明書の指紋情報と照合する。同じ指紋情報がある場合、証明書は失効している。証明書のフォーマットは、分類情報を含み、かつ本出願の実施形態に記載されているフォーマットであり得るか、または別のフォーマットであり得ることに留意されたい。

【0047】

図5に示される方法手順では、ビークルツーエブリシング通信ユニットは、ステップ402または404で証明書失効指紋ライブラリを取得する。証明書失効指紋ライブラリは、すべての失効した証明書の指紋情報を含む完全な証明書失効指紋ライブラリである場合もあれば、差分の証明書失効指紋ロケーションライブラリである場合もある。差分の証明書失効指紋ロケーションライブラリは、期間の終了時点に対応する完全な証明書失効指紋ライブラリと、期間の開始時点に対応する完全な証明書失効指紋ライブラリを比較することにより、期間内に変化するビット情報を記録する。

【0048】

例えば、証明書失効サーバに記録された完全な証明書失効指紋ライブラリが、2つの失効した証明書AおよびBの指紋を含む場合、指紋の長さは10、Aの指紋は「0010010001」、Bの指紋は「0001110000」、完全な証明書失効指紋ライブラリは「0011110001」である。ステップ304で失効した証明書Cが追加される必要がある場合、一般的な指紋ライブラリ「0011110001」と比較することにより、Cの指紋は「1100001000」であると想定され、右から4番目、9番目、10番目のビットの値がそれぞれ0から1に変化することがわかる。この場合、4番目、9番目、10番目のビットの値の変更は、差分の証明書失効指紋ロケーションライブラリに記録され、本出願では特定の記録方法に限定されない。変化するビットは、バイナリ配列の形式で1に設定され得るか、列挙型または配列の形式で設定され得、変化するビットのシーケンス番号のみが記録される。証明書Bの指紋が完全な証明書失効指紋ライブラリから削除される必要がある場合、更新された完全な証明書失効指紋ライブラリは「0010010001」である。変化するビットは右から6番目と7番目のビットであり、6番目と7番目のビットの値の変化は差分の証明書失効指紋ロケーションライブラリに記録される。

【0049】

差分の証明書失効指紋ロケーションライブラリが受信される場合、ビークルツーエブリシング通信ユニットは、差分の証明書失効指紋ロケーションライブラリに記録されたビット情報に基づいて、ローカルに格納された証明書失効指紋ライブラリ内の対応するビットの値に対して否定演算を実行して、最新の証明書失効指紋ライブラリを取得する。完全な証明書失効指紋ライブラリが受信される場合、ローカルに格納されている証明書失効指紋ライブラリが置き換えられる。

【0050】

証明書失効指紋ライブラリの1は、特定の失効した証明書にバインドされていない。したがって、ビークルツーエブリシング通信ユニットがステップ102で証明書を検証するとき、誤検知があり得る。例えば、証明書失効指紋ライブラリが大量の指紋情報を記録するとき、証明書失効指紋ライブラリでは、1つの確認対象証明書の指紋情報に対応するビットがすべて1に設定され得、これらのビットは、失効した証明書の同じ指紋に必ずしも対応するものではない。

【0051】

送信側として、ステップ101でメッセージを送信する前に、受信側の誤検知による送信側によって送信されたメッセージの破棄を回避するために、ビークルツーエブリシング通信ユニットは、図7のステップ100に示されるように、最初にローカルに格納された証明書失効指紋ライブラリを使用して、証明書の指紋情報が証明書失効指紋ライブラリに一致するレコードを有するかどうかを自己検証し、メッセージが証明書失効指紋ライブラリに一致するレコードがない証明書を含んでいることを保証する。一般に、証明書発行サーバは、ビークルツーエブリシング通信ユニットに一度に複数の証明書を発行する。ビークルツーエブリシング通信ユニットは、これらの証明書から、証明書失効指紋ライブラリに一致するレコードがない証明書を1つ選択する。ローカルで利用可能な証明書がない場合、ビークルツーエブリシング通信ユニットは、証明書のための証明書発行サーバに再適用する。

【0052】

受信側として、ステップ102において、証明書失効指紋ライブラリ内のメッセージに証明書の指紋情報があると判断した場合、誤検知を回避するために、ビークルツーエブリシング通信ユニットは、図8のステップ103に示されるように、証明書失効サーバに、証明書を検証するように要求し、要求メッセージは、証明書または証明書に関する情報を含む。証明書失効サーバは、失効した証明書の指紋情報だけでなく、CRLなどの情報も格納する。したがって、証明書失効サーバの検証結果はより正確になる。ビークルツーエブリシング通信ユニットは、受信側として、ステップ104で証明書失効サーバによって返された検証結果に基づいて、最終的にV2Xメッセージを処理する。証明書失効サーバから返された検証結果が、証明書が失効していないことを示している場合、受信側はV2Xメッセージの処理を続行する。証明書失効サーバから返された検証結果が、証明書が失効していることを示している場合、受信側はV2Xメッセージを破棄する。

【0053】

本出願の実施形態における証明書失効リストに基づく解決策および証明書失効指紋ライブラリに基づく解決策の両方は、ビークルツーエブリシング通信におけるビークルツーエブリシング端末またはビークルツーエブリシング通信ユニットによる証明書の検証の効率および速度を改善することを目的とし、これにより、メッセージ処理のリアルタイムのパフォーマンスが向上し、証明書の検証がビークルツーエブリシング端末またはビークルツーエブリシング通信ユニットのパフォーマンスに与える影響が低減する。証明書失効リストに基づく解決策と比較して、証明書失効指紋ライブラリ解決策は、ビークルツーエブリシング端末またはビークルツーエブリシング通信ユニットのストレージスペースに対する要件が低くなっている。ビークルツーエブリシング端末またはビークルツーエブリシング通信ユニットは、証明書失効指紋ライブラリを格納するために少量のストレージスペースを占有するだけで済む。ただし、証明書失効指紋ライブラリに基づく解決策には、特定の誤検知の可能性があり得る。したがって、受信側による証明書の検証に加えて、証明書の検証の精度を向上させるために追加の処理が必要になる。

【0054】

証明書失効リストに基づく解決策と証明書失効指紋ライブラリに基づく解決策は、個別に適用されることも、組み合わせて適用されることもできることに留意されたい。2つの解決策が組み合わされて適用される場合、証明書のフォーマットは、分類情報を含み、かつ証明書失効リストに基づく解決策に記述されているフォーマットである。証明書失効サーバはCRLと証明書失効指紋ライブラリの両方を格納し、ビークルツーエブリシング通信ユニットは証明書失効指紋ライブラリのみを格納する。2つの解決策が組み合わされて適用されるシナリオでは、次のようになる。

【0055】

ステップ304において、証明書失効サーバは、証明書失効リストに基づく解決策および証明書失効指紋ライブラリ解決策に基づく解決策に基づいて、それぞれ、CRLおよび証明書失効指紋ライブラリをリフレッシュする。

【0056】

ステップ402またはステップ404において、ビークルツーエブリシング通信ユニットは、ストレージスペースの消費を削減するために、証明書失効指紋ライブラリのみを取得して格納する。

【0057】

ステップ102において、ビークルツーエブリシング通信ユニットは、証明書失効指紋ライブラリに基づく解決策を使用することによって証明書を検証する。

【0058】

ステップ103および104において、検証精度を改善するために、ビークルツーエブリシング通信ユニットは、証明書失効サーバに証明書を検証するように要求し、証明書失効サーバは、CRLリストを使用して証明書を迅速に検証する。

【0059】

上記は、方法手順の観点から、本発明の実施形態で提供される解決策を主に説明している。前述の機能を実施するために、ビークルツーエブリシング通信ユニット、ビークルツーエブリシングサーバ、および証明書失効サーバなどのエンティティは、機能を実行するための対応するハードウェア構造および／またはソフトウェアモジュールを含むことが理解され得る。さらに、本出願の実施形態で説明されるビークルツーエブリシングサーバおよび証明書失効サーバは、別個の物理デバイスであり得るか、または同じ物理デバイス内の異なる論理機能エンティティであり得る。具体的には、本出願の実施形態におけるビークルツーエブリシングサーバおよび証明書失効サーバの機能は、同じ物理デバイスに実装され得る。当業者は、本明細書に開示された実施形態を参照して説明された方法手順が、本発明のハードウェアまたはハードウェアとコンピュータソフトウェアの組み合わせによって実施され得ることを容易に認識すべきである。機能がハードウェアによって実行されるか、コンピュータソフトウェアによって駆動されるハードウェアによって実行されるかは、特定のアプリケーションおよび技術的解決策の設計上の制約に依存する。当業者は、特定の各アプリケーションのために説明した機能を実装するために異なる方法を使用することができるが、実装が本発明の範囲外であると考えられるべきではない。

【0060】

例えば、前述の実施形態におけるビークルツーエブリシング通信ユニット、ビークルツーエブリシングサーバ、および証明書失効サーバはすべて、図9に示される装置によって実装され得る。

【0061】

装置500は、少なくとも1つのプロセッサ501、通信バス502、メモリ503、および少なくとも1つの通信インタフェース504を含む。

【0062】

プロセッサ501は、汎用中央処理装置（central processing unit，CPU）、マイクロプロセッサ、特定用途向け集積回路（application－specific integrated circuit，ASIC）、または本発明の解決策のプログラム実行を制御するように構成された1つまたは複数の集積回路であり得る。

【0063】

通信バス502は、前述のコンポーネント間で情報を送信するために使用される経路を含み得る。

【0064】

通信インタフェース504は、トランシーバタイプ装置を使用して、イーサネット、無線アクセスネットワーク（radio access network，RAN）、または無線ローカルエリアネットワーク（wireless local area networks，WLAN）などの別のデバイスもしくは通信ネットワークと通信する。

【0065】

メモリ503は、読み取り専用メモリ（read－only memory，ROM）、静的情報および命令を格納できる別のタイプの静的ストレージデバイス、ランダムアクセスメモリ（random access memory，RAM）、情報および命令を格納できる別のタイプのダイナミックストレージデバイス、電気的に消去可能なプログラマブル読み取り専用メモリ（electrically erasable programmable read－only memory，EEPROM）、コンパクトディスク読み取り専用メモリ（compact disc read－only memory，CD－ROM）、その他の光ディスクストレージ、光ディスクストレージ（コンパクトディスク、レーザディスク、光ディスク、デジタル多用途ディスク、ブルーレイディスクなどを含む）、ディスク記憶媒体もしくは別の磁気記憶デバイス、または命令もしくはデータ構造のフォーマットで予想されるプログラムコードを保持または格納するために使用できかつコンピュータからアクセスできる他の媒体であってもよい。メモリ503はそれに限定されない。メモリは独立して存在してもよく、バスを介してプロセッサに接続される。あるいは、メモリはプロセッサと統合されてもよい。

【0066】

メモリ503は、本発明の解決策を実行するためのアプリケーションプログラムコードを格納するように構成され、プロセッサ501は、実行を制御する。プロセッサ501は、メモリ503に格納されたアプリケーションプログラムコードを実行し、ビークルツーエブリシング通信ユニット、ビークルツーエブリシングサーバ、および証明書失効サーバの機能を本明細書の方法で実装するように構成される。

【0067】

特定の実装において、一実施形態では、プロセッサ501は、1つまたは複数のCPU、例えば図9のCPU0およびCPU1を含むことができる。

【0068】

特定の実装において、一実施形態では、装置500は、複数のプロセッサ、例えば、図9のプロセッサ501およびプロセッサ508を含むことができる。これらの各プロセッサは、シングルコア（single－CPU）プロセッサまたはマルチコア（multi－CPU）プロセッサでもよい。本明細書のプロセッサは、データ（例えば、コンピュータプログラム命令）を処理するための1つまたは複数のデバイス、回路、および／または処理コアでもよい。

【0069】

特定の実装において、一実施形態では、装置500は、出力デバイス505および入力デバイス506をさらに含むことができる。出力デバイス505は、プロセッサ501と通信し、複数の方法で情報を表示すことができる。例えば、出力デバイス505は、液晶ディスプレイ（liquid crystal display，LCD）、発光ダイオード（light emitting diode，LED）ディスプレイデバイス、陰極線管（cathode ray tube，CRT）ディスプレイデバイス、またはプロジェクタ（projector）でもよい。入力デバイス506は、プロセッサ501と通信し、複数の方法でユーザ入力を受け取ることができる。例えば、入力デバイス506は、マウス、キーボード、タッチスクリーンデバイス、または感知デバイスでもよい。

【0070】

前述の装置が、ビークルツーエブリシングサーバまたは証明書失効サーバの機能を実装する場合、装置500は、汎用サーバまたは専用サーバでもよい。

【0071】

前述の装置が、本出願の実施形態におけるビークルツーエブリシング通信ユニットの機能を実装する場合、装置500は、車両に統合されたテレマティクスボックス（Telematics BOX，T－Box）またはマルチドメインコントローラ（Multi－Domain Controller，MDC）でもよい。任意選択で、装置500は、代替的に、車両に組み込まれたチップでもよい。この場合、通信インタフェース504の機能／実装プロセスは、代わりに、ピン、回路などを使用することによって実装され得る。メモリは、チップ内のストレージユニットであり、例えば、レジスタやキャッシュである。あるいは、ストレージユニットは、チップの外側に配置されたストレージユニットでもよい。

【0072】

前述の実施形態のすべてまたはいくつかは、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせを使用することにより実装され得る。ソフトウェアが使用されて実施形態を実装する場合、実施形態は、コンピュータプログラム製品の形で完全にまたは部分的に実装され得る。コンピュータプログラム製品は、1つまたは複数のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータにロードされ実行されると、本発明の実施形態による手順または機能は、すべてまたは部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または別のプログラム可能な装置であってもよい。コンピュータ命令は、コンピュータ可読記憶媒体に格納されてもよいし、あるコンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に伝送されてもよい。例えば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバ、またはデータセンタから別のウェブサイト、コンピュータ、サーバ、またはデータセンタに有線（同軸ケーブル、光ファイバ、またはデジタル加入者回線（DSL）など）または無線（赤外線、高周波、マイクロ波など）方式で伝送されてもよい。コンピュータ可読記憶媒体は、コンピュータによってアクセス可能な任意の使用可能な媒体であってもよく、または1つまたは複数の使用可能な媒体を統合するデータ記憶デバイス、例えばサーバまたはデータセンタであってもよい。使用可能な媒体は、磁気媒体（フロッピーディスク、ハードディスク、磁気テープなど）、光学媒体（DVDなど）、半導体媒体（ソリッドステートドライブ（Solid State Disk，SSD）など）などであってもよい。

【0073】

本発明の目的、技術的解決策、および利点は、前述の特定の実装においてさらに詳細に説明される。当業者は、前述の説明が本発明の単なる特定の実装形態であるが、本発明の保護範囲を限定することを意図するものではないことを理解すべきである。本発明の技術的解決策に基づいて行われた修正、同等の交換、または改善は、本発明の保護範囲に含まれるものとする。特許請求の範囲において、「含む（comprising）」は、別の構成要素または別のステップを除外せず、「1つ（a）」または「1つ（one）」は、複数の意味を除外しない。単一のプロセッサまたは別のユニットが、請求項に列挙されているいくつかの機能を実装することができる。いくつかの手段は、互いに異なる従属請求項に記録されるが、これは、これらの手段を組み合わせてより良い効果を生み出すことができないことを意味しない。

【符号の説明】

【0074】

500 装置
501 プロセッサ
502 通信バス
503 メモリ
504 通信インタフェース
505 出力デバイス
506 入力デバイス
508 プロセッサ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】