特許 7109569 デジタル証明書の検証方法並びにその、装置、コンピュータ機器並びにコンピュータプログラム

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

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

(11)【特許番号】

(24)【登録日】2022-07-21

(45)【発行日】2022-07-29

(54)【発明の名称】デジタル証明書の検証方法並びにその、装置、コンピュータ機器並びにコンピュータプログラム

(51)【国際特許分類】

   H04L 9/08 20060101AFI20220722BHJP

   G09C 1/00 20060101ALI20220722BHJP

   H04L 9/32 20060101ALI20220722BHJP

【ＦＩ】

H04L9/08 F

G09C1/00 640D

H04L9/32 200Z

【請求項の数】 15

(21)【出願番号】P 2020551483

(86)(22)【出願日】2019-06-21

(65)【公表番号】

(43)【公表日】2021-07-15

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

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

(87)【国際公開日】2020-01-30

【審査請求日】2020-09-25

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

(32)【優先日】2018-07-24

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

(73)【特許権者】

【識別番号】517392436

【氏名又は名称】▲騰▼▲訊▼科技（深▲セン▼）有限公司

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾 直樹

(72)【発明者】

【氏名】郭 ▲鋭▼

(72)【発明者】

【氏名】李 茂材

(72)【発明者】

【氏名】▲張▼ 建俊

(72)【発明者】

【氏名】▲曾▼ ▲禎▼

【審査官】岸野 徹

(56)【参考文献】

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

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

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

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

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

Ｈ０４Ｌ ９／０８

Ｈ０４Ｌ ９／３２

Ｇ０９Ｃ １／００

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

【請求項1】

証明書申請ノードによって発行されたデジタル証明書をコンピュータが検証する方法であって、
対象デジタル証明書を検証する検証リクエストを受信するステップと、
ブロックチェーンから前記対象デジタル証明書に対応する対象トランザクションレコードを取得するステップであって、前記対象デジタル証明書はトランザクションリソースとして前記ブロックチェーンに記憶される、ステップと
前記対象トランザクションレコードに対応する対象アカウントタイプを取得するステップであって、異なるアカウントタイプが異なるトランザクションレコードに対応する、ステップと、
前記対象アカウントタイプに基づいて、前記対象デジタル証明書に対応する検証結果を決定するステップと、を含む方法。

【請求項2】

前記対象デジタル証明書を操作する操作リクエストを受信するステップと、
前記操作リクエストの操作タイプに基づいて、前記対象デジタル証明書に対応する対象受信アカウントタイプを決定するステップと、
前記操作リクエストに対応する証明書トランザクションレコードを生成し、前記証明書トランザクションレコードを前記ブロックチェーンに書き込むステップであって、記証明書トランザクションレコードのトランザクションリソースは前記対象デジタル証明書であり、前記証明書トランザクションレコードにおける受信アカウントは前記対象受信アカウントタイプに対応するアカウントである、ステップと、をさらに含む請求項１に記載の方法。

【請求項3】

前記操作リクエストの操作タイプに基づいて、前記対象デジタル証明書に対応する対象受信アカウントタイプを決定する前記ステップは、
前記操作リクエストに対応する操作タイプが更新操作タイプ又は挿入操作タイプである場合、前記対象受信アカウントタイプを証明書発行アカウントタイプとして決定するステップを含み、前記挿入操作タイプは、初めてデジタル証明書を前記ブロックチェーンに記憶することに対応する操作のタイプである、請求項２に記載の方法。

【請求項4】

前記操作リクエストの操作タイプに基づいて、前記対象デジタル証明書に対応する受信アカウントタイプを決定するステップは、
前記操作リクエストに対応する操作タイプが取り消し操作タイプである場合、前記対象受信アカウントタイプを証明書回収アカウントタイプとして決定するステップを含む請求項２に記載の方法。

【請求項5】

前記対象トランザクションレコードは最新のトランザクションレコードであり、対象トランザクションレコードに対応する対象アカウントタイプを取得する前記ステップは、
前記最新のトランザクションレコードに対応する、前記対象デジタル証明書を受信する現在の受信アカウントタイプを取得して、前記対象アカウントタイプとするステップを含み、
前記対象アカウントタイプに基づいて、前記対象デジタル証明書に対応する検証結果を決定する前記ステップは、
前記現在の受信アカウントタイプが証明書発行アカウントタイプである場合、前記対象デジタル証明書に対応する検証結果を検証成功として決定するステップを含む請求項１に記載の方法。

【請求項6】

前記対象トランザクションレコードは最新のトランザクションレコードであり、前記対象トランザクションレコードに対応する対象アカウントタイプを取得する前記ステップは、
前記最新のトランザクションレコードに対応する、前記対象デジタル証明書を受信する現在の受信アカウントタイプを取得して、前記対象アカウントタイプとすることを含み、
前記対象アカウントタイプに基づいて、前記対象デジタル証明書に対応する検証結果を決定する前記ステップは、
前記現在の受信アカウントタイプが証明書回収アカウントタイプである場合、前記対象デジタル証明書に対応する検証結果を検証失敗として決定するステップを含む請求項１に記載方法。

【請求項7】

前記検証リクエストが前記対象デジタル証明書に対応するトランザクション識別子を持ち、前記ブロックチェーンから前記対象デジタル証明書に対応する対象トランザクションレコードを取得する前記ステップは、
前記トランザクション識別子に基づいて、前記対象デジタル証明書に対応するトランザクションチェーンを取得し、前記トランザクションチェーンの末端にあるトランザクションレコードを前記最新のトランザクションレコードとするステップであって、前記トランザクションチェーン中の各トランザクションレコードがトランザクションの順序に従って配列される、ステップを含む請求項５又は６に記載の方法。

【請求項8】

前記検証リクエストに基づいて、前記ブロックチェーンから前記対象デジタル証明書に対応するルート証明書を取得するステップと、
前記ルート証明書に基づいて、前記対象デジタル証明書を検証し、ルート検証結果を取得するステップと、
前記ルート検証結果は検証失敗である場合、前記対象デジタル証明書に対応する検証結果を検証失敗として確認し、そうではなければ、ブロックチェーンから前記対象デジタル証明書に対応する対象トランザクションレコードを取得するステップに進むステップと、をさらに含む請求項１に記載の方法。

【請求項9】

認証局に適用する、証明書申請ノードによって発行されたデジタル証明書を検証する装置であって、
対象デジタル証明書を検証する検証リクエストを受信するための検証リクエスト受信モジュールと、
ブロックチェーンから前記対象デジタル証明書に対応する対象トランザクションレコードを取得するためのモジュールであって、前記対象デジタル証明書はトランザクションリソースとして前記ブロックチェーンに記憶される、対象トランザクションレコード取得モジュールと、
前記対象トランザクションレコードに対応する対象アカウントタイプを取得するためのモジュールであって、異なるアカウントタイプが異なるトランザクションレコードに対応する、対象アカウントタイプ取得モジュールと、
前記対象アカウントタイプに基づいて、前記対象デジタル証明書に対応する検証結果を決定するための検証結果決定モジュールと、を含む装置。

【請求項10】

前記対象デジタル証明書を操作する操作リクエストを受信するための操作リクエスト受信モジュールと、
前記操作リクエストの操作タイプに基づいて、前記対象デジタル証明書に対応する対象受信アカウントタイプを決定するための受信アカウントタイプ決定モジュールと、
前記操作リクエストに対応する証明書トランザクションレコードを生成し、前記証明書トランザクションレコードを前記ブロックチェーンに書き込むためのモジュールであって、前記証明書トランザクションレコードのトランザクションリソースは前記対象デジタル証明書であり、前記証明書トランザクションレコードにおける受信アカウントは前記対象受信アカウントタイプに対応するアカウントである、証明書トランザクションレコード生成モジュールと、をさらに含む請求項９に記載の装置。

【請求項11】

前記受信アカウントタイプ決定モジュールは、
前記操作リクエストに対応する操作タイプが更新操作タイプ又は挿入操作タイプである場合、前記対象受信アカウントタイプを証明書発行アカウントタイプとして決定するために用いられ、前記挿入操作タイプは、初めてデジタル証明書を前記ブロックチェーンに記憶することに対応する操作のタイプである請求項１０に記載の装置。

【請求項12】

前記受信アカウントタイプ決定モジュールは、
前記操作リクエストに対応する操作タイプが取り消し操作タイプである場合、前記対象受信アカウントタイプを証明書回収アカウントタイプとして決定するために用いられる請求項１０に記載の装置。

【請求項13】

前記対象トランザクションレコードは最新のトランザクションレコードであり、前記対象アカウントタイプ取得モジュールは、
前記最新のトランザクションレコードに対応する、前記対象デジタル証明書を受信する現在の受信アカウントタイプを取得して、前記対象アカウントタイプとするために用いられ、
前記検証結果決定モジュールは、
前記現在の受信アカウントタイプが証明書発行アカウントタイプである場合、前記対象デジタル証明書に対応する検証結果を検証成功として決定するために用いられる請求項９に記載の装置。

【請求項14】

プロセッサと、前記プロセッサによって実行される時に、前記プロセッサに請求項１から８のいずれか一項に記載の方法のステップを実行させるコンピュータプログラムが記憶されているメモリと、を含むことを特徴とするコンピュータ。

【請求項15】

コンピュータに請求項１から８のいずれか一項に記載の方法を実行させるコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

「関連出願の相互参照」
本願は、２０１８年０７月２４日に出願された、出願番号が２０１８１０８２１６６７．６であり、出願名称が「デジタル証明書の検証方法、装置、コンピュータ機器及び記憶媒体」である中国特許出願の優先権を主張し、その内容全体が援用により本願に組み込まれる。

【0002】

本願は、コンピュータ技術の分野に関し、特に、デジタル証明書の検証方法、装置、コンピュータ機器及びコンピュータプログラムに関する。

【背景技術】

【0003】

デジタル証明書とは、ネットワーク上でネットワークノードの身元を証明するための証明用ファイルであり、身元を証明するために、ネットワークノードは、権威のある認証局にデジタル証明書を申請し、権威のある認証局が身元認証を行ってから、当該ネットワークノードにデジタル証明書を発布する。

【0004】

