特許 7093428 電子証明書の管理方法、装置、コンピュータ装置及びコンピュータプログラム

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

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

(11)【特許番号】

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

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

(54)【発明の名称】電子証明書の管理方法、装置、コンピュータ装置及びコンピュータプログラム

(51)【国際特許分類】

   H04L 9/32 20060101AFI20220622BHJP

   G06F 21/33 20130101ALI20220622BHJP

   G09C 1/00 20060101ALI20220622BHJP

【ＦＩ】

H04L9/32 200B

G06F21/33

G09C1/00 640D

【請求項の数】 14

(21)【出願番号】P 2020568339

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

(65)【公表番号】

(43)【公表日】2021-09-30

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

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

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

【審査請求日】2020-12-07

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

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

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

(73)【特許権者】

【識別番号】514187420

【氏名又は名称】テンセント・テクノロジー・（シェンジェン）・カンパニー・リミテッド

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】グオ，ルォイ

(72)【発明者】

【氏名】リ，マオカイ

(72)【発明者】

【氏名】ジャン，ジエンジュン

(72)【発明者】

【氏名】ゾン，ジェン

(72)【発明者】

【氏名】タン，ズチャオ

(72)【発明者】

【氏名】ルゥ，ジィグアン

【審査官】青木 重徳

(56)【参考文献】

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

【文献】特許第６３４０１０７（ＪＰ，Ｂ１）

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

【文献】中国特許出願公開第１０５７０１３７２（ＣＮ，Ａ）

【文献】東角 芳樹 ほか，コンソーシアムチェーンにおける証明書管理に関する一考察，２０１７年 暗号と情報セキュリティシンポジウム（ＳＣＩＳ２０１７）予稿集 ［ＵＳＢ］，日本，２０１７年 暗号と情報セキュリティシンポジウム実行，2017年01月24日，１Ｆ２－３，ｐ．１－４

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

Ｈ０４Ｌ ９／３２

Ｇ０６Ｆ ２１／３３

Ｇ０９Ｃ １／００

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

【請求項1】

コンピュータ装置により実行される電子証明書の管理方法であって、
前記コンピュータ装置が、
証明書申請ノードから送信された電子証明書生成リクエストを受信するステップであって、前記電子証明書生成リクエストはアイデンティティ認証情報を持っている、ステップと、
前記アイデンティティ認証情報を各コンセンサス認証センターに送信し、各前記コンセンサス認証センターが前記アイデンティティ認証情報に基づいて認証した認証結果を取得するステップと、
各前記コンセンサス認証センターの認証結果に基づいて、前記証明書申請ノードに対応するアイデンティティ認証結果を決定するステップと、
前記アイデンティティ認証結果が認証通過である場合、前記電子証明書生成リクエストに基づいて前記証明書申請ノードに対応するターゲット電子証明書を生成するステップと、
前記ターゲット電子証明書を取引リソースとして前記コンセンサス認証センターに対応するブロックチェーンに書き込むステップと、を含み、
前記ターゲット電子証明書を取引リソースとして前記コンセンサス認証センターに対応するブロックチェーンに書き込むステップは、
第１の証明書取引記録を生成するステップであって、前記第１の証明書取引記録の取引リソースが前記ターゲット電子証明書であり、前記第１の証明書取引記録におけるトランスファーフロムアカウントが所定の初期アカウントであり、前記第１の証明書取引記録における受信アカウントが電子証明書生成リクエスト受信ノードに対応する証明書発行アカウントである、ステップと、
前記第１の証明書取引記録を前記コンセンサス認証センターに対応するブロックチェーンに書き込むステップと、を含む、管理方法。

【請求項2】