現在、デジタル証明書の検証は、いずれもデジタル証明書を生成する権威のある認証局によって行われるため、当該認証局がハイジャックされると、認証局がデジタル証明書を検証して得た検証結果が信頼できず、ネットワークセキュリティが低くなる。

【発明の概要】

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

【0005】

これに鑑みて、上記問題に対して、デジタル証明書の検証方法、装置、コンピュータ機器、及びコンピュータプログラムを提供し、対象デジタル証明書がブロックチェーンにおいて記載するトランザクションレコードに基づいて、対応する対象アカウントタイプを取得し、対応する対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を取得し、デジタル証明書がトランザクションリソースとしてブロックチェーン中に記憶されることによって、トランザクションレコードが改竄されにくくなり、そして、異なるアカウントタイプが異なる証明書操作状態に対応するため、ブロックチェーンにおけるトランザクションレコードのアカウントタイプに基づいて得る検証結果は信頼性が高く、ネットワークセキュリティが高い。

【0006】

デジタル証明書の検証方法であって、前記方法は、対象デジタル証明書を検証する検証リクエストを受信するステップと、ブロックチェーンから前記対象デジタル証明書に対応する対象トランザクションレコードを取得するステップであって、前記対象デジタル証明書はトランザクションリソースとして前記ブロックチェーンに記憶される、ステップと、前記対象トランザクションレコードに対応する対象アカウントタイプを取得するステップであって、異なるアカウントタイプが異なる証明書操作状態に対応する、ステップと、前記対象アカウントタイプに基づいて、前記対象デジタル証明書に対応する検証結果を決定するステップと、を含む。

【0007】

デジタル証明書検証装置であって、前記装置は、対象デジタル証明書を検証する検証リクエストを受信するための検証リクエスト受信モジュールと、ブロックチェーンから前記対象デジタル証明書に対応する対象トランザクションレコードを取得するためのモジュールであって、前記対象デジタル証明書はトランザクションリソースとして前記ブロックチェーンに記憶される、対象トランザクションレコード取得モジュールと、前記対象トランザクションレコードに対応する対象アカウントタイプを取得するためのモジュールであって、異なるアカウントタイプが異なる証明書操作状態に対応する、対象アカウントタイプ取得モジュールと、前記対象アカウントタイプに基づいて、前記対象デジタル証明書に対応する検証結果を決定するための検証結果決定モジュールと、を含む。

【0008】

１つの実施例では、前記装置は、前記対象デジタル証明書を操作する操作リクエストを受信するための操作リクエスト受信モジュールと、前記操作リクエストの操作タイプに基づいて、前記対象デジタル証明書に対応する対象受信アカウントタイプを決定するための受信アカウントタイプ決定モジュールと、前記操作リクエストに対応する証明書トランザクションレコードを生成し、前記証明書トランザクションレコードを前記ブロックチェーンに書き込むためのモジュールであって、前記証明書トランザクションレコードのトランザクションリソースは前記対象デジタル証明書であり、前記証明書トランザクションレコードにおける受信アカウントは前記対象受信アカウントタイプに対応するアカウントである、証明書トランザクションレコード生成モジュールと、をさらに含む。

【0009】

１つの実施例では、前記受信アカウントタイプ決定モジュールは、前記操作リクエストに対応する操作タイプが更新操作タイプ又は挿入操作タイプである場合、前記対象受信アカウントタイプを証明書発行アカウントタイプとして決定するために用いられる。

【0010】

１つの実施例では、前記受信アカウントタイプ決定モジュールは、前記操作リクエストに対応する操作タイプが取り消し操作タイプである場合、前記対象受信アカウントタイプを証明書回収アカウントタイプとして決定するために用いられる。

【0011】

１つの実施例では、前記対象トランザクションレコードは最新のトランザクションレコードであり、前記対象アカウントタイプ取得モジュールは、前記最新のトランザクションレコードに対応する、前記対象デジタル証明書を受信する現在の受信アカウントタイプを取得して、前記対象アカウントタイプとするために用いられ、前記検証結果決定モジュールは、前記現在の受信アカウントタイプが証明書発行アカウントタイプである場合、前記対象デジタル証明書に対応する検証結果を検証成功として決定するために用いられる。

【0012】

１つの実施例では、前記対象アカウントタイプ取得モジュールは、前記最新のトランザクションレコードに対応する、前記対象デジタル証明書を受信する現在の受信アカウントタイプを取得して、前記対象アカウントタイプとするために用いられ、前記検証結果決定モジュールは、前記現在の受信アカウントタイプが証明書回収アカウントタイプである場合、前記対象デジタル証明書に対応する検証結果を検証失敗として決定するために用いられる。

【0013】

１つの実施例では、前記検証リクエストが前記対象デジタル証明書に対応するトランザクション識別子を持ち、前記対象トランザクションレコード取得モジュールは、前記トランザクション識別子に基づいて、前記対象デジタル証明書に対応するトランザクションチェーンを取得し、前記トランザクションチェーンの末端にあるトランザクションレコードを前記最新のトランザクションレコードとするために用いられ、前記トランザクションチェーンにおける各トランザクションレコードがトランザクション順序に従って配列される。

【0014】

１つの実施例では、前記装置は、前記検証リクエストに基づいて、前記ブロックチェーンから前記対象デジタル証明書に対応するルート証明書を取得するためのルート証明書取得モジュールと、前記ルート証明書に基づいて、前記対象デジタル証明書を検証し、ルート検証結果を取得するためのルート検証結果取得モジュールと、前記ルート検証結果は検証失敗である場合、前記対象デジタル証明書に対応する検証結果を検証失敗として確認し、そうではなければ、ブロックチェーンから前記対象デジタル証明書に対応する対象トランザクションレコードを取得するステップに進む進入モジュールと、をさらに含む。

【0015】

コンピュータ機器であって、プロセッサと、前記プロセッサによって実行される時に、前記プロセッサに上記デジタル証明書の検証方法のステップを実行させるコンピュータプログラムが記憶されているメモリと、をさらに含む。

【0016】

コンピュータに上記デジタル証明書の検証方法を実行させるコンピュータプログラムである。

【発明の効果】

【0017】

前述したデジタル証明書の検証方法、装置、コンピュータ機器及びコンピュータプログラムは、対象デジタル証明書を検証する検証リクエストを受信し、ブロックチェーンから対象デジタル証明書に対応する対象トランザクションレコードを取得し、ただし、対象デジタル証明書がトランザクションリソースとしてブロックチェーンに記憶され、対象トランザクションレコードに対応する対象アカウントタイプを取得し、ただし、異なるアカウントタイプが異なる証明書操作状態に対応し、対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を決定する。デジタル証明書がトランザクションリソースとしてブロックチェーンに記憶されることによって、トランザクションレコードが改竄されにくくなり、そして、異なるアカウントタイプが異なる証明書操作状態に対応するため、ブロックチェーンにおけるトランザクションレコードのアカウントタイプに基づいて得る検証結果は信頼性が高く、ネットワークセキュリティが高い。

【図面の簡単な説明】

【0018】

【図1】一実施例にて提供されるデジタル証明書の検証方法の利用環境の図である。

【図2】一実施例におけるデジタル証明書の検証方法のフローチャートである。

【図3】一実施例におけるデジタル証明書の検証方法のフローチャートである。

【図4】一実施例におけるデジタル証明書の検証方法のフローチャートである。

【図5】一実施例におけるデジタル証明書の模式図である。

【図6】一実施例における対象デジタル証明書をトランザクションリソースとして合意認証局に対応するブロックチェーンに書き込むフローチャートである。

【図7】一実施例におけるトランザクションチェーンの模式図である。

【図8】一実施例におけるデジタル証明書の検証方法のフローチャートである。

【図9】一実施例にて提供されるデジタル証明書の検証方法の利用環境の図である。

【図10】一実施例におけるデジタル証明書検証装置の構造ブロック図である。

【図11】一実施例におけるデジタル証明書検証装置の構造ブロック図である。

【図12】一実施例におけるデジタル証明書検証装置の構造ブロック図である。

【図13】一実施例におけるコンピュータ機器の内部構造ブロック図である。

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

【0019】

本願の目的、技術的解決手段及び利点をより明確にするために、以下、図面及び実施例を参照しながら、本願についてさらに詳細に説明する。ここに記載されている具体的な実施例は、本願を解釈するためのものに過ぎず、本願を限定するものではないことが理解できる。

【0020】

本願に使用される「第１」、「第２」などの用語は、本明細書において各種の素子を説明するために用いることができるが、特に断りのない限り、これらの素子はこれらの用語に限定されるものではないことが理解できる。これらの用語は、１つ目の素子と別の素子を区別するためのものに過ぎない。例を挙げると、本願の範囲を逸脱せず、第１トランザクションレコードを第２トランザクションレコードと読んでもよく、同様に、第２トランザクションレコードを第１トランザクションレコードと読んでもよい。

【0021】

図１は、一実施例にて提供されるデジタル証明書の検証方法の利用環境の図であり、図１に示すように、当該利用環境は、証明書申請ノードと、インタラクションノードと、認証局と、を含む。インタラクションノードは、証明書申請ノードとインタラクションを行う時、デジタル証明書取得リクエストを証明書申請ノードまで送信し、証明書申請ノードはインタラクションノードに対象デジタル証明書及びトランザクション識別子を返信する。インタラクションノードは、トランザクション識別子及び対象デジタル証明書を持つ検証リクエストを認証局に送信することができる。認証局は、本願の実施例にて提供されるデジタル証明書の検証方法を実行し、検証結果を取得し、インタラクションノードに検証結果を返信する。

【0022】

インタラクションノードと証明書申請ノードとの間、インタラクションノードと認証局との間は、ネットワークを介して接続することができる。各認証局は、独立した物理サーバ又は端末であってもよいし、複数の物理サーバからなるサーバグループであってもよく、クラウドサーバ、クラウドデータベース、クラウドストレージ及びＣＤＮ（Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ、コンテンツデリバリネットワーク）など基本のクラウドコンピューティングサービスを提供するクラウドサーバであってもよい。証明書申請ノード及びインタラクションノードは、独立した物理サーバ又は端末であってもよいし、複数の物理サーバからなるサーバグループであってもよく、クラウドサーバ、クラウドデータベース、クラウドストレージ及びＣＤＮなど基本のクラウドコンピューティングサービスを提供するクラウドサーバであってもよい。

【0023】

図２に示すように、一実施例では、デジタル証明書の検証方法が提供され、本実施例は、主に、当該方法を上記図１における認証局に適用することを例として説明する。具体的に以下のステップを含んでもよい。

【0024】

ステップ２０２は、対象デジタル証明書を検証する検証リクエストを受信する。

【0025】

具体的に、デジタル証明書とは、ネットワーク通信において通信相手の身元情報を表す一連の数字であり、通信相手の身元を識別するために用いられる。デジタル証明書は、Ｉｎｔｅｒｎｅｔ（インターネット）上で通信エンティティ身元を検証する方式を提供するため、デジタル証明書は、一般的に、権威のあるＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ、証明書認証）機構によって発行される。ＣＡ機構は、例えば、ＣＦＣＡ（Ｃｈｉｎａ Ｆｉｎａｎｃｉａｌ Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ、中国金融認証局）であってもよい。検証リクエストは、デジタル証明書の有効性及び真実性を確認するように、対象デジタル証明書に対する検証を請求するために用いられる。対象デジタル証明書は、身元が検証されることを必要とするノードのデジタル証明書であり、例えば、図１の証明書申請ノードに対応するデジタル証明書である。検証リクエストは、証明書申請ノードとインタラクションを行うインタラクションノードから送信されてもよい。例えば、インタラクションノードは、証明書申請ノードに対応するウェブサイトにログインする必要がある場合、証明書申請ノードから対象デジタル証明書を取得し、認証局に検証リクエストを送信してもよい。

【0026】

ステップＳ２０４は、ブロックチェーンから対象デジタル証明書に対応する対象トランザクションレコードを取得し、前記対象デジタル証明書はトランザクションリソースとしてブロックチェーンに記憶される。

【0027】

具体的に、トランザクションリソースは、トランザクションに用いることができるリソースであってもよい。ブロックチェーンは、ブロックチェーン技術を実行させるキャリア及び組織方式である。ブロックチェーン技術は、ＢＴ（Ｂｌｏｃｋｃｈａｉｎ ｔｅｃｈｎｏｌｏｇｙ）と略称し、分散型台帳技術とも呼ばれ、インターネットデータベース技術であって、非中央集権、公正かつ透明を特徴とし、人々をデータベース記録に参加させることができるものである。ブロックチェーン技術は、ブロックチェーンのデータ構造を用いてデータを検証及び記憶し、分散型ノード合意アルゴリズムを用いてデータを生成及び更新し、暗号学の方式を用いてデータの伝送及びアクセスのセキュリティを保証し、自動化したスクリプトコードからなるスマートコントラクトを用いてデータをプログラミング及び操作する分散型基本アーキテクチャ及び計算方式である。トランザクションレコードは、トランザクションリソースに対応する、達成できたトランザクションを記載するものである。トランザクションレコードは、今回のトランザクションにおいてトランザクションリソースを転出する転出アカウント及びトランザクションリソースを受信する受信アカウントを含んでもよい。トランザクションレコードは、デジタル証明書そのもの又はデジタル証明書に対応する識別子を含んでもよい。ブロックチェーンにおいて、トランザクションリソースは、トランザクションレコードの形式で表される。証明書のトランザクションレコードは、ＵＴＸＯ（Ｕｎｓｐｅｎｔ Ｔｒａｎｓａｃｔｉｏｎ Ｏｕｔｐｕｔ、未使用のトランザクションの出力）トランザクションに相当する。ＵＴＸＯトランザクションは、トランザクション入力（ｉｎｐｕｔ）及びトランザクション出力（ｏｕｔｐｕｔ）を含む。各トランザクションは、いずれもトランザクション入力、つまり、トランザクションリソースの出所を有し、トランザクション出力、つまり、トランザクションリソースの行き先も有する。本願の実施例では、トランザクション入力に対応するアカウントを転出アカウントと呼び、トランザクション出力に対応するアカウントを受信アカウントと呼ぶ。対象トランザクションレコードは、対象デジタル証明書に対応する最新のトランザクションレコードであってもよい。

【0028】

一実施では、検証リクエストは対象デジタル証明書に対応するトランザクション識別子を持つ。証明書トランザクションが生成されると、認証局はトランザクションレコードに対応するトランザクション識別子を生成し、証明書申請ノードがトランザクション識別子を、証明書申請ノードとインタラクションを行うインタラクションノードである検証リクエスト送信ノードに送信するように、トランザクション識別子を証明書申請ノードに送信する。

【0029】

ステップＳ２０６は、対象トランザクションレコードに対応する対象アカウントタイプを取得し、ただし、異なるアカウントタイプが異なる証明書操作状態に対応する。

【0030】

具体的に、ブロックチェーンに記憶される対象デジタル証明書は、アカウントタイプに応じて証明書の操作状態を具現する。対象アカウントタイプは、対象デジタル証明書を受信するアカウントのタイプである受信アカウントタイプであってもよい。ブロックチェーンにおけるデジタル証明書の操作状態は挿入状態、更新状態及び取り消し状態のうちいずれかであってもよい。挿入状態に対応するデジタル証明書は、新たに生成される初期のデジタル証明書としてブロックチェーンに挿入されるものである。更新状態に対応するデジタル証明書は、初期のデジタル証明書を更新してから得るデジタル証明書であり、すなわち、証明書がすでに更新された。取り消し状態に対応するデジタル証明書は、すでに取り消されたデジタル証明書である。各認証局のアカウントは、証明書回収アカウントタイプ及び証明書発行状態タイプを含んでもよい。取り消し状態のデジタル証明書について、対応する最新のトランザクションレコードの受信アカウントタイプは証明書回収アカウントタイプであり、トランザクションレコードにおける受信アカウントが証明書回収アカウントタイプである場合は、デジタル証明書が取り消し状態にあり、すなわち、すでに取り消されたことを示す。挿入状態及び更新状態にあるデジタル証明書については、対応する最新のトランザクションレコードの受信アカウントタイプは証明書発行アカウントタイプであり、トランザクションレコードにおける受信アカウントが証明書発行アカウントタイプである場合は、デジタル証明書がすでに発行され、すなわち、発行状態にあり、有効なデジタル証明書であることを示す。

【0031】

ステップＳ２０８は、対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を決定する。

【0032】

具体的に、検証結果は検証成功又は検証失敗としてもよい。対象トランザクションレコードを得た後、対象トランザクションレコードの対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果が検証合格か検証失敗かを決定し、最新のトランザクションレコードに対応する対象アカウントタイプにより、対象デジタル証明書の操作状態を決定することができる。最新のトランザクションレコードに対応する受信アカウントタイプが証明書回収アカウントタイプである場合、対象デジタル証明書がすでに取り消され、対象デジタル証明書に対応する検証結果が検証失敗であることを決定する。最新のトランザクションレコードに対応する受信アカウントタイプが証明書発行アカウントタイプである場合、この時、デジタル証明書が挿入されたデジタル証明書又は更新されたデジタル証明書であってもよいため、デジタル証明書を有効として確認し、対象デジタル証明書に対応する検証結果を検証成功として決定する。あるいは、最新のトランザクションレコードに対応する転出アカウントタイプを取得してもよく、転出アカウントがプリセット初期アカウントであれば、当該デジタル証明書を新たに挿入されるデジタル証明書として、検証結果を成功として確認する。

【0033】

一実施例では、対象トランザクションレコードは最新のトランザクションレコードであり、対象トランザクションレコードに対応する対象アカウントタイプを取得するステップは、最新のトランザクションレコードに対応する、対象デジタル証明書を受信する現在の受信アカウントタイプを取得して、対象アカウントタイプとするステップを含む。対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を決定するステップは、現在の受信アカウントタイプが証明書発行アカウントタイプである場合、対象デジタル証明書に対応する検証結果を検証成功として決定するステップと、現在の受信アカウントタイプが証明書回収アカウントタイプである場合、対象デジタル証明書に対応する検証結果を検証失敗として決定するステップと、を含む。ただし、現在のアカウントタイプとは、最新のトランザクションレコードにおける受信アカウントのタイプである。

【0034】

上記デジタル証明書の検証方法は、対象デジタル証明書を検証する検証リクエストを受信し、ブロックチェーンから対象デジタル証明書に対応する対象トランザクションレコードを取得し、対象デジタル証明書はトランザクションリソースとしてブロックチェーンに記憶されており、対象トランザクションレコードに対応する対象アカウントタイプを取得し、ただし、異なるアカウントタイプが異なる証明書操作状態に対応し、対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を決定する。デジタル証明書がトランザクションリソースとしてブロックチェーンに記憶されることによって、トランザクションレコードが改竄されにくくなり、そして、異なるアカウントタイプが異なる証明書操作状態に対応するため、ブロックチェーンにおけるトランザクションレコードのアカウントタイプに基づいて得る検証結果は信頼性が高く、ネットワークセキュリティが高い。

【0035】

一実施例では、図３に示すように、デジタル証明書検証は、以下のステップを含んでもよい。

【0036】

ステップ３０２は、対象デジタル証明書を操作する操作リクエストを受信する。

【0037】

具体的に、操作は、挿入操作、取り消し操作及び更新操作のうちいずれかであってもよい。挿入操作は、初めてデジタル証明書をブロックチェーンに記憶することに対応する操作であり、更新操作は、すでに記憶された対象デジタル証明書を更新することに対応する操作である。取り消し操作は、対象デジタル証明書を取り消すことに対応する操作である。対象デジタル証明書を操作する操作リクエストは、証明書申請ノード、認証局又は他のノードによってトリガされるものであってもよい。例えば、対象デジタル証明書を更新する必要があれば、証明書申請ノードはデジタル証明書更新リクエストを送信することができる。対象デジタル証明書を取り消す必要があれば、証明書申請ノードはデジタル証明書取り消しリクエストを送信することができる。あるいは、認証局が証明書申請ノードの対象デジタル証明書の取得時における詐欺行為を発覚した場合、認証局の従業者は認証局において取り消し操作を起こすことができ、認証局は、取り消し操作に基づいて、デジタル証明書取り消しリクエストをトリガし、当該デジタル証明書の取り消しを請求する。あるいは、認証局ノードが対象デジタル証明書を生成し、対象デジタル証明書をブロックチェーンに記憶する必要がある時に、対象デジタル証明書を操作する操作リクエストをトリガすることもできる。

【0038】