前記ターゲット電子証明書を取引リソースとして前記コンセンサス認証センターに対応するブロックチェーンに書き込むステップの後に、さらに、
前記コンピュータ装置が、
前記ターゲット電子証明書を操作するための操作リクエストを受信するステップと、
前記操作リクエストの操作種別に基づいて、前記ターゲット電子証明書を受信する受信アカウント種別を決定するステップと、
第２の証明書取引記録を生成し、前記第２の証明書取引記録を前記ブロックチェーンに書き込むステップであって、前記第２の証明書取引記録の取引リソースが前記ターゲット電子証明書であり、前記第２の証明書取引記録における受信アカウントが前記受信アカウント種別に対応する第２のアカウントである、ステップと、を含む、請求項１に記載の管理方法。

【請求項3】

前記操作リクエストの操作種別に基づいて前記ターゲット電子証明書を受信する受信アカウント種別を決定するステップは、
前記操作リクエストの操作種別が更新操作種別である場合、前記受信アカウント種別が証明書発行アカウント種別であると決定するステップを含む、請求項２に記載の管理方法。

【請求項4】

前記操作リクエストの操作種別に基づいて前記ターゲット電子証明書を受信する受信アカウント種別を決定するステップは、
前記操作リクエストの操作種別が取り消し操作種別である場合、前記受信アカウント種別が証明書回収アカウント種別であると決定するステップを含む、請求項２に記載の管理方法。

【請求項5】

前記ターゲット電子証明書を取引リソースとして前記コンセンサス認証センターに対応するブロックチェーンに書き込むステップの後に、さらに、
前記コンピュータ装置が、
前記ターゲット電子証明書を検証するための検証リクエストを受信するステップと、
前記ブロックチェーンから前記ターゲット電子証明書に対応する最新の取引記録を取得するステップと、
前記最新の取引記録における受信アカウント種別に基づいて前記ターゲット電子証明書に対応する検証結果を決定するステップと、を含む、請求項１に記載の管理方法。

【請求項6】

前記最新の取引記録における受信アカウント種別に基づいて前記ターゲット電子証明書に対応する検証結果を決定するステップは、
前記最新の取引記録における受信アカウント種別が証明書回収アカウント種別である場合、前記ターゲット電子証明書が取り消されており、且つ前記ターゲット電子証明書に対応する検証結果が検証失敗であると決定するステップを含む、請求項５に記載の管理方法。

【請求項7】

前記最新の取引記録における受信アカウント種別に基づいて前記ターゲット電子証明書に対応する検証結果を決定するステップは、
前記最新の取引記録における受信アカウント種別が証明書発行アカウント種別である場合、前記ターゲット電子証明書に対応する検証結果が検証成功であると決定するステップを含む、請求項５に記載の管理方法。

【請求項8】

前記検証リクエストは、前記第１の証明書取引記録に対応する第１の取引識別子を持っており、前記第１の取引識別子は、電子証明書生成リクエスト受信ノードにより前記証明書申請ノードへ送信され、さらに前記証明書申請ノードにより検証リクエスト送信ノードへ送信されるものである、請求項５に記載の管理方法。

【請求項9】

前記ブロックチェーンから前記ターゲット電子証明書に対応する最新の取引記録を取得するステップは、
前記第１の取引識別子に基づいて前記ターゲット電子証明書に対応する取引チェーンを取得し、前記取引チェーンの末端の取引記録を前記最新の取引記録とするステップであって、前記取引チェーンは取引の時間順で配列される、ステップを含む、請求項８に記載の管理方法。

【請求項10】

前記ブロックチェーンから前記ターゲット電子証明書に対応する最新の取引記録を取得するステップの前に、さらに、
前記コンピュータ装置が、
前記検証リクエストに基づいて前記ブロックチェーンから前記ターゲット電子証明書に対応するルート証明書を取得するステップであって、前記ルート証明書は前記電子証明書生成リクエスト受信ノードのアイデンティティ情報を検証するためのものである、ステップと、
前記ルート証明書に基づいて前記ターゲット電子証明書を検証して、ルート検証結果を取得するステップと、
前記ルート検証結果が検証成功である場合、前記ブロックチェーンから前記ターゲット電子証明書に対応する最新の取引記録を取得するステップを実行するステップと、を含む、請求項５に記載の管理方法。