ステップＳ３０４は、操作リクエストの操作タイプに基づいて、対象デジタル証明書に対応する対象受信アカウントタイプを決定する。

【0039】

ここで、対象デジタル証明書に対応する対象受信アカウントタイプは、対象デジタル証明書を受信するアカウントに対応する対象受信アカウントタイプであってもよい。

【0040】

具体的に、操作タイプに応じて受信アカウントタイプが異なる。各認証局のアカウントは、証明書回収アカウントタイプ及び証明書発行状態タイプを含んでもよい。取り消し操作タイプについては、対応する受信アカウントタイプは証明書回収アカウントタイプであり、トランザクションレコードにおける受信アカウントが証明書回収アカウントタイプである場合は、デジタル証明書が取り消し状態にあり、すなわち、すでに取り消されたことを示す。更新操作タイプ及び挿入操作タイプについては、対応するアカウントタイプは証明書発行アカウントタイプであり、トランザクションレコードにおける受信アカウントが証明書発行アカウントタイプである場合は、デジタル証明書がすでに発行され、すなわち、発行状態にあり、有効なデジタル証明書であることを示す。

【0041】

一実施例では、操作リクエストに対応する操作タイプが更新操作タイプ又は挿入操作タイプである場合、対象受信アカウントタイプを証明書発行アカウントタイプとして決定する。

【0042】

一実施例では、操作リクエストに対応する操作タイプが取り消し操作タイプである場合、対象受信アカウントタイプを証明書回収アカウントタイプとして決定する。ただし、証明書回収アカウント及び証明書発行アカウントは、デジタル証明書を生成する認証ノードに対応するアカウントであってもよい。

【0043】

ステップＳ３０６は、操作リクエストに対応する証明書トランザクションレコードを生成し、証明書トランザクションレコードをブロックチェーンに書き込み、ただし、証明書トランザクションレコードのトランザクションリソースは対象デジタル証明書であり、証明書トランザクションレコードにおける受信アカウントは対象受信アカウントタイプに対応するアカウントである。

【0044】

具体的に、トランザクションにおいて、受信アカウントとは、トランザクションリソースを有するアカウントである。転出アカウントとは、トランザクションリソースを受信アカウントまで転出するアカウントである。対象デジタル証明書を、トランザクションが可能なリソースとし、当該デジタル証明書のトランザクションレコードがブロックチェーンに記憶される。アカウントタイプとアカウントとの間の対応関係が予め設定され、例えば、証明書発行アカウントタイプについては、対応するアカウントは００００１であり、証明書回収アカウントタイプについては、対応するアカウントは００００２である。対象受信アカウントタイプを得た後、対象受信アカウントタイプに対応するアカウントを取得し、証明書トランザクションレコードに対応する受信アカウントとする。証明書トランザクションレコードを得た後、ブロックに当該証明書トランザクションレコードを記憶するように、証明書トランザクションレコードをブロックチェーンのブロック中に書き込む。証明書トランザクションレコードをブロックに書き込む時、ブロックチェーンにおけるノードもブロックにおいて証明書トランザクションレコードを記憶するように、証明書トランザクションレコードをブロードキャストすることが理解できる。証明書トランザクションレコードをブロードキャストする前に、秘密鍵を用いて証明書トランザクションレコードに対して署名し、署名後の証明書トランザクションレコードをブロードキャストするものとしてもよい。証明書トランザクションレコードを生成する時、証明書トランザクションを識別するために、対応するトランザクション識別子を生成してもよい。

【0045】

一実施例では、証明書トランザクションレコードに対応するトランザクション識別子を生成した後、トランザクション識別子を証明書申請ノードに送信する。このように、証明書申請ノードと通信するインタラクションノードは、当該証明書申請ノードに対応するトランザクション識別子及び対象デジタル証明書を取得するとともに、証明書検証を行うように、トランザクション識別子に基づいて、ブロックチェーンにおいて対象デジタル証明書がブロックチェーンに記憶したトランザクションレコードを取得することができる。

【0046】

ステップＳ３０２～Ｓ３０６は、ステップＳ２０２～Ｓ２０８の前に実行してもよいし、ステップＳ２０２～Ｓ２０８の後に実行してもよいことが理解できる。

【0047】

一実施例では、対象デジタル証明書に対する操作は挿入操作であり、図４に示すように、デジタル証明書の検証方法は、具体的に、以下のステップをさらに含んでもよい。

【0048】

ステップＳ４０２は、証明書申請ノードから送信された、身元認証情報を持つデジタル証明書生成リクエストを受信する。

【0049】

具体的に、身元認証情報は、証明書申請ノードの身元を認証するために用いられ、身元認証情報は、例えば、証明書申請ノードの企業に対応する営業許可書情報又は証明書申請ノードの個人ユーザに対応する身分証明書情報などであってもよい。証明書申請ノードは、デジタル証明書の申請を必要とするノードである。例えば、企業がウェブサイトを作成する必要がある場合には、当該ウェブサイトに対応するデジタル証明書を申請する必要があり、この場合、デジタル証明書を申請する必要がある企業のサーバによって認証局にデジタル証明書生成リクエストを送信してもよい。

【0050】

一実施例では、デジタル証明書生成リクエストは、公開鍵をさらに持ってもよい。公開鍵（Ｐｕｂｌｉｃ Ｋｅｙ）と秘密鍵（Ｐｒｉｖａｔｅ Ｋｅｙ）は、アルゴリズムによって得られた鍵ペアであり、公開鍵は鍵ペアうち公開される鍵であり、秘密鍵は公開されない鍵である。公開鍵は、通常、セッション鍵の暗号又はデジタル署名の検証に用いられる。デジタル証明書を申請する必要がある場合、証明書申請ノードは鍵ペアを生成し、鍵ペアの秘密鍵を記憶するとともに、認証局が公開鍵をデジタル証明書に書き込むように、公開鍵を認証局に送信する。このように、証明書申請ノードは、秘密鍵を用いて送信する情報を署名することができ、署名された情報を受信したノードは、デジタル証明書の公開鍵を用いて、証明書申請ノードから送信された情報に対して署名認証を行い、受信した情報を証明書申請ノードから送信された情報として確認することができる。

【0051】

ステップＳ４０４は、身元認証情報を各合意認証局に送信して認証し、各合意認証局が身元認証情報に基づいて認証することによって得た認証結果を取得する。

【0052】

具体的に、合意認証局の数は、必要に応じて設定されてもよい。身元認証情報の送信は、Ｐ２Ｐ（ｐｅｅｒ－ｔｏ－ｐｅｅｒ、ピアツーピア）技術によって実現されてもよい。認証局１はブロックチェーンにおいて当該身元認証情報をブロードキャストしてもよく、身元認証情報を受信した合意認証局も当該身元認証情報をブロードキャストし続けることで、各合意認証局は身元認証情報を受信できることになる。合意認証局は、合意認証を行うための認証局であり、合意とは、多くの参加者同士のノードが、予め設定されたルール下で、複数のノードのインタラクションにより、あるデータ、行為又はフローについて合致するプロセスである。合意を行う時に用いる合意アルゴリズムは、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｒａｎｃｅ、プラクティカルビザンチンフォールトトレランス）であってもよい。認証局は、ネットワークにおいて、認証サービス、ノード身元の確認のためのデジタル証明書の署名発行などの仕事をする、権威性及び公正性を有するコンピュータノードであってもよい。各合意認証局が身元認証情報を受信した後、受信した身元情報が記憶されている身元情報に一致するか否かを確認するように、受信した身元認証情報を予め記憶された当該証明書申請ノードの身元認証情報と比較するか、又は身元認証情報を身元認証情報が記憶されている信頼できるソースに送信して比較するものとしてもよく、一致する場合、受信した身元情報を真実なものとして確認すると、合意認証局に対応する認証結果は合格であり、そうではなければ、認証結果は不合格である。信頼できるソースは、身元認証情報を発布するノード、例えば、公安機関による個人身分証明書の発布に対応するノードであってもよい。

【0053】

ステップｓ４０６は、各合意認証局の認証結果に基づいて、証明書申請ノードに対応する身元認証結果を決定する。

【0054】

具体的に、身元認証結果は、身元認証合格又は身元認証不合格であってもよい。身元認証結果は、各合意認証局の認証結果と結びつけて計算することで得られるものである。身元認証結果を決定する時に、認証結果が認証合格の合意認証局に対応する第１数量及び認証結果が認証不合格の合意認証局に対応する第２数量のうち少なくとも１つを取得し、第１数量及び第２数量のうち少なくとも１つに基づいて、身元認証結果を決定することができる。例えば、第１数量が第２数量より大きい、第１数量が第１プリセット閾値に達する、第１数量と合意検証に参加する認証局の数量との比が第２プリセット閾値に達する、第１数量とブロックチェーンのノードの数量との比が第２プリセット閾値に達するという条件のうち少なくとも１つを満たす場合、身元認証結果は合格であり、第１数量が第２数量より大きく、第１数量が第１プリセット閾値に達し、第１数量と合意検証に参加するノードの数量との比が第３プリセット閾値に達する。認証局１も合意認証局であることが理解できる。第１プリセット閾値、第２プリセット閾値及び第３プリセット閾値に対応する具体的な数は、必要に応じて設定されてもよい。例えば、認証局１～４に対応する認証結果はそれぞれ合格、合格、合格及び不合格であると仮定すると、第１数量は３であり、第２数量は１であり、身元認証結果が合格である条件を、第１数量より大きい合意認証局が合意認証局の総量を占める比率が３／４以上であることと仮定すると、身元認証結果は合格である。

【0055】

ステップｓ４０８は、デジタル証明書生成リクエストに基づいて、証明書申請ノードに対応する対象デジタル証明書を生成する。

【0056】

具体的に、デジタル証明書は、認証局によってデジタル署名されるファイルで、ネットワークノードの身元を証明するために用いられる。デジタル証明書は、証明書申請ポイントの身元情報及び公開鍵情報を含むとともに、認証局の署名情報を付けるものとしてもよい。当然ながら、デジタル証明書の有効期限などの情報をさらに含んでもよい。対象デジタル証明書は、身元認証結果を認証合格として確認した後に生成されるものであってもよいし、身元認証結果を認証合格として確認していない時に対象デジタル証明書を生成するものであってもよい。身元認証結果を認証合格として確認していない時に対象デジタル証明書を生成する場合は、身元認証結果は合格である時に、対象デジタル証明書をブロックチェーンに速やかに書き込んでもよい。身元認証結果を認証合格として確認した後に対象デジタル証明書を生成すれば、身元認証結果は認証不合格である場合にも対象デジタル証明書を生成する必要がある状況の発生を回避することができる。

【0057】

図５に示すように、図５は、デジタル証明書の模式図であり、証明書発布者の情報、証明書申請ノードの公開鍵、証明書申請ノードである証明書オーナーの情報、有効期限情報、デジタル署名を行う署名ハッシュアルゴリズム及びデジタル署名を有し、デジタル署名とは、デジタル証明書を双方が約束したハッシュアルゴリズムに従って計算して得られるメッセージダイジェストである。数学上に、デジタル証明書におけるいずれか１つを変更しさえすれば、改めて算出したメッセージダイジェストの値は元の値に一致しないことが保証される。このように、デジタル証明書が変更されるか否かを識別できることが保証される。

【0058】

ステップＳ４１０は、身元認証結果は認証合格である場合、対象デジタル証明書をトランザクションリソースとして合意認証局に対応するブロックチェーンに書き込み、ただし、対象デジタル証明書に対応する受信アカウントはデジタル証明書生成リクエスト受信ノードに対応する第１アカウントである。

【0059】

具体的に、対象デジタル証明書が書き込まれるブロックチェーンは合意認証局に対応するブロックチェーンである。デジタル証明書生成リクエスト受信ノードとは、デジタル証明書生成リクエストを受信するノードである。トランザクションにおいて、受信アカウントとは、トランザクションリソースを有するアカウントである。転出アカウントとは、トランザクションリソースを受信アカウントまで転出するアカウントである。対象デジタル証明書をブロックチェーンに書き込む時に、対象デジタル証明書を、トランザクションが可能なリソースとし、当該デジタル証明書のトランザクションレコードがブロックチェーンに記憶される。対象デジタル証明書をブロックチェーンに記憶する時に、対象デジタル証明書のトランザクションレコードにおける受信アカウントはデジタル証明書生成リクエストを受信するノードに対応するアカウントである。対象デジタル証明書は初めて記憶される対象デジタル証明書であるため、転出アカウントは予め設定されたアカウントであってもよい。例えば、すべて０である文字列としてもよく、当該トランザクションリソースは初期のトランザクションリソースであることを示す。対象デジタル証明書をトランザクションリソースとして合意認証局に対応するブロックチェーンに書き込む時に、新しいブロックを作成し、対象デジタル証明書を作成した新しいブロックに書き込んでもよい。

【0060】

ブロックチェーンにおけるアカウントは、公開鍵が一方向の暗号化ハッシュアルゴリズムを経て得られるアドレスと呼ばれてもよい。ハッシュアルゴリズムは、任意長の入力を受信して指紋ダイジェストを生成する一方向関数である。公開鍵によってアドレスを生成する時に使用するアルゴリズムはＳＨＡ（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ、
セキュアハッシュアルゴリズム）又はＲＩＰＥＭＤ（ｔｈｅ ＲＡＣＥ Ｉｎｔｅｇｒｉｔｙ Ｐｒｉｍｉｔｉｖｅｓ Ｅｖａｌｕａｔｉｏｎ Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ、初期完全性検証メッセージダイジェスト）アルゴリズムであってもよく、例えば、ＳＨＡ２５６又はＲＩＰＥＭＤ１６０アルゴリズムである。

【0061】

本願の実施例では、身元認証情報に対して合意認証を行い、得た身元認証結果は認証合格である場合、対象デジタル証明書をブロックチェーンに書き込み、認証局がハイジャックされれば、ブロックチェーンにおいてデジタル証明書を書き込むことが困難になり、そして、デジタル証明書は、トランザクションリソースとしてブロックに書き込まれ、受信アカウントは、デジタル証明書生成リクエスト受信ノードに対応するアカウントであり、他のノードは、デジタル証明書を随意に変更したり取り消したりできないことにより、デジタル証明書の安全性が保証され、デジタル証明書の信頼度が向上し、ネットワークセキュリティも向上する。

【0062】

一実施例では、図６に示すように、ステップＳ４１０である対象デジタル証明書をトランザクションリソースとして合意認証局に対応するブロックチェーンに書き込むステップは、具体的に以下のステップを含んでもよい。

【0063】

ステップＳ６０２は、第１証明書トランザクションレコードであって、そのトランザクションリソースは対象デジタル証明書であり、その中の転出アカウントはプリセット初期アカウントであり、その中の受信アカウントはデジタル証明書生成リクエスト受信ノードに対応する証明書発行アカウントである、第１証明書トランザクションレコードを生成する。

【0064】

具体的に、証明書トランザクションレコードは、今回のトランザクションにおいてトランザクションリソースを転出する転出アカウントと、トランザクションリソースを受信する受信アカウントと、を含んでもよい。トランザクションレコードは、デジタル証明書そのもの又はデジタル証明書に対応する識別子を含む。プリセット初期アカウントは予め設定されたもので、現在のトランザクションを行う前に、トランザクションリソースが初期で、トランザクションを行っていないリソースであり、ビットコインのトランザクションの採掘に対応するＣｏｉｎｂａｓｅトランザクションに相当することを示すために用いられ、プリセット初期アカウントの具体的な値は、必要に応じて設定されてもよく、例えば、すべて０で、その中の文字の数が必要に応じて設定される文字列であってもよい。証明書発行アカウントは証明書を発行するためのアカウントである。受信アカウントが証明書発行アカウントタイプである場合は、デジタル証明書が発行状態にあり、有効なデジタル証明書であることを示す。証明書トランザクションレコードは、証明書トランザクションの時間などの情報をさらに含んでもよい。

【0065】

一実施例では、証明書トランザクションレコードにおける転出アカウントは、当該証明書トランザクションレコードの１つ前のトランザクションレコードにおける受信アカウントであってもよく、あるいは、当該証明書トランザクションレコードの１つ前の証明書トランザクションレコードに対応するトランザクション識別子を用いてトランザクションの入力を識別するものとしてもよく、すなわち、転出アカウントは、１つ前のトランザクションレコードに対応するトランザクション識別子を用いて示すものとしてもよい。

【0066】

ステップＳ６０４は、第１証明書トランザクションレコードを合意認証局に対応するブロックチェーンに書き込む。

【0067】

具体的に、第１証明書トランザクションレコードを得た後、第１証明書トランザクションレコードを、ブロックに当該第１証明書トランザクションレコードを記憶させるように、合意認証局に対応するブロックチェーンのブロックに書き込む。第１証明書トランザクションレコードをブロックに書き込む時に、ブロックチェーンにおけるノードもブロックにおいて第１証明書トランザクションレコードを記憶するように、第１証明書トランザクションレコードをブロードキャストすることが理解できる。第１証明書トランザクションレコードをブロードキャストする前に、秘密鍵を用いて第１証明書トランザクションレコードを署名し、署名した第１証明書トランザクションレコードをブロードキャストする。

【0068】

一実施例では、第１証明書トランザクションレコードに対応する第１トランザクション識別子を生成した後、第１トランザクション識別子を証明書申請ノードに送信する。このように、証明書申請ノードと通信するノードは、当該証明書申請ノードに対応する第１トランザクション識別子及び対象デジタル証明書を取得するとともに、証明書検証を行うように、第１トランザクション識別子に基づいて、ブロックチェーンにおいて対象デジタル証明書がブロックチェーンに記憶するトランザクションレコードを取得することができる。

【0069】

一実施例では、対象デジタル証明書をブロックチェーンに挿入した後、対象デジタル証明書を取り消したり、更新したりしてもよく、認証局による対象デジタル証明書に対する操作は更新操作又は取り消し操作である場合、第２証明書トランザクションレコードを生成し、第２トランザクションレコードをブロックチェーンに書き込み、ただし、第２証明書トランザクションレコードのトランザクションリソースは対象デジタル証明書である。対象デジタル証明書に対する操作は更新操作である場合、第２証明書トランザクションレコードにおける受信アカウントは、更新操作に対応する対象受信アカウントタイプに対応する第２アカウントであり、対象デジタル証明書に対する操作は取り消し操作である場合、第２証明書トランザクションレコードにおける受信アカウントは、取り消し操作に対応する対象受信アカウントタイプに対応する第２アカウントである。

【0070】

第２証明書トランザクションレコードにおける転出アカウントは、第２証明書トランザクションレコードの１つ前のトランザクションレコードにおける受信アカウントであってもよいことが理解でき、例えば、第２証明書トランザクションレコードの１つ前のトランザクションレコードが第１証明書トランザクションレコードである場合、第２証明書トランザクションレコードにおける転出アカウントは、第１トランザクションレコードにおける受信アカウントである第１アカウントである。あるいは、第２証明書トランザクションレコードの１つ前のトランザクションレコードに対応するトランザクション識別子を用いてトランザクションの入力を識別してもよく、すなわち、転出アカウントは、１つ前のトランザクションレコードに対応するトランザクション識別子を用いて示すものとしてもよい。

【0071】

ブロックチェーンにおいて、初めてデジタル証明書をブロックチェーンに書き込む操作を挿入操作と呼び、挿入操作をトランザクションとし、トランザクションレコードを形成してブロックチェーンに書き込み、操作リクエストの操作タイプに基づいて、対象デジタル証明書を受信する対象受信アカウントタイプを決定し、第２証明書トランザクションレコードであって、その中の受信アカウントが対象受信アカウントタイプに対応する第２アカウントである第２トランザクションレコードを生成し、したがって、異なるアカウントタイプを用いて、デジタル証明書がすでに取り消されたか否か、又は更新されるか否かを示す。記憶されるトランザクションレコードは、一般的に、改竄できないため、引き続いてデジタル証明書を更新したり取り消したりする時に、デジタル証明書に対応する操作をトランザクションとし、操作のタイプに基づいて対応するトランザクションレコードを形成し、ブロックチェーンに記憶するものとしてもよい。このように、デジタル証明書の状態を調べる場合は、最新のトランザクションレコードに対応するアカウントタイプに基づいて、デジタル証明書がすでに更新されたか否か、又は取り消されるか否かを決定することができる。

【0072】