【請求項11】

電子証明書の管理装置であって、
証明書申請ノードから送信された電子証明書生成リクエストを受信する生成リクエスト受信モジュールであって、前記電子証明書生成リクエストはアイデンティティ認証情報を持っている、生成リクエスト受信モジュールと、
前記アイデンティティ認証情報を各コンセンサス認証センターに送信し、各前記コンセンサス認証センターが前記アイデンティティ認証情報に基づいて認証した認証結果を取得するコンセンサス認証モジュールと、
各前記コンセンサス認証センターの認証結果に基づいて、前記証明書申請ノードに対応するアイデンティティ認証結果を決定するアイデンティティ認証結果取得モジュールと、
前記アイデンティティ認証結果が認証通過である場合、前記電子証明書生成リクエストに基づいて前記証明書申請ノードに対応するターゲット電子証明書を生成する証明書生成モジュールと、
前記アイデンティティ認証結果が認証通過である場合、前記ターゲット電子証明書を取引リソースとして前記コンセンサス認証センターに対応するブロックチェーンに書き込む書き込みモジュールと、を含み、
前記書き込みモジュールは、
第１の証明書取引記録を生成する第１の記録生成ユニットであって、前記第１の証明書取引記録の取引リソースが前記ターゲット電子証明書であり、前記第１の証明書取引記録におけるトランスファーフロムアカウントが所定の初期アカウントであり、前記第１の証明書取引記録における受信アカウントが電子証明書生成リクエスト受信ノードに対応する証明書発行アカウントである、第１の記録生成ユニットと、
前記第１の証明書取引記録を前記コンセンサス認証センターに対応するブロックチェーンに書き込む第１の書き込みユニットと、を含む、管理装置。

【請求項12】

前記ターゲット電子証明書を操作するための操作リクエストを受信する操作リクエスト受信モジュールと、
前記操作リクエストの操作種別に基づいて前記ターゲット電子証明書を受信する受信アカウント種別を決定するアカウント種別決定モジュールと、
第２の証明書取引記録を生成し、前記第２の証明書取引記録を前記ブロックチェーンに書き込む第２の取引記録生成モジュールであって、前記第２の証明書取引記録の取引リソースが前記ターゲット電子証明書であり、前記第２の証明書取引記録における受信アカウントが前記受信アカウント種別に対応する第２のアカウントである、第２の取引記録生成モジュールと、をさらに含む、請求項１１に記載の管理装置。

【請求項13】

プロセッサと、
前記プロセッサによって実行される際、請求項１～１０のいずれか１項に記載の電子証明書の管理方法を前記プロセッサに実行させるコンピュータプログラムが記憶されているメモリと、を含む、コンピュータ装置。

【請求項14】

コンピュータに、請求項１～１０のいずれか１項に記載の電子証明書の管理方法を実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、２０１８年７月２４日に提出された、出願番号２０１８１０８２１６８７．３で、発明の名称「電子証明書の管理方法、装置、コンピュータ装置及び記憶媒体」の中国特許出願の優先権を主張するものであり、その全ての内容は、参照により本願に組み込まれるものとする。

【0002】

本願は、コンピュータの技術分野に関し、特に電子証明書の管理方法、装置、コンピュータ装置及びコンピュータプログラムに関する。

【背景技術】

【0003】

電子証明書は、ネットワークでネットワークノードのアイデンティティを証明するための証明書類であり、アイデンティティを証明するために、ネットワークノードは、権威ある認証センターに電子証明書を申請してもよく、権威ある認証センターは、アイデンティティを認証した後に該ネットワークノードに電子証明書を発行する。

【0004】

現在、電子証明書の生成及び記憶はいずれも権威ある認証センターに集中しており、該権威ある認証センターがハイジャックされると、権威ある認証センターが生成又は記憶した電子証明書は信頼できず、ネットワークセキュリティが低くなる。