一実施例では、認証局は、証明書申請ノードがインタラクションノードに第２トランザクション識別子を送信するように、証明書申請ノードに第２証明書トランザクションレコードに対応する第２トランザクション識別子を返信してもよく、検証リクエストは、第２トランザクション識別子を持つものとしてもよい。

【0073】

一実施では、対象トランザクションレコードは最新のトランザクションレコードであり、検証リクエストは対象デジタル証明書に対応するトランザクション識別子を持ち、ブロックチェーンから、対象デジタル証明書に対応する対象トランザクションレコードを取得するステップは、トランザクション識別子に基づいて、対象デジタル証明書に対応するトランザクションチェーンを取得し、トランザクションチェーンの末端にあるトランザクションレコードを最新のトランザクションレコードとするステップであって、トランザクションチェーンで中の各トランザクションレコードがトランザクションの順序に従って配列されるステップを含む。トランザクションチェーンは、デジタル証明書に対応するトランザクションレコードを記憶するブロックチェーンであってもよい。

【0074】

具体的に、最新のトランザクションレコードは、対象デジタル証明書に対応するトランザクションレコードうち、トランザクションレコードの時刻が最も遅いトランザクションレコードである。ブロックチェーンにおいて、対象デジタル証明書に対する操作を対象デジタル証明書に対するトランザクションと見なすため、ブロックチェーンに対象デジタル証明書のトランザクションレコードが記憶され、対象デジタル証明書のトランザクションレコードから、トランザクションの時刻が最も遅いトランザクションレコードを取得して最新のトランザクションレコードとすることができる。

【0075】

ブロックチェーンにおけるトランザクションリソースのトランザクションレコードは、前後が接続されており、トランザクションチェーンは、１つのトランザクションが親トランザクションの出力を消耗するとともに、その後のトランザクション（サブトランザクション）のために入力を生じるという形式を有する。トランザクションチェーンにおける各トランザクションレコードは、トランザクションの順序に従って接続されるため、トランザクション識別子に基づいて、対象デジタル証明書に対応するトランザクションチェーンを取得し、トランザクションチェーンの末端にあるトランザクションレコードを最新のトランザクションレコードとすることができる。ただし、トランザクションチェーンの末端とは、トランザクションの時刻が最も遅いトランザクションレコードがあるエンドポイントである。各トランザクションレコードには親トランザクションに対応するトランザクション識別子が記録されている。図７に示すように、１つのトランザクションチェーンを示す図である。図７において、トランザクション識別子が１００１＃のトランザクションレコードは、デジタル証明書をブロックチェーンに書き込む操作に対応するレコードであり、１００１＃は２００１＃の親トランザクションであり、２００１＃は３００１＃の親トランザクションである。トランザクションレコードは、デジタル証明書そのもの又はデジタル証明書に対応する識別子を含んでもよい。図７から分かるように、トランザクション入力は、前回のトランザクションに対応するトランザクション識別子である。トランザクション出力は、ユーザに対応するアカウントであり、アドレスと呼ばれてもよい。１つのトランザクションレコードには、複数のトランザクション出力が存在してもよく、１つのトランザクションレコードは、複数のトランザクションリソースを含んでもよい。

【0076】

一実施例では、検証リクエストは第２トランザクション識別子を持ち、第２トランザクション識別子に基づいて、対象デジタル証明書に対応するトランザクションチェーンを取得することができる。第２トランザクション識別子は第２証明書トランザクションレコードに対応する識別子である。認証局は、第２証明書トランザクションレコードを生成する時に、証明書申請ノードが対応するインタラクションノードに第２トランザクション識別子を送信するように、証明書申請ノードに第２トランザクション識別子を送信してもよい。

【0077】

一実施例では、検証リクエストは第１トランザクション識別子を持ち、トランザクションチェーンにより、対象デジタル証明書の第１トランザクション識別子に基づいて、最新のトランザクションレコードを取得することができ、このように、第２トランザクションレコードに対応する第２トランザクション識別子を証明書申請ノードに適時送信せず、証明書申請ノードが第１トランザクション識別子をインタラクションノードに送信しても、第１トランザクション識別子により最新のトランザクションレコードを取得ｓ売ることができる。

【0078】

図８に示すように、一実施例では、デジタル証明書管理方法は、以下のステップをさらに含んでもよい。

【0079】

ステップＳ８０２は、検証リクエストに基づいて、ブロックチェーンから対象デジタル証明書に対応するルート証明書を取得する。

【0080】

具体的に、ルート証明書は、認証局が自分に発布する証明書であり、トラストチェーンの開始点である。ルート証明書は、認証局が発布するデジタル証明書を検証するために用いられ、デジタル証明書の正当及び有効性を確認し、すなわち、対象デジタル証明書が確かにＣＡ機構によって発行されるか否かを検証するように、ルート証明書における公開鍵を用いてデジタル証明書におけるデジタル署名を検証することできる。ルート証明書はブロックチェーンに記憶されてもよい。ルート証明書が改竄される可能性を低減するように、ルート証明書をブロックチェーンの１つ目のブロックであるブロックチェーンのジェネシスブロックに記憶してもよい。

【0081】

ステップＳ８０４は、ルート証明書に基づいて、対象デジタル証明書を検証し、ルート検証結果を取得する。

【0082】

具体的に、ルート検証結果は検証合格又は検証失敗であってもよい。ルート証明書を得た後、ルート証明書における公開鍵を取得して、対象デジタル証明書のデジタル署名を検証することができ、デジタル署名が検証に合格すると確認すれば、検証成功になり、デジタル署名が検証に不合格であれば、検証失敗になる。

【0083】

ステップＳ８０６は、ルート検証結果は検証失敗であるか否かを判断する。

【0084】

具体的に、ルート検証結果は検証失敗である場合、ステップＳ８０８に進む。ルート検証結果は検証成功である場合、ステップＳ２０４に進む。

【0085】

ステップＳ８０８は、ルート検証結果は検証失敗である場合、対象デジタル証明書に対応する検証結果を検証失敗として確認する。

【0086】

具体的に、ルート検証結果は検証失敗である場合、対象デジタル証明書に対応する検証結果を検証失敗として確認し、対象デジタル証明書に対する検証を続ける必要がなく、ルート検証結果は検証成功である場合、ブロックチェーンから対象デジタル証明書に対応する最新のトランザクションレコードを取得するステップに進み、対象デジタル証明書に対する検証を続ける。

【0087】

一実施例では、ルート証明書、証明書発行アカウント及び証明書回収アカウントは、認証局に記憶されてもよいし、ブロックチェーンに記憶されてもよく、例えば、ルート証明書、証明書発行アカウント及び証明書回収アカウントはブロックチェーンのくあｓに記憶されてもよい。検証リクエストを受信する認証局とデジタル証明書生成リクエストを受信する認証局とは同じであってもよいし、異なってもよいことが理解できる。例えば、ルート証明書、証明書発行アカウント及び証明書回収アカウントは、デジタル証明書生成リクエストを受信する認証局に記憶されてもよく、このように、ただデジタル証明書生成リクエストを受信する認証局こそ、対象デジタル証明書を検証できる。各認証局は、ルート証明書、デジタル証明書生成リクエストを受信するノードに対応する証明書発行アカウント及び証明書回収アカウントを記憶してもよく、あるいは、ブロックチェーン上のルート証明書、証明書発行アカウント、証明書回収アカウントは合意に参加する認証局に向けて公開されて調べることができる。このように、各認証局は、いずれも対象デジタル証明書を検証する検証リクエストを受信し、対象デジタル証明書を検証することができ、証明書を発布する認証局がハイジャックされ、又は崩れるとしても、他の認証局を用いて検証することができる。すなわち、異なる認証局の間は、互いに信頼でき、証明書を発布する認証局しか対象デジタル証明書を検証できないことに制限されず、１つの認証局は、複数の認証局が発布するデジタル証明書を検証することができる。

【0088】

一実施例では、ブロックチェーンに対象デジタル証明書が存在するか否かを確認してもよく、存在すれば、対象デジタル証明書が検証に合格することを確認する。ブロックチェーンの数字が改竄されにくいため、ブロックチェーンにおいて一致するデジタル証明書が存在する場合は、当該デジタル証明書が信頼できることを示す。

【0089】

図９は、一実施例にて提供されるデジタル証明書の検証方法の利用環境の図であり、当該利用環境は、証明書申請ノードと、同じブロックチェーンに属する認証局１、認証局２、認証局３及び認証局４とを含む。以下、図９を参照しながら、本願の実施例にて提供される証明書検証方法について説明する。

【0090】

１、デジタル証明書を申請する必要がある場合、証明書申請ノードは、身元認証情報を持つデジタル証明書生成リクエストを認証局１に送信する。

【0091】

２、認証局１はデジタル証明書生成リクエストを受信し、合意認証を行うように、認証局１は認証局２、認証局３及び認証局４に身元認証情報を送信する。

【0092】

３、合意認証の結果に基づいて、身元認証結果を合格として得る場合、認証局１は対象デジタル証明書及び対応する第１トランザクションレコードを生成し、第１トランザクションレコードをブロックチェーンにおける最新のブロックに記憶し、対象デジタル証明書及び第１トランザクション識別子を証明書申請ノードに返信する。

【0093】

４、インタラクションノードは、証明書申請ノードとインタラクションを行う時、デジタル証明書取得リクエストを証明書申請ノードまで送信する。

【0094】

５、証明書申請ノードはインタラクションノードに対象デジタル証明書及び第１トランザクション識別子を返信する。

【0095】

６、インタラクションノードは、第１トランザクション識別子及び対象デジタル証明書を持つ検証リクエストを認証局４に送信する。

【0096】

７、認証局４は、ジェネシスブロックからルート証明書を取得し、ルート証明書に基づいて、対象デジタル証明書を検証し、ルート検証結果を取得する。

【0097】

８、ルート検証結果は検証合格である場合、認証局４は、第１トランザクション識別子に基づいて、対象デジタル証明書に対応するトランザクションチェーンにおける最新のトランザクションレコードの受信アカウントタイプを取得し、最新のトランザクションレコードの受信アカウントタイプに基づいて検証結果を決定する。例えば、回収アカウントタイプであれば、対象デジタル証明書がすでに取り消され、検証結果は失敗であることが示される。

【0098】

検証リクエストを受信して検証するものは、インタラクションノードは信頼できると考えれば、ブロックチェーンの他のノードであってもよいことが理解できる。あるいは、インタラクションノードはブロックチェーンにおけるノードであってもよく、このように、インタラクションノードもローカルに記憶されているブロックチェーンデータからルート証明書及びトランザクションレコードを取得して、検証する。

【0099】

図１０に示すように、一実施例では、デジタル証明書検証装置が提供され、当該デジタル証明書検証装置は、上記の認証ノード４に集積してもよく、具体的に、検証リクエスト受信モジュール１００２と、対象トランザクションレコード取得モジュール１００４と、対象アカウントタイプ取得モジュール１００６と、検証結果決定モジュール１００８とを含んでもよい。

【0100】

検証リクエスト受信モジュール１００２は、対象デジタル証明書を検証する検証リクエストを受信するために用いられ、
対象トランザクションレコード取得モジュール１００４は、ブロックチェーンから、トランザクションリソースとして記憶される対象デジタル証明書に対応する対象トランザクションレコードを取得するために用いられ、
対象アカウントタイプ取得モジュール１００６は、対象トランザクションレコードに対応する対象アカウントタイプを取得するために用いられ、ただし、異なるアカウントタイプが異なる証明書操作状態に対応し、
検証結果決定モジュール１００８は、対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を決定するために用いられる。

【0101】

１つの実施例では、図１１に示すように、デジタル証明書検証装置は、
対象デジタル証明書を操作する操作リクエストを受信するための操作リクエスト受信モジュール１１０２と、
操作リクエストの操作タイプに基づいて、対象デジタル証明書に対応する対象受信アカウントタイプを決定するための受信アカウントタイプ決定モジュール１１０４と、
操作リクエストに対応する証明書トランザクションレコードを生成し、証明書トランザクションレコードをブロックチェーンに書き込むためのモジュールであって、証明書トランザクションレコードのトランザクションリソースは対象デジタル証明書であり、証明書トランザクションレコードにおける受信アカウントは対象受信アカウントタイプに対応するアカウントである、証明書トランザクションレコード生成モジュール１１０６とをさらに含む。

【0102】

１つの実施例では、受信アカウントタイプ決定モジュール１１０４は、操作リクエストに対応する操作タイプが更新操作タイプ又は挿入操作タイプである場合、対象受信アカウントタイプを証明書発行アカウントタイプとして決定するために用いられる。

【0103】

１つの実施例では、受信アカウントタイプ決定モジュール１１０４は、操作リクエストに対応する操作タイプが取り消し操作タイプである場合、対象受信アカウントタイプを証明書回収アカウントタイプとして決定するために用いられる。

【0104】

１つの実施例では、対象トランザクションレコードは最新のトランザクションレコードであり、対象アカウントタイプ取得モジュール１００６は、最新のトランザクションレコードに対応する、対象デジタル証明書を受信する現在の受信アカウントタイプを取得して、対象アカウントタイプとするために用いられ、検証結果決定モジュール１００８は、現在の受信アカウントタイプが証明書発行アカウントタイプである場合、対象デジタル証明書に対応する検証結果を検証成功として決定するために用いられる。

【0105】

１つの実施例では、対象アカウントタイプ取得モジュール１００６は、最新のトランザクションレコードに対応する、対象デジタル証明書を受信する現在の受信アカウントタイプを取得して、対象アカウントタイプとするために用いられ、検証結果決定モジュール１００８は、現在の受信アカウントタイプが証明書回収アカウントタイプである場合、対象デジタル証明書に対応する検証結果を検証失敗として決定するために用いられる。

【0106】

１つの実施例では、検証リクエストは対象デジタル証明書に対応するトランザクション識別子を持ち、対象トランザクションレコード取得モジュール１００４は、第１トランザクション識別子に基づいて、対象デジタル証明書に対応するトランザクションチェーンを取得し、トランザクションチェーンの末端にあるトランザクションレコードを最新のトランザクションレコードとするために用いられ、ただし、トランザクションチェーン中の各トランザクションレコードがトランザクションの順序に従って配列される。

【0107】

一実施例では、図１２に示すように、証明書検証装置は、
証明書申請ノードから送信された、身元認証情報を持つデジタル証明書生成リクエストを受信するための証明書生成リクエスト受信モジュール１２０２と、
身元認証情報を各合意認証局に送信して認証し、各合意認証局が身元認証情報に基づいて認証することによって得た認証結果を取得するための認証モジュール１２０４と、
各合意認証局の認証結果に基づいて、証明書申請ノードに対応する身元認証結果を決定するための身元認証結果決定モジュール１２０６と、
デジタル証明書生成リクエストに基づいて、証明書申請ノードに対応する対象デジタル証明書を生成するための証明書生成モジュール１２０８と、
身元認証結果は認証合格である場合、対象デジタル証明書をトランザクションリソースとして合意認証局に対応するブロックチェーンに書き込むために用いたれ、ただし、対象デジタル証明書に対応する受信アカウントはデジタル証明書生成リクエスト受信ノードに対応する第１アカウントである書き込みモジュールとをさらに含む。

【0108】

１つの実施例では、証明書検証装置は、
検証リクエストに基づいて、ブロックチェーンから対象デジタル証明書に対応するルート証明書を取得するためのルート証明書取得モジュールと、
ルート証明書に基づいて、対象デジタル証明書を検証し、ルート検証結果を取得するためのルート検証結果取得モジュールと、
ルート検証結果は検証失敗である場合、対象デジタル証明書に対応する検証結果を検証失敗として確認し、そうでなければ、ブロックチェーンから、対象デジタル証明書に対応する対象トランザクションレコードを取得するステップに進むための進入モジュールとをさらに含む。

【0109】

図１３は、一実施例におけるコンピュータ機器の内部構造図を示す。当該コンピュータ機器は、具体的に、図１における認証局であってもよい。図１３に示すように、当該コンピュータ機器は、システムバスを介して接続されるプロセッサと、メモリと、ネットワークインタフェースと、入力装置とを含む。ただし、メモリは不揮発性記憶媒体と内部メモリとを含む。当該コンピュータ機器の不揮発性記憶媒体には、オペレーティングシステムが記憶されており、さらに、コンピュータプログラムが記憶されており、当該コンピュータプログラムがプロセッサによって実行されると、プロセッサはデジタル証明書の検証方法を実現することができる。当該内部メモリにもコンピュータプログラムが記憶されてもよく、当該コンピュータプログラムがプロセッサによって実行されると、プロセッサはデジタル証明書の検証方法を実行することができる。コンピュータ機器の入力装置は、ディスプレイ上を覆うタッチレイヤであってもよく、コンピュータ機器のハウジング上に設置されたボタン、トラックボール又はタッチパネルであってもよく、さらに、外付けのキーボード、タッチパネル又はマウスなどであってもよい。

【0110】

当業者であれば、図１３に示す構造は、本願の解決手段に関連する一部の構造のブロック図に過ぎず、本願の解決手段が適用されるコンピュータ機器を限定するものではなく、具体的なコンピュータ機器は、図示より多く、又は図示より少ない部材を含み、又はいくつかの部材を組み合わせ、又は異なる部材配置を有するものとしてもよいことを理解できる。

【0111】

一実施例では、本願が提供するデジタル証明書検証装置は、コンピュータプログラムの形式として実現でき、コンピュータプログラムは、図１３に示すコンピュータ機器上で実行できる。コンピュータ機器のメモリは、当該デジタル証明書検証装置を構成する各プログラムモジュールを記憶することができ、例えば、図１０に示す検証リクエスト受信モジュール１００２、対象トランザクションレコード取得モジュール１００４、対象アカウントタイプ取得モジュール１００６及び検証結果決定モジュール１００８が挙げられる。各プログラムモジュールからないコンピュータプログラムは、本明細書に記載される本願の各実施例のデジタル証明書の検証方法におけるステップをプロセッサに実行させる。

【0112】

例えば、図１３に示すコンピュータ機器は、図１０に示すデジタル証明書検証装置における検証リクエスト受信モジュール１００２により、対象デジタル証明書を検証する検証リクエストを受信し、レコード取得モジュール１００４により、ブロックチェーンから対象デジタル証明書に対応する対象トランザクションレコードを取得し、対象デジタル証明書はトランザクションリソースとして記憶されており、対象アカウントタイプ取得モジュール１００６により、対象トランザクションレコードに対応する対象アカウントタイプを取得し、ただし、異なるアカウントタイプが異なる証明書操作状態に対応し、検証結果決定モジュール１００８により、対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を決定する。

【0113】

一実施例では、コンピュータ機器が提供され、コンピュータ機器は、メモリと、プロセッサと、メモリに記憶され、プロセッサ上で実行できるコンピュータプログラムとを含み、プロセッサは、コンピュータプログラムを実行する時に、対象デジタル証明書を検証する検証リクエストを受信するステップと、ブロックチェーンから対象デジタル証明書に対応する対象トランザクションレコードを取得するステップであって、前記対象デジタル証明書はトランザクションリソースとして記憶される、ステップと、対象トランザクションレコードに対応する対象アカウントタイプを取得するステップであって、異なるアカウントタイプが異なる証明書操作状態に対応する、ステップと、対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を決定するステップとを実現する。

【0114】

一実施例では、コンピュータプログラムは、対象デジタル証明書を操作する操作リクエストを受信するステップと、操作リクエストの操作タイプに基づいて、対象デジタル証明書の受信に対応する対象受信アカウントタイプを決定するステップと、操作リクエストに対応する証明書トランザクションレコードを生成し、証明書トランザクションレコードをブロックチェーンに書き込むステップであって、証明書トランザクションレコードのトランザクションリソースは対象デジタル証明書であり、証明書トランザクションレコードにおける受信アカウントは対象受信アカウントタイプに対応するアカウントである、ステップと、をプロセッサに実行させる。

【0115】

一実施例では、プロセッサが実行する、操作リクエストの操作タイプに基づいて、対象デジタル証明書の受信に対応する対象受信アカウントタイプを決定するステップは、操作リクエストに対応する操作タイプが更新操作タイプ又は挿入操作タイプである場合、対象受信アカウントタイプを証明書発行アカウントタイプとして決定するステップを含む。

【0116】