【発明の概要】

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

【0005】

本願の実施例は、従来技術におけるネットワークセキュリティが低いという問題を解決することができる、電子証明書の管理方法、装置、コンピュータ装置及びコンピュータプログラムを提供する。

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

【0006】

一態様によると、コンピュータ装置により実行される電子証明書の管理方法が提供され、該方法は、証明書申請ノードから送信された電子証明書生成リクエストを受信するステップであって、前記電子証明書生成リクエストはアイデンティティ認証情報を持っている（即ち、前記電子証明書生成リクエストにはアイデンティティ認証情報が含まれている）、ステップと、前記アイデンティティ認証情報を各コンセンサス認証センターに送信して認証し、各前記コンセンサス認証センターが前記アイデンティティ認証情報に基づいて認証した認証結果を取得するステップと、各前記コンセンサス認証センターの認証結果に基づいて前記証明書申請ノードに対応するアイデンティティ認証結果を決定するステップと、前記アイデンティティ認証結果が認証通過である場合、前記電子証明書生成リクエストに基づいて前記証明書申請ノードに対応するターゲット電子証明書を生成するステップと、前記ターゲット電子証明書を取引リソースとして前記コンセンサス認証センターに対応するブロックチェーンに書き込むステップと、を含む。

【0007】

一態様によると、電子証明書の管理装置が提供され、該装置は、証明書申請ノードから送信された電子証明書生成リクエストを受信する生成リクエスト受信モジュールであって、前記電子証明書生成リクエストはアイデンティティ認証情報を持っている、生成リクエスト受信モジュールと、前記アイデンティティ認証情報を各コンセンサス認証センターに送信して認証し、各前記コンセンサス認証センターが前記アイデンティティ認証情報に基づいて認証した認証結果を取得するコンセンサス認証モジュールと、各前記コンセンサス認証センターの認証結果に基づいて、前記証明書申請ノードに対応するアイデンティティ認証結果を決定するアイデンティティ認証結果取得モジュールと、前記アイデンティティ認証結果が認証通過である場合、前記電子証明書生成リクエストに基づいて前記証明書申請ノードに対応するターゲット電子証明書を生成する証明書生成モジュールと、前記ターゲット電子証明書を取引リソースとして前記コンセンサス認証センターに対応するブロックチェーンに書き込む書き込みモジュールと、を含む。

【0008】

一態様によると、コンピュータ装置が提供され、該装置は、プロセッサと、前記プロセッサによって実行される際、上述の電子証明書の管理方法のステップを前記プロセッサに実行させるコンピュータプログラムが記憶されているメモリと、を含む。

【0009】

一態様によると、コンピュータプログラムが提供され、該プログラムは、プロセッサによって実行される際、上述の電子証明書の管理方法のステップを前記プロセッサに実行させる。

【発明の効果】

【0010】

本願の実施例に係る技術手段による有益な効果は、少なくとも以下を含む。

【0011】

複数の認証センターにより証明書申請ノードのアイデンティティ情報を検証し、その後各コンセンサス認証センターに対応する認証結果に基づいて証明書申請ノードのアイデンティティ認証結果を決定し、アイデンティティ認証結果が通過である場合に電子証明書を生成し、該電子証明書は、取引リソースとして各コンセンサス認証センターに対応するブロックチェーンに書き込まれ、アイデンティティ認証結果が複数の認証センターの認証結果に基づくものであるため、１つの認証センターのみによる検証に比べて、検証の正確さがより高い。また、電子証明書がある認証センターに記憶されず、ブロックチェーンに書き込まれるので、他の不正ノードがブロックチェーンにおいて電子証明書を修正する又は取り消すことが困難となり、電子証明書のセキュリティを確保し、ネットワークセキュリティを向上させることができる。

【図面の簡単な説明】

【0012】

【図1】本願の一実施例に係る応用環境の概略図である。

【図2】本願の一実施例に係る電子証明書の管理方法のフローチャートである。