一実施例では、プロセッサが実行する、操作リクエストの操作タイプに基づいて、対象デジタル証明書の受信に対応する受信アカウントタイプを決定するステップは、
操作リクエストに対応する操作タイプが取り消し操作タイプである場合、対象受信アカウントタイプを証明書回収アカウントタイプとして決定するステップを含む。

【0117】

一実施例では、プロセッサが実行する、対象トランザクションレコードは最新のトランザクションレコードであり、対象トランザクションレコードに対応する対象アカウントタイプを取得するステップは、最新のトランザクションレコードに対応する、対象デジタル証明書を受信する現在の受信アカウントタイプを取得して、対象アカウントタイプとするステップを含み、対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を決定するステップは、現在の受信アカウントタイプが証明書発行アカウントタイプである場合、対象デジタル証明書に対応する検証結果を検証成功として決定するステップを含む。

【0118】

一実施例では、対象トランザクションレコードは最新のトランザクションレコードであり、プロセッサが実行する、対象トランザクションレコードに対応する対象アカウントタイプを取得するステップは、最新のトランザクションレコードに対応する、対象デジタル証明書を受信する現在の受信アカウントタイプを取得して、対象アカウントタイプとするステップを含み、対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を決定するステップは、現在の受信アカウントタイプが証明書回収アカウントタイプである場合、対象デジタル証明書に対応する検証結果を検証失敗として決定するステップを含む。

【0119】

一実施例では、検証リクエストは対象デジタル証明書に対応するトランザクション識別子を持ち、プロセッサが実行する、ブロックチェーンから対象デジタル証明書に対応する対象トランザクションレコードを取得するステップは、トランザクション識別子に基づいて、対象デジタル証明書に対応するトランザクションチェーンを取得し、トランザクションチェーンの末端にあるトランザクションレコードを最新のトランザクションレコードとするステップであって、トランザクションチェーン中の各トランザクションレコードがトランザクションの順序に従って配列される、ステップを含む。

【0120】

一実施例では、コンピュータプログラムはプロセッサに、検証リクエストに基づいて、ブロックチェーンから対象デジタル証明書に対応するルート証明書を取得するステップと、ルート証明書に基づいて、対象デジタル証明書を検証し、ルート検証結果を取得するステップと、ルート検証結果は検証失敗である場合、対象デジタル証明書に対応する検証結果を検証失敗として確認し、そうでなければ、ブロックチェーンから、対象デジタル証明書に対応する対象トランザクションレコードを取得するステップに進むステップとを実行させる。

【0121】

一実施例では、コンピュータ可読記憶媒体が提供され、コンピュータ可読記憶媒体にコンピュータプログラムが記憶されており、コンピュータプログラムがプロセッサによって実行される時に、対象デジタル証明書を検証する検証リクエストを受信ステップと、ブロックチェーンから対象デジタル証明書に対応する対象トランザクションレコードを取得するステップであって、対象デジタル証明書はトランザクションリソースとして記憶される、ステップと、対象トランザクションレコードに対応する対象アカウントタイプを取得するステップであって、異なるアカウントタイプが異なる証明書操作状態に対応する、ステップと、対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を決定するステップと、をプロセッサに実行させる。

【0122】

一実施例では、コンピュータプログラムは、対象デジタル証明書を操作する操作リクエストを受信するステップと、操作リクエストの操作タイプに基づいて、対象デジタル証明書の受信に対応する対象受信アカウントタイプを決定するステップと、操作リクエストに対応する証明書トランザクションレコードを生成し、証明書トランザクションレコードをブロックチェーンに書き込むステップであって、証明書トランザクションレコードのトランザクションリソースは対象デジタル証明書であり、証明書トランザクションレコードにおける受信アカウントは対象受信アカウントタイプに対応するアカウントである、ステップと、をプロセッサに実行させる。

【0123】

一実施例では、プロセッサが実行する、操作リクエストの操作タイプに基づいて、対象デジタル証明書の受信に対応する対象受信アカウントタイプを決定するステップは、操作リクエストに対応する操作タイプが更新操作タイプ又は挿入操作タイプである場合、対象受信アカウントタイプを証明書発行アカウントタイプとして決定するステップを含む。

【0124】

一実施例では、プロセッサが実行する、操作リクエストの操作タイプに基づいて、対象デジタル証明書の受信に対応する受信アカウントタイプを決定するステップは、
操作リクエストに対応する操作タイプが取り消し操作タイプである場合、対象受信アカウントタイプを証明書回収アカウントタイプとして決定するステップを含む。

【0125】

一実施例では、プロセッサが実行する、対象トランザクションレコードは最新のトランザクションレコードであり、対象トランザクションレコードに対応する対象アカウントタイプを取得するステップは、最新のトランザクションレコードに対応する、対象デジタル証明書を受信する現在の受信アカウントタイプを取得して、対象アカウントタイプとするステップを含み、対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を決定するステップは、現在の受信アカウントタイプが証明書発行アカウントタイプである場合、対象デジタル証明書に対応する検証結果を検証成功として決定するステップを含む。

【0126】

一実施例では、対象トランザクションレコードは最新のトランザクションレコードであり、プロセッサが実行する、対象トランザクションレコードに対応する対象アカウントタイプを取得するステップは、最新のトランザクションレコードに対応する、対象デジタル証明書を受信する現在の受信アカウントタイプを取得して、対象アカウントタイプとするステップを含み、対象アカウントタイプに基づいて、対象デジタル証明書に対応する検証結果を決定するステップは、現在の受信アカウントタイプが証明書回収アカウントタイプである場合、対象デジタル証明書に対応する検証結果を検証失敗として決定するステップを含む。

【0127】

一実施例では、検証リクエストは対象デジタル証明書に対応するトランザクション識別子を持ち、プロセッサが実行する、ブロックチェーンから対象デジタル証明書に対応する対象トランザクションレコードを取得するステップは、トランザクション識別子に基づいて、対象デジタル証明書に対応するトランザクションチェーンを取得し、トランザクションチェーンの末端にあるトランザクションレコードを最新のトランザクションレコードとするステップであって、トランザクションチェーン中の各トランザクションレコードがトランザクションの順序に従って配列される、ステップを含む。

【0128】

一実施例では、コンピュータプログラムは、検証リクエストに基づいて、ブロックチェーンから対象デジタル証明書に対応するルート証明書を取得するステップと、ルート証明書に基づいて、対象デジタル証明書を検証し、ルート検証結果を取得するステップと、ルート検証結果は検証失敗である場合、対象デジタル証明書に対応する検証結果を検証失敗として確認し、そうでなければ、ブロックチェーンから、対象デジタル証明書に対応する対象トランザクションレコードを取得するステップに進むステップと、をプロセッサに実行させる。

【0129】

本願の各実施例のフローチャートにおける各ステップは、矢印が示すように表示されるが、これらのステップは、必ずしも矢印が示す順序に従って実行するものではないことが理解できる。本明細書に明確に説明されない限り、これらのステップの実行は、厳しい順序に限定されず、これらのステップは他の順序で実行してもよい。そして、各実施例における少なくとも一部のステップは、複数のサブステップ又は複数の段階を含んでもよく、これらのサブステップ又は段階は、必ずしも同じ時刻で実行して完成するものではなく、異なる時刻で実行してもよく、これらのサブステップ又は段階の実行順序は、必ずしも順次行うものではなく、他のステップ又は他のステップのサブステップ若しくは段階の少なくとも一部と順番又は交替で実行してもよい。

【0130】

当業者であれば、上記実施例の方法におけるフローのすべて又は一部は、コンピュータプログラムによって関連するハードウェアを指令して完成してもよく、プログラムは不揮発性コンピュータ可読記憶媒体に記憶されてもよく、当該プログラムは、実行時に、上記各方法の実施例のフローを含んでもよい。ただし、本願にて提供される各実施例に用いるメモリ、ストレージ、データベース又は他の媒体に対する援用は、いずれも不揮発性及び／又は揮発性メモリを含んでもよい。不揮発性メモリは、リードオンリーメモリ（ＲＯＭ）、プログラミングＲＯＭ（ＰＲＯＭ）、電気的プログラマブルＲＯＭ（ＥＰＲＯＭ）、電気的消去可能プログラマブルＲＯＭ（ＥＥＰＲＯＭ）又はフラッシュメモリを含んでもよい。揮発性メモリはランダムアクセスメモリ（ＲＡＭ）又は外部キャッシュを含んでもよい。制限ではなく、説明として、ＲＡＭは、例えば、スタティックＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、同期式ＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲＳＤＲＡＭ）、強化型ＳＤＲＡＭ（ＥＳＤＲＡＭ）、シンクリンク（Ｓｙｎｃｈｌｉｎｋ）ＤＲＡＭ（ＳＬＤＲＡＭ）、メモリバス（Ｒａｍｂｕｓ）ダイレクトＲＡＭ（ＲＤＲＡＭ）、ダイレクトメモリバスダイナミックＲＡＭ（ＤＲＤＲＡＭ）及びメモリバスダイナミックＲＡＭ（ＲＤＲＡＭ）など、複数種の形式で得ることができる。

【0131】

以上の実施例の各技術的特徴は、任意に組み合わせてもよく、説明を簡潔にするために、上記実施例における各技術的特徴の可能な組み合わせをすべて説明しないが、これらの技術的特徴の組み合わせは、矛盾しない限り、すべて本明細書に記載される範囲と見なすべきである。

【0132】

以上に記載される実施例は、本願のいくつかの実施形態を具体的で詳細的に示すが、本願の特許請求の範囲を限定するものと見なすべきではない。なお、当業者であれば、本願の思想を逸脱せず、変形及び改良をいろいろ行うことができ、これらはすべて本願の保護範囲に属する。したがって、本願の特許の保護範囲は添付する特許請求の範囲を基準とすべきである。

【符号の説明】

【0133】

１００２ 検証リクエスト受信モジュール
１００４ 対象トランザクションレコード取得モジュール
１００６ 対象アカウントタイプ取得モジュール
１００８ 検証結果決定モジュール
１１０２ 操作リクエスト受信モジュール
１１０４ 受信アカウントタイプ決定モジュール
１１０６ 証明書トランザクションレコード生成モジュール
１２０２ 証明書生成リクエスト受信モジュール
１２０４ 認証モジュール
１２０６ 身元認証結果決定モジュール
１２０８ 証明書生成モジュール

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】