【図3】本願の一実施例に係る電子証明書の概略図である。

【図4】本願の一実施例に係るターゲット電子証明書を取引リソースとしてコンセンサス認証センターに対応するブロックチェーンに書き込むフローチャートである。

【図5】本願の一実施例に係る電子証明書の管理方法のフローチャートである。

【図6】本願の一実施例に係る電子証明書の管理方法のフローチャートである。

【図7】本願の一実施例に係る取引チェーンの概略図である。

【図8】本願の一実施例に係る電子証明書の管理方法のフローチャートである。

【図9】本願の一実施例に係る電子証明書を管理する概略図である。

【図10】本願の一実施例に係る電子証明書の管理装置の構成ブロック図である。

【図11】本願の一実施例に係る書き込みモジュールの構成ブロック図である。

【図12】本願の一実施例に係る電子証明書の管理装置の構成ブロック図である。

【図13】本願の一実施例に係るコンピュータ装置の内部構成ブロック図である。

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

【0013】

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

【0014】

本願に使用される用語「第１」、「第２」などは、本明細書において様々な素子を説明するのに用いられることができるが、特に説明しない限り、これらの素子は、これらの用語に限定されないことが理解できる。これらの用語は、１番目の素子と他の素子とを区別するためのものである。例えば、本願の範囲を逸脱しない限り、第１のアカウントを第２のアカウントと呼んでもよく、同様に、第２のアカウントを第１のアカウントと呼んでもよい。

【0015】

以下、本願の実施例に係る用語について説明する。

【0016】

電子証明書は、ネットワーク通信において通信相手のアイデンティティ情報を識別するものであり、数字、アルファベット、記号の少なくとも１種を含む組み合わせであってもよい。電子証明書は、通常、権威あるＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ、証明書登録）機構によって発行される。一例として、ＣＡ機構は、ＣＦＣＡ（Ｃｈｉｎａ Ｆｉｎａｎｃｉａｌ Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ、中国金融認証センター）センターである。

【0017】

認証センターは、ネットワークにおいて認証サービスと、電子証明書を発行してノードのアイデンティティを確認するなどの仕事とを担当する、権限性及び公正性を有するコンピュータノードである。

【0018】

ブロックチェーンは、ある取引リソースを記憶する取引記録である。取引記録は、取引リソース、トランスファーフロムアカウント、トランスファーインアカウントという３つの要素を含む。本願の実施例では、上述の取引リソースは電子証明書である。また、アカウント（トランスファーフロムアカウント又はトランスファーインアカウント）は、アドレスとも呼ばれ、アドレスは、公開鍵により一方向の暗号化ハッシュアルゴリズムを経て取得することができる。ハッシュアルゴリズムは、任意の長さの入力を受信して指紋ダイジェストを生成する一方向性関数である。公開鍵によりアドレスを生成する際に用いられるアルゴリズムは、Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ（ＳＨＡ）アルゴリズム又はｔｈｅ ＲＡＣＥ Ｉｎｔｅｇｒｉｔｙ Ｐｒｉｍｉｔｉｖｅｓ Ｅｖａｌｕａｔｉｏｎ Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ（ＲＩＰＥＭＤ）アルゴリズムであり、例えばＳＨＡ２５６又はＲＩＰＥＭＤ１６０アルゴリズムであってもよい。

【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】

１つの具合的な例において、図９を参照すると、本願の一実施例に係る電子証明書の管理方法のフローチャートである。該方法は以下のステップ１～8を含んでもよい。

【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】

以上の実施例は、本願のいくつかの実施形態を説明したものに過ぎず、その説明が具体的で詳細であるが、本願の特許請求の範囲を限定するものだと理解してはいけない。なお、当業者にとって、本発明の思想から逸脱しない前提で、いくつかの変形及び改善を行うことができ、これらも本発明の保護範囲に含まれることを注意すべきである。したがって、本願の保護範囲は、特許請求の範囲を基準とすべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】