JP7273148B2 - デジタル証明書の発行方法、デジタル証明書発行センター、記憶媒体およびコンピュータプログラム - Google Patents

Description

［関連出願への相互参照］
本開示は、２０１９年０１月０９日に中国特許庁へ提出した出願番号が２０１９１００２０４３５．５であり、出願名称が「デジタル証明書の発行方法、デジタル証明書発行センターおよび媒体」である中国特許出願に基づいて優先権を要求し、その全ての内容は援用により本出願に組み込まれる。

［技術分野］
本開示は、ブロックチェーンの分野に関し、特に、ブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する技術に関する。

従来のブロックチェーンネットワークシステムでは、パブリック型ブロックチェーン、コンソーシアム型ブロックチェーンおよびプライベート型ブロックチェーンはいずれも技術の発展に伴って生成したものである。パブリック型ブロックチェーンは、高度な脱中心化を実現可能であるとともに信頼性および安全性が最も高いが、その取引速度が最も遅いものである。プライベート型ブロックチェーンは、実現可能な脱中心化の程度が低いが、その取引速度が速く、監督管理に最適するものである。また、コンソーシアム型ブロックチェーンは、部分的な脱中心化を実現可能であり、その脱中心化の程度がパブリック型ブロックチェーンとプライベート型ブロックチェーンとの間にあり、かつ、その取引速度が比較的に速く、監督管理の可能性も高いものである。この３種類のブロックチェーンは、その特徴が異なるので、適用可能な場面も異なる。

いずれのブロックチェーンネットワークシステムであっても、データブロックのブロックチェーンへの書込みおよびクエリーの過程では、例えば書き込み情報、クエリー要求などのようなデータをブロックチェーンネットワークシステムにおいて伝送する必要がある。安全性を向上させるために、通常、送信者がデータを伝送するときにデータに対してその鍵で署名し、受信者が署名とデータを受信したときに送信者の鍵で署名を検証する必要があるので、送信者の鍵の取得に関わっている。鍵の安全性や権威性を保障するために、発行した鍵が安全で権威的なものであることを証明するよう送信者に対してデジタル証明書を発行する必要がある。しかしながら、従来技術では、ノードに対するデジタル証明書の発行過程は孤立的であり、ノードが割り当てられた鍵を有するとともにデジタル証明書が発行されるが、従来のデジタル証明書の発行過程は、当該発行されたデジタル証明書が必ず当該鍵に対応していることを証明できないので、デジタル証明書の証明力が悪く、権威性も悪い。

本開示は、発行されたデジタル証明書の証明力を高めて、ブロックチェーンネットワークにおけるデータ交換の安全性を高めることができる、ブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行するための方法、デジタル証明書発行センターおよび媒体を提供することを目的とする。

本開示の実施例の一方面によれば、ブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法であって、前記方法がデジタル証明書発行センターにより実行され、前記デジタル証明書発行センターは公開／秘密鍵生成モジュールと認証モジュールとを含み、ブロックチェーンネットワークにおけるノードからの公開／秘密鍵要求に応じて、公開／秘密鍵生成モジュールによって、前記ノードに対して前記ノードの公開鍵および秘密鍵を生成して前記ノードに送信するステップと、認証モジュールによって、前記ノードの公開鍵および登録情報を受信するステップと、認証モジュールによって前記登録情報を認証するステップと、認証に成功すると、認証モジュールによって、平文情報と、認証モジュールの秘密鍵を用いて前記平文情報に対して形成した署名とを含む、前記ノードのデジタル証明書を生成して前記ノードに送信することによって、前記ノードが認証モジュールの公開鍵を用いて前記署名を検証するようにするステップであって、前記平文情報は前記ノードの公開鍵を含む、ステップと、を含むことを特徴とする方法が開示される。

本開示の実施例の一方面によれば、デジタル証明書発行センターであって、
ブロックチェーンネットワークにおけるノードからの公開／秘密鍵要求に応じて、前記ノードに対して前記ノードの公開鍵および秘密鍵を生成して、前記ノードに送信するための公開／秘密鍵生成モジュールと、認証モジュールであって、前記ノードの公開鍵および登録情報を受信して、前記登録情報を認証し、かつ、認証に成功すると、平文情報と、認証モジュールの秘密鍵を用いて前記平文情報に対して形成した署名とを含む、前記ノードのデジタル証明書を生成して前記ノードに送信することによって、前記ノードが認証モジュールの公開鍵を用いて前記署名を検証するようにするための、認証モジュールと、を含み、前記平文情報は、前記ノードの公開鍵を含むことを特徴とするデジタル証明書発行センターが開示される。

本開示の実施例の一方面によれば、コンピュータ読み取り可能な指令が記憶されるメモリと、メモリに記憶されるコンピュータ読み取り可能な指令を読み取って、上記の方法を実行するプロセッサと、を備えるデジタル証明書発行センターが開示される。

本開示の実施例の一方面によれば、コンピュータのプロセッサによって実行される場合、上記の方法をコンピュータに実行させるコンピュータ読み取り可能な指令を記憶するためのコンピュータプログラム媒体が開示される。

本開示の実施例の一方面によれば、コンピュータで動作することによって、上記の方法をコンピュータに実行させるための指令を含むコンピュータプログラムプロダクトが開示される。

従来技術では、デジタル証明書の発行は孤立的であるため、ノードの公開/秘密鍵の正当性に対する証明力が低い。本開示の実施例では、デジタル証明書発行センターは、公開／秘密鍵生成モジュールと認証モジュールとを含む。公開／秘密鍵生成モジュールによってノードに対して公開/秘密鍵を生成した後、ノードは、公開鍵と登録情報とを共に認証モジュールに送信して認証を行う。認証成功後に、ノードに返送されたデジタル証明書には、公開鍵が含まれる。これにより、発行された公開鍵に対するデジタル証明書の証明力が強くなる。そして、デジタル証明書には認証モジュールの秘密鍵による署名が含まれており、前記ノードに返送された後、前記ノードは、認証モジュールの公開鍵で当該署名に対して検証を行うことができる。このように、当該署名が検証可能なものであるので、当該デジタル証明書の証明力および信頼性が向上する。これにより、当該デジタル証明書で保証する公開／秘密鍵を用いてブロックチェーンネットワークにおいてデータを交換することにより、ブロックチェーンネットワークにおけるデータ交換の安全性が向上する。

本開示の他の特徴および利点は、以下の詳細な説明により明らかになり、または本開示の実践によって一部を習得することができる。

なお、以上の一般的な記載と以下の詳細な説明は、あくまでも例示に過ぎなく、本開示を限定するものではないと理解できろう。

以下、本開示の上記および他の目的、特徴および利点は、例示的な実施例を図面を参照しながら詳細に説明することによってより明らかとなろう。
本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法のシステムアーキテクチャを示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法のシステムアーキテクチャを示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法のシステムアーキテクチャを示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のアーキテクチャを示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法を示すフローチャートである。 本開示の一実施例に係るデジタル証明書発行センターにおける各モジュール同士および前記ノード同士のインタラクティブを示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法を示すフローチャートである。 本開示の一実施例に係るデジタル証明書発行センターにおける各モジュール同士および前記ノード同士のインタラクティブを示す図である。 本開示の一実施例に係るノードから送信された秘密鍵を受信する方法を示すフローチャートである。 本開示の一実施例に係るノードから送信された秘密鍵を受信する方法を示すフローチャートである。 本開示の一実施例に係るノードが秘密鍵管理モジュールに秘密鍵を寄託する際のインタラクティブのフローを示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法を示すフローチャートである。 本開示の一実施例に係る秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓがノードの秘密鍵をノードに送信する方法を示すフローチャートである。 本開示の一実施例に係るノードが秘密鍵管理モジュールから寄託された秘密鍵を取得する場合のインタラクティブのフローを示す図である。 本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法を示すフローチャートである。 本開示の一実施例に係るデジタル証明書発行センターの詳細を示すブロック図である。 本開示の一実施例に係るデジタル証明書発行センターが発行したデジタル証明書を示す図である。 本開示の一実施例に係るデジタル証明書発行センターが発行したデジタル証明書を示す図である。 本開示の一実施例に係るデジタル証明書発行センターのハードウェア構成を示す図である。

以下、本開示の実施例について図面を参照しながらより全面的に説明する。しかしながら、実施例は、ここで述べる例に限られたものではなく、多様な形態で実施可能であると理解するべきである。一方、これらの実施例を提供することにより、本開示の説明がより全面的かつ完全となり、かつ実施例の構想を全面的に当業者に伝送することができる。図面は、本開示を例示的に示すものに過ぎなく、必ずしも比例的に描かれていない。図中における同一の符号は、同一または類似する部分を示すため、重複する説明を省略する。

また、ここで説明した特徴、構造または特性は、１つ以上の実施例に任意の好適な形態で組み込まれ得る。以下の説明では、本開示の実施例を十分に理解できるように具体的な詳細を多く提供する。しかし、当業者であれば、本開示の技術方案を実現するために、特定の細部のうちの１つ以上を省略したり、他の方法、ユニット、ステップなどを採用したりすることができることを理解できろう。その他の場合に、本開示の各方面を不明瞭にさせないように、公知の構造、方法、実現または動作を詳細に例示または説明しない。

図面に示すいくつかのブロック図は、機能的エンティティであり、必ずしも物理的または論理的に独立したエンティティに対応する必要はない。これらの機能的エンティティは、ソフトウェアによって実現されてもよいし、１つまたは複数のハードウェアモジュールや集積回路において実現されてもよいし、異なるネットワークおよび／またはプロセッサ装置および／又はマイクロコントローラ装置において実現されてもよい。

本開示の実施例が提供する方法は、分散型データ記憶、Ｐ２Ｐ伝送、コンセンサス機制、暗号アルゴリズムなどのコンピュータ技術の新規の応用モードであるブロックチェーンに適用される。ブロックチェーン（Ｂｌｏｃｋ ｃｈａｉｎ）は、本質的に脱中心化されたデータベースであって、暗号学の方法で関連付けられて発生した一連のデータブロックであり、各データブロックのそれぞれに１ロットのネットワーク取引の情報が含まれ、その情報の有効性（偽造防止）の検証および次のブロックの生成に利用されるものである。ブロックチェーンは、ブロックチェーン下層プラットフォーム、プラットフォームプロダクトサービス層およびアプリケーションサービス層を含み得る。

ブロックチェーン下層プラットフォームは、ユーザ管理、基礎サービス、スマートコントラクトおよび運営監視等の処理モジュールを含み得る。ここで、ユーザ管理モジュールは、公開／秘密鍵の生成の保守（アカウント管理）、鍵管理およびユーザの真実な身分とブロックチェーンアドレスとの対応関係の保守（権限管理）等を含めてブロックチェーンの全ての参与者の身分情報管理を担当し、かつ、権限が授与される場合に、ある真実な身分の取引状況を監視および監査し、リスク制御のルールの設定（リスク制御監査）を提供する。基礎サービスモジュールは、ブロックチェーンにおける全てのノード装置に配置され、トラフィック要求の有効性を検証するとともに有効な要求に対して合意形成した後に記憶媒体に記録し、１つの新たなトラフィック要求に対して、先ずはインターフェース適応性に対する解析および認証処理（インターフェースアダプテーション）を施し、その後、合意アルゴリズムによってトラフィック情報を暗号化し（合意管理）、暗号化後に共有帳簿に完全に伝送して（ネットワーク通信）記録格納するものである。スマートコントラクトモジュールは、コントラクトの登録や発行およびコントラクトの触発と実行を担当し、開発者は、あるプログラミング言語によってコントラクト論理を定義してブロックチェーンに配信し（コントラクト登録）、コントラクト条款の論理に応じて、鍵またはその他のイベントトリガを呼び出して実行して、コントラクト論理を完了するとともに、コントラクトに対するアップグレードおよび取消の機能を提供する。
運営監視モジュールは、主に、例えばアラーム、ネットワーク状況の監視、ノード装置の健康状態の監視等のような、プロダクトの発表過程における部署、配置の修正、コントラクトの設定、クラウド対応およびプロダクトの動作中のリアルタイム状態の可視化出力等を担当する。

プラットフォームプロダクトサービス層は、代表的なアプリケーションの基本機能および実現フレームを提供するものであり、開発者は、これらの基本機能に基づいて、トラフィックの特性を重ね合わせることによって、トラフィック論理のブロックチェーンを実現することができる。アプリケーションサービス層は、ブロックチェーンに基づいたアプリケーションサービスをトラフィックの参与者に提供して使用するものである。

以下、本開示の実施例に適用されるシステムアーキテクチャおよび全体フローについて図１Ａ－１Ｃを参照しながら説明する。

図１Ａに、本開示の実施例に適用されるブロックチェーンネットワークのシステムアーキテクチャを示す。このシステムアーキテクチャは、複数の記帳ノード１０１を含む記帳ノードサブネットワーク１００と、取引情報生成者ノード１０２と、デジタル証明書発行センター１０３とを含む。取引情報生成者ノード１０２と記帳ノード１０１は、ブロックチェーンのシステムアーキテクチャにおける権限が異なり、記帳ノード１０１は、記帳権利（データブロックを生成してブロックチェーンへ書き込む権利）を有するのに対して、取引情報生成者ノード１０２は、記帳権利を有せず、取引情報を生成して記帳を請求する権利のみを有し、そして、記帳ノード１０１による記帳が正確であるかをチェックできず、記帳ノード１０１による記帳を受動的に信頼することしかできない。各取引情報生成者ノード１０２のそれぞれは、対応する記帳ノード１０１を有する。取引情報生成者ノード１０２は、取引情報を生成すると、取引情報をその対応な記帳ノード１０１に送信して記帳を請求することにより、ブロックチェーンへの書き込みを完了することができる。

記帳ノードサブネットワーク１００に含まれる記帳ノード１０１同士、および記帳ノード１０１と取引情報生成者ノード１０２との間は、上記のデータブロックのブロックチェーンへの書き込み過程において各種の情報を交換する必要がある。送信者は、交換する情報の安全性を保障するために、その秘密鍵を用いて情報に対して署名して情報とともに送信する必要がある。署名および情報を受信したノードは、この署名を当該送信者の公開鍵で検証することができる。公開／秘密鍵の存在により、デジタル証明書発行センター１０３の作用が表現され、デジタル証明書発行センター１０３は、公開／秘密鍵の正当性を確認することができる。

図１Ｂに、本開示の実施例に適用される別種のブロックチェーンネットワークのシステムアーキテクチャを示す。当該システムアーキテクチャは、記帳ノードサブネットワーク１００と、トラフィックノードサブネットワーク１０４と、デジタル証明書発行センター１０３とを含む。当該システムアーキテクチャは、トラフィックノード１０２から構成されるトラフィックノードサブネットワーク１０４を含むという点で図１Ａのシステムアーキテクチャと異なる。トラフィックノード１０２は、記帳が不可能であるが、記帳ノード１０１による記帳を検証可能であるという点で図１Ａにおける取引情報生成者ノード１０２と異なる。記帳ノードサブネットワーク１００とトラフィックノードサブネットワーク１０４とは、エージェントノード１０５を介して接続されている。エージェントノード１０５は、トラフィックノードサブネットワーク１０４に属する１つの特別なノードである。エージェントノード１０５によるデータの伝送方式は、双方向であり、記帳ノード１０１からトラフィックノード１０２へ伝送しようとする情報のトラフィックノード１０２への伝送だけではなく、トラフィックノード１０２が発生した取引情報を記帳ノード１０１へ送信してブロックチェーンへの書き込みを完了することもできる。トラフィックノード１０２は、ブロックチェーンへの書き込みを必要とする各種の取引情報を生成して、エージェントノード１０５を介して１つの記帳ノード１０１に伝送する。記帳ノード１０１は、全ての記帳ノード１０１から選択したリーダー記帳ノードによって、受信した複数の取引情報をパケット化してブロックチェーンへ書き込む。リーダー記帳ノードは、パケット化された複数の取引情報に対してサマリを生成して、リーダー記帳ノードの秘密鍵を用いて署名を生成し、サマリと署名とをブロックヘッダに加えてトラフィックノード１０２へ返送させる。トラフィックノード１０２は、この署名をリーダー記帳ノードの公開鍵で検証することができる。ここで、リーダー記帳ノードの公開鍵および秘密鍵に関わっているので、リーダー記帳ノードの公開鍵の正当性を保証するために、デジタル証明書発行センター１０３が発行したデジタル証明書が必要となる。

トラフィックノード１０２は、記帳ノード１０１から送信されたブロックヘッダのみを受信するが、ブロックにおける具体的な取引情報をクエリーしようとする場合、エージェントノード１０５へ取引情報のクエリー要求を送信する必要がある。クエリー要求が正当的なトラフィックノード１０２から送信されたものであることを検証するために、トラフィックノード１０２は、その秘密鍵でクエリー要求に対して署名を行う必要があり、エージェントノード１０５は、クエリー要求に対して当該トラフィックノード１０２の公開鍵で署名検証を行うことによって、クエリー要求がトラフィックノード１０２から送信されたものであるとともに伝送途中に損失が発生しなかったことを証明する。ここで、トラフィックノードの公開鍵および秘密鍵に関わっているので、トラフィックノードの公開鍵および秘密鍵の正当性を保証するために、デジタル証明書発行センター１０３が発行したデジタル証明書が必要となる。

図１Ｃに、本開示の実施例に適用される別種のブロックチェーンネットワークのシステムアーキテクチャを示す。当該システムアーキテクチャは、その記帳ノードサブネットワーク１００が複数の分岐記帳ノードサブネットワークに分けられている点で図１Ｂにおけるシステムアーキテクチャと異なる。各分岐記帳ノードサブネットワークのそれぞれは、ある種類の取引情報の記録を担当することができる。例えば、分岐記帳ノードサブネットワークＡにおける記帳ノードは、ブロックチェーンにおける金融取引情報の記録を担当し、分岐記帳ノードサブネットワークＢにおける記帳ノードは、電子伝票の取引情報の記録を担当する。図１Ｃにおいても、リーダー記帳ノードの公開鍵および秘密鍵またはトラフィックノード１０２の公開鍵および秘密鍵を用いて署名および署名検証を行う必要があり、その過程が図１Ｂと類似する。

図２は、本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の場面に適用される場合のアーキテクチャを示す図である。

従来の方式では、いずれも中心化したデータベースによって電子伝票の発行などのトラフィックフローを完了させているが、ブロックチェーン技術の出現につれて、伝票のブロックチェーンへの書き込みでは、既に一定の応用上の成果を取得していた。このような電子伝票におけるブロックチェーンの適用場面では、従来の中心化した電子伝票のトラフィックフローにおける、例えば地方税務局から伝票発行企業への伝票の配布、伝票発行企業から伝票受領者への伝票の発行、および伝票受領者からその清算先への伝票の清算などの取引行為はいずれもブロックチェーンに書込み、すなわちブロックチェーンに記録する必要がある。

地方税務局から伝票発行企業への伝票の配布、伝票発行企業から伝票受領者への伝票の発行などのイベントでは、地方税務局端末や伝票発行先などのトラフィックノード１０２は、伝票の配布、発行などの取引情報を記帳ノードサブネットワーク１００に送信してブロックチェーンに書き込ませる。リーダー記帳ノードがブロックチェーンへの書き込みを完了した後、図１Ｂを参照して述べたように、リーダー記帳ノードからトラフィックノード１０２へのブロックヘッダの送信過程、およびトラフィックノード１０２によるブロックにおける取引情報のクエリー過程では、それぞれリーダー記帳ノードの秘密鍵を用いてブロックに対して署名し、およびトラフィックノード１０２の秘密鍵を用いてクエリー要求に対して署名する必要がある。トラフィックノード１０２およびエージェントノード１０５に、それぞれリーダー記帳ノードの公開鍵とトラフィックノード１０２の公開鍵を用いて署名を検証する場合、それぞれリーダー記帳ノードの公開鍵とトラフィックノード１０２の公開鍵を使用する。従って、これらの公開／秘密鍵の正当性を保証するためにデジタル証明書を発行する必要があるので、本開示の実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が生じた。

図３Ａ－３Ｋは、本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合の伝票発行端末ノードの表示画面を示す図であり、これらの画面図には、電子伝票の応用場面では図１Ａに示したシステムアーキテクチャにおける記帳ノードサブネットワーク１００以外の取引情報生成者ノード１０２によるデジタル証明書の申請と取引情報のブロックチェーンへの書き込みについての概略過程を示している。

図３Ａに示すように、伝票発行先端末は、取引情報を記帳ノード１０１に伝送して記帳する過程で取引情報に対して署名する必要があるため、伝票発行の行為に先立って、公開鍵および秘密鍵を有しなければならない。従って、図３Ａの画面では、「公開鍵および秘密鍵の発行を要求する」のような提示が表示され、「確定」をクリックすると、伝票発行先端末は、デジタル証明書発行センター１０３に公開鍵および秘密鍵の発行を要求する。

図３Ｂに示すように、デジタル証明書発行センター１０３は、伝票発行先端末の要求に応じて、一対の公開／秘密鍵ペアを生成して、伝票発行先端末へ公開／秘密鍵ペアを返送する。伝票発行先端末は、秘密鍵を自ら保存してもよいし、端末に故障が発生した場合に自己の端末に保存された秘密鍵が紛失するのを防止するように、秘密鍵をデジタル証明書発行センターに寄託してもよい。

そのため、図３Ｂの画面に示すように、公開／秘密鍵ペアを返送するときに、「秘密鍵を寄託するか」のような提示を表示することができ、寄託を選択すると、管理者は、図３Ｂに示す「はい」をクリックして、秘密鍵をデジタル証明書発行センター１０３に寄託させることができる。そして、図３Ｃに示すように、「秘密鍵の寄託に成功」のような提示を表示する。

この公開鍵および秘密鍵が正当的な機構から発行された統一的な公開鍵および秘密鍵であることを証明するために、デジタル証明書を申請して当該公開鍵および秘密鍵の正当性を証明する必要がある。従って、図３Ｄに示すように、伝票発行先端末に、会社名、納税者識別番号などの登録情報を記入する。管理者が「確定」をクリックすると、発行された公開鍵および登録情報をデジタル証明書発行センター１０３に送信する。

デジタル証明書発行センター１０３は、登録情報を受信すると、登録情報を認証し、認証に成功すると、デジタル証明書を発票発行先端末に発行する。デジタル証明書には、図３Ｅに示すバージョン番号、署名アルゴリズム、認証モジュールの公開鍵、伝票発行先の公開鍵などの平文情報と、認証モジュールの秘密鍵を用いて平文情報に対して行った署名が含まれている。このデジタル証明書に伝票発行先の公開鍵が含まれているため、公開鍵および秘密鍵とバインディング関係が形成され、当該発行された公開鍵および秘密鍵が正当的なものであることを証明できる。

伝票発行先端末がデジタル証明書を受信すると、管理者は、「検証」をクリックすることによって、認証モジュールの公開鍵を用いてデジタル証明書における署名を検証することができる。検証に成功すると、このデジタル証明書が正当的な機構により発行されたものであることを証明することができ、図３Ｆに示すデジタル証明書の検証に成功したような提示が表示される。

伝票発行先端末が伝票を発行した場合、伝票発行情報をブロックチェーンに書き込む必要がある。この場合、図３Ｇに示す画面に伝票発行先、伝票識別子などの取引情報を記入する。管理者は、「記帳ノードへ送信」をクリックすると、これらの取引情報を対応する記帳ノード１０１に送信するように指示する。

取引情報送信者の正当性および取引情報の伝送の完全性を保障するために、取引情報に対して署名する必要がある。署名には、伝票発行先端末の秘密鍵を用いる必要がある。この秘密鍵は、図３Ｂに示す画面において寄託が選択されるため、この場合、寄託された秘密鍵をデジタル証明書発行センター１０３から取得する必要がある。管理者は、図３Ｈに示す画面において「はい」を選択する。

寄託された秘密鍵をデジタル証明書発行センター１０３から取得すると、図３Ｉに示す提示画面が表示される。管理者が当該画面において「署名して送信」をクリックすると、伝票発行先端末の秘密鍵で取引情報に対して署名して、記帳ノード１０１に送信する。

記帳ノード１０１は、伝票発行先端末の署名を受信すると、伝票発行先端末の公開鍵でこの署名を検証する。検証に成功すると、検証に成功した旨を伝票発行先端末に通知する。伝票発行先端末には、図３Ｊに示す画面が表示される。

記帳ノード１０１は、取引情報をブロックチェーンに書き込む。ブロックチェーンへの書き込みが完了すると、ブロックチェーンへの書き込みが完了した旨を伝票発行先端末に通知する。伝票発行先端末には、図３Ｋに示す画面が表示される。

図４Ａ－４Ｋは、本開示の一実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が電子伝票の応用場面に適用される場合のノードの表示画面を示す図であり、これらの画面図には、図１Ｂに示したシステムアーキテクチャにおいてトラフィックノードサブネットワーク１０４におけるトラフィックノード１０２が記帳ノードサブネットワーク１００における記帳ノード１０１からブロックチェーンに書き込まれたデータブロックのブロックをクエリーする概略過程を示している。

図４Ａ～４Ｆは、トラフィックノード１０２がブロック内の取引情報をクエリーする前に公開鍵、秘密鍵およびその対応のデジタル証明書の取得を完了する過程であり、図３Ａ～３Ｆと類似するので説明を省略する。

取引情報がブロックチェーンに書き込まれた後、トラフィックノード１０２は、記帳ノード１０１から送信されたブロックヘッダのみを受信する。トラフィックノード１０２がブロック内の取引情報をクエリーする必要がある場合、図４Ｇに示す画面を表示する。管理者は、「確定」をクリックすると、エージェントノード１０５へクエリー要求を送信するように指示する。

クエリー要求が正当的なトラフィックノード１０２から発信されたものであることを証明するために、同時にトラフィックノード１０２による署名を送信する必要がある。図４Ｈに示すように、表示される画面には、クエリー要求に対して署名する必要があることを提示し、かつ、署名用の秘密鍵を取得するか否かを聞き合わせる。

管理者が図４Ｈに示す画面における「はい」をクリックすると、デジタル証明書発行センター１０３からトラフィックノード１０２の秘密鍵を取得する。図４Ｉに示すように、管理者が「署名して送信」をクリックすると、トラフィックノード１０２の秘密鍵でクエリー要求に対して署名して、クエリー要求とともにエージェントノード１０５に送信する。

エージェントノード１０５は、クエリー要求および署名を受信すると、トラフィックノード１０２の公開鍵で署名を検証し、検証に成功すると、その旨をトラフィックノード１０２に通知する。トラフィックノード１０２は、図４Ｊに示す画面を表示する。

署名の検証に成功すると、エージェントノード１０５は、ブロックヘッダの取引情報のクエリー要求を対応する記帳ノード１０１に送信するとともに、トラフィックノード１０２の権限に応じて、そのクエリーを要求している取引情報を返送するか否かを決定する。図４Ｋに、トラフィックノード１０２において返送された取引情報を閲覧する画面を示している。

図５に示すように、本開示の一実施例によれば、ブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法が提供される。

ブロックチェーンネットワークは、図１Ａー１Ｃに示すようなブロックチェーンへのデータブロックの記録に係るシステムアーキテクチャ全体を意味する。デジタル証明書は、ノードに割り当てられる公開鍵および秘密鍵が正当的な機構により割り当てられたものであることを保証するために設けられた証明書類である。ブロックチェーンネットワークにおけるノードは、ブロックチェーンネットワークにおけるデジタル証明書発行センター１０３以外の全てのノードを意味する。図１Ａでは、取引情報生成者ノード１０２と記帳ノード１０１とを含む。図１Ｂ－１Ｃでは、トラフィックノード１０２、エージェントノード１０５および記帳ノード１０１を含む。

前記方法は、デジタル証明書発行センター１０３によって実行される。デジタル証明書発行センターは、暗号アルゴリズムに基づいて、ブロックチェーンのノードの通信に対してセキュリティサービスを提供する中心化したインフラであり、公開鍵および秘密鍵の正当性を確認できるようにノードに対してデジタル証明書を発行することができる。図６に示すように、前記デジタル証明書発行センター１０３は、少なくとも公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋと認証モジュールＴＰＫＩ＿ｃａとを含む。公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋは、ノードに対して公開鍵および秘密鍵を生成するためのものである。認証モジュールＴＰＫＩ＿ｃａは、ノードを認証することにより、当該ノードの正当性を検証し、さらに、正当的なノードとノードに対して生成した公開鍵および秘密鍵との間に認証された対合を形成するためのものである。

デジタル証明書発行センター１０３は、ノードの登録情報を認証する際に用いられるポリシーを記憶するための認証ポリシーモジュールＴＰＫＩ＿ａｕｓをさらに含んでもよい。

公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋ、認証モジュールＴＰＫＩ＿ｃａおよび認証ポリシーモジュールＴＰＫＩ＿ａｕｓは、例えば異なるエンティティに分布される物理的なものであってもよいし、例えば１つのエンティティに分布する異なる仮想モジュールのような仮想的なものであってもよい。

図５に示すように、前記方法は、
ブロックチェーンネットワークにおけるノードからの公開／秘密鍵要求に応じて、公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋによって、前記ノードに対して前記ノードの公開鍵および秘密鍵を生成して前記ノードに送信するステップ５１０と、
認証モジュールＴＰＫＩ＿ｃａによって、前記ノードの公開鍵および登録情報を受信するステップ５３０と、
認証モジュールＴＰＫＩ＿ｃａによって前記登録情報を認証するステップ５５０と、
認証に成功すると、認証モジュールＴＰＫＩ＿ｃａによって、平文情報と、認証モジュールＴＰＫＩ＿ｃａの秘密鍵を用いて前記平文情報に対して形成した署名とを含む、前記ノードのデジタル証明書を生成して前記ノードに送信することによって、前記ノードが認証モジュールＴＰＫＩ＿ｃａの公開鍵を用いて前記署名を検証するようにするステップ５６０と、を含む。ここで、前記平文情報は前記ノードの公開鍵を含む。

ここで、公開鍵（Ｐｕｂｌｉｃ Ｋｅｙ）および秘密鍵（Ｐｒｉｖａｔｅ Ｋｅｙ）は、１種のアルゴリズムによって得られた１つの鍵ペア（すなわち、１つの公開鍵と１つの秘密鍵）であり、公開鍵は鍵ペアにおける公開部分であり、秘密鍵は非公開部分である。公開鍵で暗号化されたデータは、対応する秘密鍵でしか復号することができなく、秘密鍵で暗号化されたデータは、対応する公開鍵でしか復号することができない。

ノードの公開鍵は、デジタル証明書発行センター１０３の公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋによって生成され、かつ、ノード間で伝送されるデータを暗号化または復号するとともに、デジタル証明書がノードに対して生成された公開鍵および秘密鍵が正当的なものであることを証明できるように、デジタル証明書発行センター１０３がノードに対してデジタル証明書を発行する際にデジタル証明書とノードの公開鍵とを関連付けるためのものである。ノードがデジタル証明書発行センター１０３からデジタル証明書を取得したときに、認証モジュールＴＰＫＩ＿ｃａの公開鍵を用いて、認証モジュールＴＰＫＩ＿ｃａがその自身の秘密鍵を用いてデジタル証明書およびノードの公開鍵に対して形成した署名を検証して、デジタル証明書の信頼性を向上できるように、ノードには認証モジュールＴＰＫＩ＿ｃａの公開鍵が記憶されてもよい。

なお、デジタル証明書発行センター１０３が認証ポリシーモジュールＴＰＫＩ＿ａｕｓをさらに含む場合、ステップ５５０の前に、認証モジュールＴＰＫＩ＿ｃａによって、認証ポリシーモジュールＴＰＫＩ＿ａｕｓから前記ノードに対応する登録情報認証ポリシーを取得するステップ５４０（図５において点線でこのステップがオプションであることを示す）をさらに含んでもよい。これにより、ステップ５５０において登録情報を認証するときに、前記認証モジュール（ＴＰＫＩ＿ｃａ）によって、前記ノードに対応する登録情報認証ポリシーに基づいて前記登録情報を認証することができ、認証が統一的な基準を有するようにすることができる。

以下、図５に示す技術方案について、図６に示すデジタル証明書発行センターにおける各モジュール同士、および前記ノードとの間のインタラクティブ模式図を参照しながら説明する。６－１において、公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋは、ノードＢｅｒｓに対して公開／秘密鍵ペアを生成して当該ノードに送信する。６－４において、ノードＢｅｒｓは、登録情報および公開鍵を認証モジュールＴＰＫＩ＿ｃａに送信する。６－５において、認証モジュールＴＰＫＩ＿ｃａは、登録情報認証ポリシー取得要求を認証ポリシーモジュールＴＰＫＩ＿ａｕｓに送信する。その後、認証ポリシーモジュールＴＰＫＩ＿ａｕｓは、前記ノードに対応する登録情報認証ポリシーを取得して、ステップ６－６において認証ポリシーを認証モジュールＴＰＫＩ＿ｃａへ返送する。認証に成功すると、認証モジュールＴＰＫＩ＿ｃａは、ステップ６－７においてデジタル証明書をノードＢｅｒｓに送信する。一方、認証に失敗すると、認証モジュールＴＰＫＩ＿ｃａは、ステップ６－７において認証に失敗した旨のアラート情報をノードＢｅｒｓに送信する。

以下、ステップ５１０－５６０について詳述する。

ステップ５１０において、ブロックチェーンネットワークにおけるノードからの公開／秘密鍵要求に応じて、公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋによって、前記ノードに対して前記ノードの公開鍵および秘密鍵を生成して前記ノードに送信する。

公開／秘密鍵要求は、ブロックチェーンネットワークにおけるノードがデジタル証明書発行センターからデジタル証明書を取得するための要求である。公開／秘密鍵要求は、例えばＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）／ＨＴＴＰＳプロトコルに基づいた要求などのような各種のネットワークプロトコルに基づいたネットワーク要求や、例えばｇｅｔ、ｐｏｓｔなどの方法で生成された要求であってよい。

１つの実施例では、公開／秘密鍵ペアの生成方式について、従来のＯｐｅｎＳＳＬといったセキュア・ソケット・レイヤー暗号ライブラリのコマンド行ツールによって生成されることができる。

非対称暗号アルゴリズムが異なるため、公開／秘密鍵ペアを生成する方法が異なる。そこで、１つの実施例では、公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋに非対称暗号アルゴリズムライブラリが設置され、公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋは、この非対称暗号アルゴリズムライブラリから１種の非対称暗号アルゴリズムをランダムに選択して、前記ノードに対して前記ノードの公開鍵および秘密鍵を生成する。

１つの実施例では、ブロックチェーンネットワークにおけるノードがデジタル証明書発行センターに送信した公開／秘密鍵要求には、非対称暗号アルゴリズムの名称が含まれ、公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋは、この名称の非対称暗号アルゴリズムに基づいて前記ノードに対して前記ノードの公開鍵および秘密鍵を生成する。この実施例は、ノードが公開鍵と秘密鍵を選択する自由度を高めることによって、ノードは、そのプリファレンスに応じて特別に愛好する暗号アルゴリズムに基づいた公開鍵および秘密鍵を選択することができる。

ある実施例では、ブロックチェーンネットワークにおけるノードがデジタル証明書発行センターに送信した公開／秘密鍵要求には、当該ノードの種別が含まれ、公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋには、ノードの種別と非対称暗号アルゴリズムの名称との対応関係テーブルが予め設けられており、公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋは、公開／秘密鍵要求におけるノードの種別に従って対応関係テーブルをサーチして、対応する非対称暗号アルゴリズムの名称を得、当該名称の非対称暗号アルゴリズムに従って前記ノードに対して前記ノードの公開鍵および秘密鍵を生成する。この実施例は、１種のノードに適する非対称暗号アルゴリズムが一定であるという利点がある。ノードの種別に応じて、それに適する非対称暗号アルゴリズムを選択して公開鍵および秘密鍵を生成することにより、生成した公開鍵および秘密鍵の品質を向上させることができる。

ある実施例では、公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋに非対称暗号アルゴリズムライブラリが設定され、非対称暗号アルゴリズムライブラリにおける非対称暗号アルゴリズムが所定の順序を有し、公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋは、この非対称暗号アルゴリズムライブラリから、前回で選択した非対称暗号アルゴリズムの次の非対称暗号アルゴリズムを所定の順序で選択して、前記ノードに対して前記ノードの公開鍵および秘密鍵を生成する。前回で選択した非対称暗号アルゴリズムは、所定の順序における最後の１つの非対称暗号アルゴリズムである場合、１番目の非対称暗号アルゴリズムを選択して、前記ノードに対して前記ノードの公開鍵および秘密鍵を生成する。この実施例は、毎回に選択した非対称暗号アルゴリズムが異なるため、公開鍵および秘密鍵が伝送過程で第三者によりクラックされる困難度が高まり、発行した公開鍵および秘密鍵の伝送安全性が向上したという利点がある。

ある実施例では、前記方法は、公開／秘密鍵生成モジュールＴＰＫ１＿ｓｄｋによって前記ノードに対して前記ノードの公開鍵および秘密鍵を生成して前記ノードに送信した後に、前記ノードの公開鍵および秘密鍵とノード識別子とを対応付けてバックアップするステップをさらに含む。このようにすれば、ノードは、自らの秘密鍵を大切に保存していなく、同時に秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓへの寄託もされていない場合、公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋによって自分に発行された秘密鍵を見つけることができるという利点がある。

ステップ５３０において、認証モジュールＴＰＫＩ＿ｃａによって、前記ノードの公開鍵および登録情報を受信する。

上記のように、前記ノードの公開鍵は、既に公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋによって生成されて前記ノードに送信される。

登録情報は、例えば会社名、納税者識別番号などのような、ノードがデジタル証明書発行センター１０３で登録する際に記入する必要がある情報であってもよい。デジタル証明書発行センター１０３で登録する意義としては、デジタル証明書を取得して、それに割り当てられた公開鍵および秘密鍵が正当的な機構から発行されたものであることを証明するためのことである。登録情報の認証に成功しなければ、ノードに対してデジタル証明書を発行することができない。

ある実施例では、前記ノードの公開鍵および登録情報は、認証モジュールＴＰＫＩ＿ｃａの公開鍵で暗号化される。このようにすれば、認証モジュールＴＰＫＩ＿ｃａのみがその秘密鍵を有するので、認証モジュールＴＰＫＩ＿ｃａでしか複号できないという利点がある。従って、伝送過程で第三者によって傍受されても、第三者が認証モジュールＴＰＫＩ＿ｃａの秘密鍵を有しないので、復号が不能であり、ノードの登録情報の伝送安全性が保証される。

ステップ５４０において、認証モジュール（ＴＰＫＩ＿ｃａ）によって、前記ノードに対応する登録情報認証ポリシーを認証ポリシーモジュール（ＴＰＫＩ＿ａｕｓ）から取得する。

登録情報認証ポリシーは、デジタル証明書が満足可能なセキュリティ要求の表現が準拠するポリシーであり、１または複数のセキュリティルールのポリシーであってもよい。例えば、どんな登録情報を検証するか、どのような基準に従って検証するかなどであってもよい。例えば、登録情報認証ポリシーは、会社の住所が深セン市にあるとともに会社の人数が５００人よりも多いとのことである。すなわち、当該ブロックチェーンネットワークは、深セン市にある大中型の会社にサービスを提供する１つのブロックチェーンネットワークである可能性がある。深セン市に位置しない会社、または深セン市にあるが人数が少ない小型の会社であると、ネットワークの保守コストという問題を考慮して、その認証が失敗し、デジタル証明書が発行されなく、その公開鍵および秘密鍵に対して正当性証明書を提供しない。

なお、前記ノードに対応する登録情報認証ポリシーは、当該登録情報認証ポリシーが前記ノードと一意に対応することを意味しない。すなわち、当該登録情報認証ポリシーは、前記ノードに適用されてもよいし、前記ノード以外の他のノードに適用されてもよい。登録情報認証ポリシーは、全てのノードが共通するユニークな登録情報認証ポリシーであってもよいし、ノード毎に異なる登録情報認証ポリシーであってもよい。

ある実施例では、前記ノードに対応する登録情報認証ポリシーは、前記ノードの種別に特定される登録情報認証ポリシーを含む。前記登録情報には、前記ノードの種別が含まれる。前記ステップ５４０は、認証ポリシーモジュール（ＴＰＫＩ＿ａｕｓ）から前記ノードの種別に特定される登録情報認証ポリシーを取得することを含む。

つまり、登録情報に含まれるノードの種別（例えば、金融業界の企業の端末、法律業界の企業の端末）に応じて、前記ノードの種別に特定される登録情報認証ポリシーを確定する。登録情報認証ポリシーはノードの種別によって異なる可能性がある。例えば、金融業界の企業は、その利益率が比較的に大きい可能性があり、登記資本金が２００万以上であるように要求される。法律業界の企業は、その利益率が比較的に小さい可能性があり、登記資本金が１０万以上であるように要求される。

この実施例は、ある種別のノードは類似する特徴を有するので、デジタル証明書を発行できるか否かを考慮する際に、通常は類似する基準に準拠するという利点がある。このようにすると、認証の正確性がより向上される。

ある実施例では、前記ノードの登録情報には、申請するデジタル証明書のセキュリティレベルを示す規格が含まれる。認証ポリシーモジュールＴＰＫＩ＿ａｕｓは、デジタル証明書の規格と登録情報認証ポリシーとの対応関係テーブルを含むので、前記ノードに対応する登録情報認証ポリシーは、前記登録情報におけるデジタル証明書の規格に従って、デジタル証明書の規格と認証ポリシーとの対応関係テーブルからサーチされるものである。

規格は、デジタル証明書のセキュリティレベルを表し、例えば、規格が３レベルであることはセキュリティレベルが最高であること、規格が２レベルであることはセキュリティレベルが中程度であること、規格が１レベルであることはセキュリティレベルが最低であることをそれぞれ示す。セキュリティレベルが高いほど、認証の厳しさが高くなり、対応する認証ポリシーも多くなったり、過酷になる可能性がある。この実施例は、異なるセキュリティレベルのデジタル証明書に対して異なる認証ポリシーが設定され、異なるセキュリティレベルのデジタル証明書が公開鍵および秘密鍵の正当性に対する証明力が異なるという利点がある。このようにすると、デジタル証明書の発行の自由度を高めることができる。

ある実施例では、前記登録情報認証ポリシーは、ブロックチェーンに記憶されている、前記ノードとブロックチェーンネットワークの運営者とが締結したスマートコントラクトから取得される。前記ノードは、ブロックチェーンネットワークを使用する前に、事前に認証時の登録情報認証ポリシーを有するスマートコントラクトをブロックチェーンネットワークの運営者と締結する必要がある。このスマートコントラクトは、前記ノードの識別子と対応付けてブロックチェーンに記憶されてもよい。このように、ブロックチェーンに書き込まれた全てのデータブロックのブロックから前記ノードの識別子をサーチし、当該ノードの識別子と対応付けて記憶されているスマートコントラクトをサーチして、前記スマートコントラクトから登録情報認証ポリシーをサーチすることができる。この実施例は、認証ポリシーを別途設定する必要がなく、スマートコントラクトにおける認証ポリシーを直接利用することができ、デジタル証明書の発行効率を向上させることができるという利点がある。

ある実施例では、認証ポリシーモジュールＴＰＫＩ＿ａｕｓは、発行要求時間帯と認証ポリシーとの対応関係テーブルを含む。ステップ５４０は、公開鍵および登録情報を受信した時点が所在する発行要求時間帯を確定するステップと、前記発行要求時間帯を認証ポリシーモジュールＴＰＫＩ＿ａｕｓに送信し、認証ポリシーモジュールＴＰＫＩ＿ａｕｓが発行要求時間帯と認証ポリシーとの対応関係テーブルをサーチして、当該発行要求時間帯と対応する認証ポリシーを取得して返信するステップとを含む。

例えば、毎日の出勤時間９：００～１７：００、および退勤時間０：００－９：００または１７：００－２４：００の登録情報認証ポリシーは異なる。公開鍵および登録情報を受信した時点を、デジタル証明書の発行を要求する時点として決定することができ、当該発行を要求する時点が９：００－１７：００にあるか、それとも０：００－９：００または１７：００－２４：００にあるかによって認証ポリシーが異なる。要求発行時間帯と認証ポリシーとの対応関係テーブルから、当該要求発行時間帯と対応する認証ポリシーを、取得した登録情報認証ポリシーとして見つけることができる。

この実施例は、幾らかの場面において認証ポリシーが異なる時間帯に従って変化することを十分に考慮して、デジタル証明書発行システムがより広く応用されるという利点がある。

登録情報認証ポリシーが認証ポリシーモジュールＴＰＫＩ＿ａｕｓから取得したものであると、ステップ５５０において、認証モジュール（ＴＰＫＩ＿ｃａ）によって、前記ノードと対応する登録情報認証ポリシーに基づいて前記登録情報を認証する。

前記ノードと対応する登録情報認証ポリシーは、例えば上記のように会社の住所が深セン市に位置し、会社の人数が５００人よりも多いなどのセキュリティルールを複数有する可能性がある。認証は、セキュリティルールごとに認証情報がこのセキュリティルールに合致するか否かをそれぞれ考慮する必要がある。全部が合致すると認証に成功する。逆に、認証に失敗する。

ステップ５６０において、認証に成功すると、認証モジュールＴＰＫＩ＿ｃａによって、平文情報と、認証モジュールＴＰＫＩ＿ｃａの秘密鍵を用いて前記平文情報に対して形成した署名とを含む、前記ノードのデジタル証明書を生成して前記ノードに送信することによって、前記ノードが認証モジュールＴＰＫＩ＿ｃａの公開鍵を用いて前記署名を検証するようにし、前記平文情報は前記ノードの公開鍵を含む。

ある実施例では、前記ノードのデジタル証明書を生成するステップは、
前記ノードの公開鍵を含む平文情報を生成するステップと、
所定のサマリアルゴリズムに基づいて前記平文情報に対してサマリを生成するステップと、
前記サマリを認証モジュールＴＰＫＩ＿ｃａの秘密鍵で暗号化して署名を得るステップと、
署名と平文情報とに基づいて前記デジタル証明書を生成するステップと、を含む。

所定のサマリアルゴリズムは、例えば、ハッシュアルゴリズムであってもよい。この実施例でも、一般的な署名の生成過程と類似するように、平文情報に対してサマリを生成した後、サマリを暗号化して署名を得るようになっている。そして、署名を平文情報とともにデジタル証明書に加える。平文情報は前記ノードの公開鍵を有するため、デジタル証明書と発行した公開鍵および秘密鍵とが関連付けられ、デジタル証明書はある特定の公開鍵および秘密鍵が正当的に発行したものであることを証明可能となる。署名の作用としては、前記ノードによる当該デジタル証明書が正当的な機構である認証モジュールＴＰＫＩ＿ｃａから発行されたものであるかの検証を容易にさせ、デジタル証明書の信頼性を高めるとのことである。

これと対応し、ある実施例では、前記署名を認証モジュールＴＰＫＩ＿ｃａの公開鍵で検証するステップは、
デジタル証明書における署名を、認証モジュールＴＰＫＩ＿ｃａの公開鍵で復号するステップと、
デジタル証明書における平文情報に対して前記所定のサマリアルゴリズムによってサマリを生成するステップと、
復号の結果と前記生成したサマリとを比較し、かつ、一致すると検証に成功し、一致しないと検証に失敗するステップとを含む。

ある実施例では、ブロックチェーンネットワークにおけるノードのそれぞれには、前記認証モジュールＴＰＫＩ＿ｃａの公開鍵が記憶される。前記認証モジュールＴＰＫＩ＿ｃａの公開鍵は、前記ノードに記憶される公開鍵から取得してもよい。この実施例は、実現が容易になり、前記認証モジュールＴＰＫＩ＿ｃａの公開鍵を取得する時間を減少したという利点がある。

ある実施例では、前記認証モジュールＴＰＫＩ＿ｃａの公開鍵は、ブロックチェーンにおける当該認証モジュールＴＰＫＩ＿ｃａの公開鍵が記録されるデータブロックから取得してもよい。つまり、例えば、認証モジュールＴＰＫＩ＿ｃａの識別子と対応付けて１つのデータブロックの１つの取引情報に保存するように、認証モジュールＴＰＫＩ＿ｃａの公開鍵をブロックチェーンに書き込んで記憶する。クエリーの際に、ブロックチェーンにおける全てのデータブロックの取引情報から認証モジュールＴＰＫＩ＿ｃａの識別子をサーチし、この取引情報における当該識別子とその対応な公開鍵をサーチする。この実施例は、各ノードの記憶空間の占用比率を減少させたという利点がある。

このデジタル証明書は、正当的な認証モジュールＴＰＫＩ＿ｃａによって発行されたものであると、その復号の結果が前記生成されたサマリと一致し、検証に成功する。認証に成功しないと、デジタル証明書は、正当的な認証モジュールＴＰＫＩ＿ｃａによって発行されたものではない可能性が高い。これにより、デジタル証明書自体の安全性を向上させた。

ある実施例では、ノードは、上記のような署名の検証に加えて、発行機構の正当性に対しても検証を行う。

図１７Ａおよび図１７Ｂに示すように、前記平文情報は、前記ノードが正当的な発行機構の識別子情報リストに基づいてデジタル証明書を検証できるように発行機構の識別子情報を含む。

各ノードには、全ての正当的な発行機構の識別子リストをリストアップした正当的な発行機構の識別子情報リストが記憶されてもよい。識別子情報が当該正当的な発行機構の識別子情報リストに含まれていれば、当該発行機構は正当的なものである。平文情報における発行機構の識別子情報を正当的な発行機構の識別子情報リストにおける正当的な発行機構の識別子情報のそれぞれと逐一対比することにより、当該デジタル証明書が正当的な発行機構によって発行されたものであるか否かを判定することができる。このように発行機構の正当性を検証することは、デジタル証明書の信頼性をさらに向上させたという利点がある。

図１７Ａおよび図１７Ｂは、それぞれ前記ノードが企業またはサービス事業者である場合にデジタル証明書発行センターが前記ノードに対して発行したデジタル証明書の内容の例を示すものである。図１７Ａ－１７Ｂに示すように、企業およびサービス事業者のデジタル証明書のいずれにも、平文情報および平文情報に対する署名が含まれている。

図１７Ａに示すように、企業の平文情報は、企業の公開鍵、発行機構の識別子の以外に、バージョン番号、シリアル番号、署名アルゴリズム、認証モジュールＣＡの公開鍵、企業識別子、有効時間、証明書状態情報および拡張情報を含み得る。当業者であれば、実際には、企業の平文情報は、バージョン番号、シリアル番号、署名アルゴリズム、認証モジュールＣＡの公開鍵、企業識別子、有効時間、証明書状態情報および拡張情報のうちの１つまたは複数のみを含む場合があり、１つも含まない場合もあり得ると理解できろう。

バージョン番号は、ブロックチェーンのバージョン識別子である。ブロックチェーンのバージョンがアップグレードされた場合、デジタル証明書発行センターが発行したデジタル証明書におけるバージョン識別子が変化する。

シリアル番号は、発行されたデジタル証明書の順序番号である。各デジタル証明書は、その発行の順序に従って唯一なシリアル番号を有する。このシリアル番号は、その発行の順序で昇順に生成することができる。

署名アルゴリズムは、認証モジュールＣＡが署名を生成する際に平文情報に対してサマリを生成するためのサマリアルゴリズムである。この署名アルゴリズムを前記ノードに返送するのは、前記ノードが署名を検証するときに当該サマリアルゴリズムを用いて平文情報に対してサマリを新たに生成して、署名の復号結果と対比できるようにするためのことである。

認証モジュールＣＡの公開鍵を前記ノードに返送する意義としては、前記ノードが署名を復号するときに認証モジュールＣＡの公開鍵を用いて復号する必要があるとのことである。

企業識別子は、企業を唯一に区分するためのマークであり、納税者識別番号などを企業識別子としてもよいし、企業に対して専用の識別子を割り当ててもよい。

有効時間は、このデジタル証明書の有効期間のカットオフタイムである。後述するように、秘密鍵をクエリーする場合、そのクエリーしている秘密鍵を前記ノードに返送するか否かを決定するために、当該有効時間に基づいて有効時間の検証を行う必要がある。

証明書状態情報は、例えば、証明書が取り消されたか否かのようなデジタル証明書の状態を示す情報であり、取り消されていない場合、当該証明書状態情報は正常である。

拡張情報は、実際の需要に応じて、デジタル証明書へ追加する必要がある他の情報である。

図１７Ｂは、サービス事業者識別子で企業識別子を、サービス事業者の公開鍵で企業の公開鍵をそれぞれ代替した点で図１７Ａと異なる。サービス事業者識別子は、サービス事業者を唯一に区分するためのマーカーである。サービス事業者の公開鍵は、サービス事業者に割り当てられた公開鍵である。

デジタル証明書は、例えば．ｃｅｒまたは．ｃｒｔなどのようなノードが識別可能な各種のフォーマットとなる構造化されたデータファイルであってもよい。

ある実施例では、前記デジタル証明書発行センターは、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓをさらに含む。秘密鍵管理モジュールは、デジタル証明書発行センターがノードに対して発行した秘密鍵を寄託するためのモジュールである。図７に示すように、前記方法は、ステップ５１０の後に、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓによって、前記ノードから送信された秘密鍵を受信して保存するステップ５２０をさらに含む。

この実施例は、前記ノードが自ら秘密鍵を保存する場合、機器に故障が発生してメモリが破壊されてしまうと、秘密鍵が紛失される可能性があり、そして、秘密鍵を前記ノードのメモリに記憶すると、第三者によって盗み取られやすいのに対して、寄託されるとこれらの問題がなくなるという利点がある。

図８に示すように、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、６－２および６－３によってノードＢｅｒｓとの双方向インタラクションを実現することができる。６－２において、前記ノードは、秘密鍵を秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信する。６－３において、前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、秘密鍵が寄託された旨を前記ノードに通知する。

ある実施例では、図９に示すように、ステップ５２０において、前記ノードから送信された秘密鍵を受信するステップは、
前記ノードが秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵を用いて暗号化した第１のランダムセッション鍵を受信するステップ５２３と、
暗号化された第１のランダムセッション鍵を秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの秘密鍵で復号して、前記第１のランダムセッション鍵を得るステップ５２４と、
前記ノードが前記第１のランダムセッション鍵を用いて暗号化した前記ノードの秘密鍵を受信するステップ５２５と、
復号して得られた第１のランダムセッション鍵を用いて、暗号化された前記ノードの秘密鍵を復号して、前記ノードの秘密鍵を得るステップ５２６と、を含む。

以下、図９に示す上記のような複数のステップについて具体的に説明する。

ステップ５２３において、前記ノードが秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵を用いて暗号化した第１のランダムセッション鍵を受信する。

第１のランダムセッション鍵は、前記ノードが秘密鍵を寄託しようとする場合にランダムに生成した１つのセッション鍵である。

ある実施例では、ブロックチェーンネットワークにおける全てのノードには、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵が記憶されている。この場合、ノードは、記憶されている公開鍵から秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵を取得することができる。この実施例は、実現が容易となり、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵を取得する時間を節約できるという利点がある。

ある実施例では、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵は、ブロックチェーンに記憶され、ノードは、ブロックチェーンにおける当該秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵が記録されるデータブロックから、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵を取得することができる。つまり、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵は、ブロックチェーンに書き込まれて記憶され、かつ秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの識別子と対応付けて１つのデータブロックに記憶されることができる。ブロックチェーンから秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵を取得する場合、当該秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの識別子を持つ全てのデータブロックをサーチして、この識別子と対応付けて１つの取引情報に記憶された公開鍵をサーチすることができる。この実施例は、各ノードの記憶空間を節約できるという利点がある。

ステップ５２４において、暗号化された第１のランダムセッション鍵を秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの秘密鍵で復号して、前記第１のランダムセッション鍵を得る。

秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓのみがその秘密鍵を有しているため、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓのみが暗号化された第１のランダムセッション鍵を復号することができる。そのため、第三者が暗号化された第１のランダムセッション鍵を傍受したとしても、第１のランダムセッション鍵をクラックすることができず、第１のランダムセッション鍵の伝送安全性が保証される。

ステップ５２５において、前記ノードが前記第１のランダムセッション鍵を用いて暗号化した前記ノードの秘密鍵を受信する。

前述したように、第三者が暗号化された第１のランダムセッション鍵を傍受したとしても、第１のランダムセッション鍵をクラックすることができず、前記ノードと秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓのみが第１のランダムセッション鍵を有する。従って、前記ノードの秘密鍵を第１のランダムセッション鍵で暗号化して秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに伝送する場合、暗号化された前記ノードの秘密鍵が途中で第三者によって傍受されてもクラックされることができないので、前記ノードの秘密鍵の伝送安全性が向上する。

ステップ５２６において、復号して得られた第１のランダムセッション鍵を用いて、暗号化された前記ノードの秘密鍵を復号して前記ノードの秘密鍵を得る。

この実施例は、前記ノードの秘密鍵の伝送過程で２回のネゴシエーションプロセスを運用するという利点がある。１回目のネゴシエーションプロセスによって第１のランダムセッション鍵を伝送し、かつ伝送過程では秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵で暗号化し、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは受信した後にその秘密鍵で復号する。２回目のネゴシエーションプロセスによって前記ノードの秘密鍵を伝送し、かつ伝送過程では第１のランダムセッション鍵で暗号化し、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは受信した後に第１のランダムセッション鍵で復号する。第三者がそのうちの１回のネゴシエーションプロセスで伝送されるコンテンツを傍受したとしても、前記ノードの秘密鍵をクラックすることが絶対に不能である。第三者が２回のネゴシエーションプロセスで伝送されるコンテンツを傍受したとしても、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓのみがその秘密鍵を有するため、前記ノードの秘密鍵をクラックすることができない。これにより、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの秘密鍵の伝送安全性に対して二重保証を提供できる。

ある実施例では、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、複数の箇所に分散される複数の秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓであってもよい。いずれかの秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、ノードから送信された秘密鍵を受信すると、他の箇所にある秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信させることができる。

この実施例は、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓが１箇所にのみ設けられる場合、当該秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓが攻撃によって破壊されると、全てのノードが寄託した秘密鍵が紛失してしまうのを防止できるという利点がある。この実施例は、複数箇所に複数の秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓを設置し、かつ、いずれかの秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓがノードから送信された秘密鍵を受信すると、他の箇所にある秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信することにより、１箇所の秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓが破壊されたとしても、他の箇所にある秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓから寄託した秘密鍵を見つけることができ、秘密鍵の寄託の安全性が向上する。

ある実施例では、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓが秘密鍵の寄託を受けて記憶する場合、例えばデータ暗号化規格（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ、ＤＥＳ）、高度暗号化規格（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ、ＡＥＳ）、３ＤＥＳなどの暗号アルゴリズムのような対称暗号アルゴリズムを用いることができる。前記秘密鍵を暗号化する鍵は、秘密鍵管理モジュールにハードコーディングされてもよい。このように、この暗号化された秘密鍵が第三者によって盗み取られたとしても、前記秘密鍵を暗号化する鍵が秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓにハードコーディングされるため、第三者は当該暗号化された秘密鍵を復号することができず、寄託された秘密鍵の安全性がさらに向上する。

ある実施例では、ステップ５２０は、ステップ５２３の前に、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの正当性を検証するプロセスをさらに含む。例えば、図１０に示すように、ステップ５２０は、さらにステップ５２１およびステップ５２２を含む。

ステップ５２１において、認証モジュールＴＰＫＩ＿ｃａによって、前記ノードからの秘密鍵管理モジュールＴＰＫＩ＿ｐｋのデジタル証明書の取得要求を受信する。

秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓのデジタル証明書は、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓが正当的な寄託資質を有することを証明するための書類である。ある実施例では、このデジタル証明書は、認証モジュールＴＰＫＩ＿ｃａによって発行されたものであってもよい。

ステップ５２２において、認証モジュールＴＰＫＩ＿ｃａによって、認証モジュール（ＴＰＫＩ＿ｃａ）の秘密鍵を用いて行った署名を含む、デジタル証明書の取得要求に応じて、前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓのデジタル証明書を前記ノードに送信することによって、前記ノードが前記デジタル証明書を受信した後に認証モジュール（ＴＰＫＩ＿ｃａ）の公開鍵を用いて認証を行うようにすることができる。

この秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓのデジタル証明書は、平文情報と、認証モジュールＴＰＫＩ＿ｃａの秘密鍵を用いて当該平文情報に対して形成した署名とを含む。平文情報には、例えば名称、登録番号、登録時間、授与される権利、権限授与時間等のような秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの基本情報が含まれる。署名の生成方法は、以上と同様であるので説明を省略する。前記ノードは前記デジタル証明書を受信した後に認証モジュール（ＴＰＫＩ＿ｃａ）の公開鍵を用いて検証を行う方法も以上と同様であるため、説明を省略する。

この実施例は、前記ノードの秘密鍵を寄託する前に秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの正当性を検証することができるので、秘密鍵の寄託の安全性を向上することができるという利点がある。

図１１に示すように、ノードＢｅｒｓがその秘密鍵を寄託しようとする場合、まず、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓのデジタル証明書を取得する取得要求を、認証モジュールＴＰＫＩ＿ｃａに送信する。そして、認証モジュールＴＰＫＩ＿ｃａは、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓのデジタル証明書をノードＢｅｒｓに返送する。そして、ノードＢｅｒｓは、認証モジュールＴＰＫＩ＿ｃａから返送されたデジタル証明書を検証する。そして、デジタル証明書の検証に成功すると、ノードＢｅｒｓは、第１のランダムセッション鍵を生成する。その後、ノードＢｅｒｓは、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵を用いて生成した第１のランダムセッション鍵を暗号化する。次に、ノードＢｅｒｓは、暗号化された第１のランダムセッション鍵を秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信する。秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、その秘密鍵を用いて復号して第１のランダムセッション鍵を得ることができる。次に、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、セッション鍵の取得に成功した旨のアラート情報をノードＢｅｒｓへ返送する。そして、ノードＢｅｒｓは、第１のランダムセッション鍵を用いて、ノードＢｅｒｓの秘密鍵を含めて種々の機密情報を暗号化することが可能となる。次に、ノードＢｅｒｓは、暗号化された秘密鍵などの機密情報を秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信する。秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、得た第１のランダムセッション鍵を用いて暗号化された秘密鍵を復号して、ノードＢｅｒｓの秘密鍵を得て、かつ秘密鍵の寄託に成功した旨のアラート情報をノードＢｅｒｓに返送する。このようにして、ノードＢｅｒｓから秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓへの秘密鍵の寄託の全部のプロセスが完了する。

ノードが秘密鍵を秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに寄託した場合、ノードは、秘密鍵を必要となると、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓからその秘密鍵を取得することができる。以下、ノードが秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓからその秘密鍵を取得するプロセスについて説明する。

ある実施例では、前記方法は、ステップ５６０の後に、ステップ５８０～ステップ５１００をさらに含む。図１２に示すように、前記方法は、さらに、
前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓによって、前記ノードからの秘密鍵クエリー要求を受信するステップ５８０と、
ここで、秘密鍵クエリー要求は、前記ノードから送信された、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓから寄託した秘密鍵を取得するための要求であり、例えばＨＴＴＰやＨＴＴＰＳなどの各種のネットワークプロトコルに基づいて作成された要求であってもよい。

前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓによって、前記ノードのデジタル証明書クエリー要求を認証モジュールＴＰＫＩ＿ｃａに送信するステップ５９０と、
認証モジュール（ＴＰＫＩ＿ｃａ）がデジタル証明書クエリー要求に応じて生成されたデジタル証明書の認証に成功した旨の応答を受信すると、前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓによって、秘密鍵クエリー要求に応じて前記ノードにその秘密鍵を送信するステップ５１００と、を含む。

秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、秘密鍵クエリー要求のみを受信すれば寄託された秘密鍵を当該要求の送信元に返送すると、ハッカーなどの犯罪者は、偽りの要求を用いて秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに寄託された秘密鍵を容易に盗み取ることができ、重大な損失を招いてしまう可能性がある。従って、既にデジタル証明書が発行されたノードではなければ、秘密鍵を返送することができない。デジタル証明書は、公開鍵および秘密鍵の正当性を証明することができ、そして、当該デジタル証明書は、前記ノードが要求したものであるため、前記ノードが当該公開鍵および秘密鍵に対して支配権を有することを証明できる。従って、秘密鍵を返送する前に、認証モジュールＴＰＫＩ＿ｃａに前記ノードのデジタル証明書クエリー要求を送信する必要があり、認証モジュールＴＰＫＩ＿ｃａは当該ノードがデジタル証明書を有することをサーチした場合のみに、秘密鍵を返送することができる。

ある実施例では、前記秘密鍵クエリー要求およびデジタル証明書クエリー要求は、いずれも前記ノードの公開鍵を有する。図１７Ａ－１７Ｂに示すように、前記デジタル証明書には、前記ノードの公開鍵が含まれる。認証モジュールＴＰＫＩ＿ｃａは、前記公開鍵に基づいて前記ノードのデジタル証明書をクエリーすることができる。

ある実施例では、前記秘密鍵クエリー要求およびデジタル証明書クエリー要求は、いずれも前記ノードの識別子を有する。図１７Ａ－１７Ｂに示すように、前記デジタル証明書は、例えば図１７Ａに示す企業識別子および図１７Ｂに示すサービス事業者識別子などの前記ノードの識別子を有する。認証モジュールＴＰＫＩ＿ｃａは、前記ノードの識別子に基づいて前記ノードのデジタル証明書をクエリーする。

ある実施例では、前記秘密鍵クエリー要求およびデジタル証明書クエリー要求は、いずれも前記デジタル証明書のシリアル番号を有する。図１７Ａ－１７Ｂに示すように、前記デジタル証明書は、そのシリアル番号を有する。認証モジュールＴＰＫＩ＿ｃａは、前記シリアル番号に基づいて前記ノードのデジタル証明書をクエリーする。

ある実施例では、図１３に示すように、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓが秘密鍵クエリー要求に応じて前記ノードの秘密鍵を前記ノードに送信するプロセスは、以下のステップを含んでもよい。

ステップ５１１０において、前記ノードが秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵で暗号化した第２のランダムセッション鍵を受信する。

前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵は以上と同様であるため、説明を省略する。

第２のランダムセッション鍵は、第１のランダムセッション鍵と比べて、前記ノードが同一の生成方式で生成したものであってもよいし、異なる生成方式で生成したものであってもよい。

ステップ５１２０において、暗号化された第２のランダムセッション鍵を秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの秘密鍵で復号して、前記第２のランダムセッション鍵を得る。

ここで、上記の暗号化された第１のランダムセッション鍵を復号するプロセスと同様であるため、説明を省略する。

ステップ５１３０において、秘密鍵クエリー要求に応じて、前記ノードの秘密鍵をクエリーする。

ある実施例では、ステップ５２５は、前記ノードが前記第１のランダムセッション鍵を用いて暗号化した前記ノードの秘密鍵および公開鍵を受信するステップを含む。ステップ５２６は、復号して得た第１のランダムセッション鍵を用いて、暗号化された前記ノードの秘密鍵および公開鍵を復号し、得られた秘密鍵および公開鍵を対応付けて記憶するステップを含む。ステップ５１３０は、秘密鍵クエリー要求における前記ノードの公開鍵に応じて、記憶された公開鍵と対応する秘密鍵をクエリーするステップを含む。

ある実施例では、ステップ５２５は、前記ノードが前記第１のランダムセッション鍵を用いて暗号化した前記ノードの秘密鍵と、前記ノードの識別子とを受信するステップを含む。ステップ５２６は、復号して得た第１のランダムセッション鍵を用いて、暗号化された前記ノードの秘密鍵と前記ノードの識別子とを復号し、得られた秘密鍵と前記ノードの識別子とを対応付けて記憶するステップを含む。ステップ５１３０は、秘密鍵クエリー要求における前記ノードの識別子に応じて、記憶された前記識別子と対応する秘密鍵をクエリーするステップを含む。

ステップ５１４０は、前記ノードの秘密鍵を前記第２のランダムセッション鍵で暗号化して前記ノードに送信し、前記ノードが前記第２のランダムセッション鍵を用いて暗号化された前記ノードの秘密鍵を復号して、前記ノードの秘密鍵を得るステップを含む。

ある実施例では、第２のランダムセッション鍵は、対称暗号アルゴリズムに基づいて生成されたものである。前記ノードの秘密鍵を前記第２のランダムセッション鍵で暗号化するプロセス、および暗号化された前記ノードの秘密鍵を前記第２のランダムセッション鍵で復号するプロセスは、上記の前記ノードの秘密鍵を前記第１のランダムセッション鍵で暗号化するプロセス、および暗号化された前記ノードの秘密鍵を前記第１のランダムセッション鍵で復号するプロセスと同様であるので、説明を省略する。秘密鍵を寄託する場合の２回のネゴシエーションと同様に、秘密鍵をクエリーする場合の２回のネゴシエーションも、秘密鍵の伝送過程における安全性を高めるという効果を奏することができる。

ある実施例では、図１Ｃに示すように、前記ブロックチェーンは、複数のサブブロックチェーンを含む。異なるサブブロックチェーンに対するデータブロックの書き込みおよびクエリーは、異なる公開／秘密鍵ペアが必要となるので、ブロックチェーンにおける公開鍵および秘密鍵の利用安全性をより向上させることが可能となる。第三者が１つのサブブロックチェーンに対する書き込みおよびクエリーのための公開鍵および秘密鍵を知ったとしても、他のサブブロックチェーンに対する書き込みおよびクエリーのための公開鍵および秘密鍵を知ることは難しい。

この実施例では、前記公開／秘密鍵要求には、登録対象サブブロックチェーンの識別子が含まれる。前記ノードに対して前記ノードの公開鍵および秘密鍵を生成するステップは、前記ノードに対して前記ノードの登録対象サブブロックチェーンにおける公開鍵および秘密鍵を生成するステップを含む。具体的には、公開／秘密鍵要求における登録対象サブブロックチェーンの識別子に応じて、ノードに対してこれらサブブロックチェーンにおける公開鍵および秘密鍵を生成する。サブブロックチェーンは複数存在しているが、前記ノードは、そのうちの一部のサブブロックチェーンを使用しない可能性があるため、後に使用する可能性があるサブブロックチェーンにおける公開鍵および秘密鍵のみを要求すればよい。

ノードがどのサブブロックチェーンにおける公開鍵および秘密鍵を要求したかに基づいて、これらのサブブロックチェーンに対して認証が成功すればよい。そこで、この実施例では、前記登録情報は、登録対象サブブロックチェーンを含み、これらのサブブロックチェーンは、公開鍵および秘密鍵の発行を要求するサブブロックチェーンと一致する。ステップ５４０は、認証ポリシーモジュールＴＰＫＩ＿ａｕｓから、登録対象サブブロックチェーンに対応する登録情報認証ポリシーを取得するステップを含む。すなわち、サブブロックチェーン毎に異なる認証ポリシーを有し、前記ノード毎に登録するサブブロックチェーン（登録対象サブブロックチェーン）に対して対応する認証ポリシーで認証することができる。

ステップ５５０は、登録対象サブブロックチェーンに対応する登録情報認証ポリシーに基づいて、登録対象サブブロックチェーンにおける前記登録情報の認証を行うステップを含む。前記平文情報には、認証に成功したサブブロックチェーンにおける公開鍵が含まれる。

前記ノードが各登録対象サブブロックチェーンにそれぞれ認証されるため、そのうちの一部の登録対象サブブロックチェーンの認証に成功するが、他部の登録対象サブブロックチェーンの認証に失敗することがある。この場合、認証に成功したサブブロックチェーンのみに対して証明書を発行する。すなわち、証明書の平文情報には、認証に成功したサブブロックチェーンにおける公開鍵のみが含まれる。これにより、デジタル証明書の平文情報に含まれる公開鍵のみから、前記ノードがどのサブブロックチェーンにおいて認証に成功して権限を有するかを確定することができる。

例えば、前記ノードに対応する登録対象サブブロックチェーンは、サブブロックチェーン２、３であり、そのうち、サブブロックチェーン２の認証ポリシーは、住所が深セン市にあることであり、サブブロックチェーン３の認証ポリシーは、会社の人数が５００人を超えることである場合、当該企業は、人数が２０００人以上であるとともに北京に位置する工場であるため、サブブロックチェーン３の認証に成功し、サブブロックチェーン２の認証に失敗する。サブブロックチェーン３の公開鍵のみをデジタル証明書の平文情報に書き込む。

この実施例は、サブブロックチェーンが複数存在する場合に、異なるサブブロックチェーンに対して異なる認証を行うことにより、異なるサブブロックチェーンの認証結果を得ることによって、デジタル証明書が公開鍵および秘密鍵の正当性への証明をサブブロックチェーンに精確することができ、デジタル証明書の利用自由度を向上させることができるという利点がある。

ある実施例では、前記秘密鍵クエリー要求は、クエリーとなる秘密鍵が所属するサブブロックチェーンを含み、前記ノードのデジタル証明書クエリー要求は、クエリーとなる秘密鍵が所属するサブブロックチェーンを含むようにして、前記認証モジュールＴＰＫ１＿ｃａは、クエリーとなる秘密鍵が所属するサブブロックチェーンが前記デジタル証明書の平文情報に含まれる認証に成功した公開鍵と対応するサブブロックチェーンであるか否かに応じて、デジタル証明書の認証に成功した旨の応答を送信するか否かを確定することができる。

すなわち、上記の実施例では、ステップ５１００において、認証モジュールＴＰＫＩ＿ｃａは、デジタル証明書クエリー要求における前記ノードの識別子のみに基づいて、前記ノードに対してデジタル証明書を発行したか否かをクエリーすることができる。発行した場合、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓにデジタル証明書の認証に成功した旨の応答を送信することができる。しかし、この実施例では、異なるサブブロックチェーンが存在するため、前記ノードが秘密鍵を取得しようとするサブブロックチェーンにおいて前記ノードが権限を有しているか否かを具体的に検証する必要がある。この場合、平文情報に含まれる公開鍵をそのデジタル証明書の平文情報からサーチする必要があり、これらの公開鍵に対応するサブブロックチェーンは、前記ノードが権限を有するサブブロックチェーンであるので、それらにデジタル証明書の認証に成功した旨の応答を送信することができ、応答には認証に成功したサブブロックチェーンが含まれる。秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、認証に成功したサブブロックチェーンのみに基づいて、クエリーを要求している秘密鍵を前記ノードに返送する。例えば、前記ノードは、サブブロックチェーン２および３における秘密鍵を要求する可能性があるが、認証モジュールＴＰＫＩ＿ｃａは、そのデジタル証明書をクエリーして、デジタル証明書にサブブロックチェーン３における公開鍵のみが含まれることを発見したため、サブブロックチェーン３における秘密鍵のみを前記ノードに返送する。

この実施例は、サブブロックチェーンが複数存在する場合、寄託された秘密鍵のクエリーの自由度を高めることができるという利点がある。前記ノードは、認証に成功しかつデジタル証明書において対応する公開鍵を有する秘密鍵のみをクエリーすることができる。

ある実施例では、認証モジュールＴＰＫＩ＿ｃａは、デジタル証明書の認証に成功した旨の応答を秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信する場合、上記の認証に加えて、デジタル証明書が期限を過ぎているかを検証しする必要がある。期限を過ぎていると、デジタル証明書の再登録が必要となる。図１７Ａ－１７Ｂに示すように、前記平文情報には、有効時間がさらに含まれる。前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓによって前記ノードのデジタル証明書クエリー要求を認証モジュールＴＰＫＩ＿ｃａに送信した後、認証モジュールＴＰＫＩ＿ｃａは、前記ノードに対応するデジタル証明書を見つけて、デジタル証明書における有効時間と現在の時間との比較に基づいて当該デジタル証明書の有効時間を検証する。有効時間の検証に成功した場合のみに、デジタル証明書の認証に成功した旨の応答を前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信する。

具体的には、有効時間は、このデジタル証明書の有効期間のカットオフタイムであってもよい。この有効時間が現在のデータよりも早い場合、認証に失敗する。この有効時間が現在の時間よりも遅い場合、認証に成功する。この実施例は、デジタル証明書の適時性を検証することにより、デジタル証明書の信頼性をさらに高めることができるという利点がある。

デジタル証明書は、期限を過ぎていなくても、会社の違法行為などにより取り消される可能性がある。ある実施例では、認証モジュールＴＰＫＩ＿ｃａは、デジタル証明書の認証に成功した旨の応答を秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信する前、上記の検証に加えて、デジタル証明書の状態、すなわち取り消されたか否かを検証する必要がある。取り消されると、秘密鍵を発行しない。図１７Ａ－１７Ｂに示すように、前記平文情報には、証明書状態情報がさらに含まれる。前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓによって前記ノードのデジタル証明書クエリー要求を認証モジュールＴＰＫＩ＿ｃａに送信した後、認証モジュールＴＰＫＩ＿ｃａは、前記証明書状態情報に基づいて当該デジタル証明書の状態を検証する。状態の検証に成功した場合のみに、デジタル証明書の認証に成功した旨の応答を前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信する。

具体的には、証明書状態情報は当該デジタル証明書が正常であることを示している場合、状態の検証に成功する。一方、証明書状態情報はデジタル証明書が取り消されたことを示している場合、状態の検証に失敗する。この実施例は、デジタル証明書の状態を検証することにより、デジタル証明書の信頼性をさらに高めることができるという利点がある。

ある実施例では、前記ノードは、会社ノードとサービス事業者ノードとを含む。サービス事業者は、会社が自らブロックチェーンに対する取引情報の書き込みまたはクエリーの条件を有しないだけではなく（すなわち、図１Ａ－１Ｃにおける記帳ノード１０１ではなく）、ブロックチェーンに対する取引情報の書き込みまたはクエリーを記帳ノード１０１に委任する条件も有しない（すなわち、図１Ａにおける取引情報生成者ノード１０２でもなく、図１Ｂ－１Ｃにおけるトラフィックノード１０５でもない）場合、これらの会社の委任を受けて、これらの会社に対してブロックチェーンに対する取引情報の書き込みまたはクエリーを記帳ノード１０１に委任することを実行するエンティティである。もちろん、自己がブロックチェーンに対する取引情報の書き込みまたはクエリーの条件を有し、またはブロックチェーンに対する取引情報の書き込みまたはクエリーを記帳ノード１０１に委任する条件を有しても、ブロックチェーンに対する書き込みまたはクエリーをあるサービス事業者に委任することもある。

サービス事業者は、一部の会社に代わってブロックチェーンに対する取引情報の書き込みまたはクエリーの委任を行い、そのクエリーする秘密鍵がその自身の秘密鍵だけではなく、その受託会社のノードの秘密鍵となる可能性もある。従って、デジタル証明書の発行時にサービス事業者ノードが保有する権限情報を記録して保存する。サービス事業者ノードが会社ノードに代わって秘密鍵をクエリーする場合、前記秘密鍵クエリー要求には、前記サービス事業者ノードの識別子と、前記サービス事業者ノードのクエリーしようとする鍵が所属するノードの識別子とが含まれ、前記認証モジュールＴＰＫ１＿ｃａは、記憶された前記権限情報に基づいて、前記サービス事業者ノードのクエリーしようとする鍵が所属するノードの識別子が前記サービス事業者ノードがサービスを提供している会社またはサービス事業者ノードの識別子であるか否かを確定する。「ＹＥＳ」の場合、認証に成功する。逆に、認証に失敗する。

具体的には、前記ノードがサービス事業者ノードである場合、前記ノードの公開鍵および登録情報を受信するステップは、前記ノードの公開鍵、登録情報、およびサービス事業者ノードがサービスを提供している会社の権限情報を受信するステップを含む。例えば、サービス事業者ノードＡは、会社ノードＡ１、Ａ２、Ａ３に代わって、ブロックチェーンに対する取引情報の書き込みまたはクエリーの委任を行う場合、権限情報はＡ１、Ａ２、Ａ３を含む。

この実施例では、デジタル証明書発行センターは認証ポリシーモジュール（ＴＰＫＩ＿ａｕｓ）をさらに含む場合、前記方法は、認証モジュールＴＰＫＩ＿ｃａによって前記登録情報を認証した後に、認証に成功すると、認証モジュールＴＰＫＩ＿ｃａによって前記権限情報を認証ポリシーモジュールＴＰＫＩ＿ａｕｓに送信して記憶するステップをさらに含む。具体的には、前記ノードの識別子を、前記権限情報と対応付けて記憶することができる。

この実施例では、前記秘密鍵クエリー要求は、前記サービス事業者ノードの識別子と、前記サービス事業者ノードのクエリーしようとする鍵が所属するノードの識別子とを含み、前記認証モジュールＴＰＫＩ＿ｃａは、認証ポリシーモジュールＴＰＫＩ＿ａｕｓに記憶された前記権限情報に基づいて、前記サービス事業者ノードのクエリーしようとする鍵が所属するノードの識別子が、前記サービス事業者ノードがサービスを提供している会社またはサービス事業者ノードの識別子であるとした場合、認証に成功する。例えば、認証ポリシーモジュールＴＰＫＩ＿ａｕｓに記憶されたサービス事業者ノードＡの権限情報は、会社ノードＡ１、Ａ２、Ａ３を含み、サービス事業者ノードのクエリーしようとする鍵がＡ１、Ａ２、Ａ３、Ａのうちのいずれか１つまたは複数のノードの秘密鍵であると、認証に成功し、秘密鍵を返送することができる。

この実施例は、サービス事業者ノードが複数の会社ノードに代わってブロックチェーンに対する書き込みまたはクエリーの委任を行う場面に対して秘密鍵管理技術の実現を支援することができるという利点がある。

サブブロックチェーンは、通常、ある種類の取引情報のデータブロックに特定される。例えば、１つのサブブロックチェーンがサプライチェーン金融の取引情報のデータブロックを記録し、別の１つのサブブロックチェーンが電子伝票の取引情報のデータブロックを記録する。１種類のノードの取引種別も比較的に一定となるため、記録が必要なサブブロックチェーンも比較的に一定となる。そこで、ある実施例では、ノードの取引種別に応じて、サブブロックチェーンの権限を自動的に設定することができる。例えば、自動車製造企業に対しては、通常、サプライチェーン金融トラフィックを必要とするが、電子伝票も実行されるため、サプライチェーン金融のサブブロックチェーンおよび電子伝票のサブブロックチェーンを必要とする。

この実施例では、前記ブロックチェーンは、複数のサブブロックチェーンを含み、前記登録情報は、ノード種別を含む。前記ノードに対して前記ノードの公開鍵および秘密鍵を生成するステップは、前記ノードに対して異なるサブブロックチェーンにおける前記ノードの公開鍵および秘密鍵を生成するステップを含む。Ｎ本のサブブロックチェーンが存在するとすると、前記ノードに対して、Ｎ本のサブブロックチェーンと対応するＮ個の公開／秘密鍵ペアを生成することができる。

デジタル証明書発行センターは認証ポリシーモジュール（ＴＰＫＩ＿ａｕｓ）をさらに含む場合、前記方法は、ステップ５５０において認証モジュールＴＰＫＩ＿ｃａによって前記登録情報を認証した後に、認証に成功すると、認証モジュールＴＰＫＩ＿ｃａによって、前記ノード種別に基づいて前記ノード種別に特定されるサブブロックチェーン権限情報を生成して、サブブロックチェーン権限情報を認証ポリシーモジュールＴＰＫＩ＿ａｕｓに記憶するステップであって、当該サブブロックチェーン権限情報は、異なるトラフィック種別に対してクエリーが許容されるサブブロックチェーンを含むステップをさらに含む。

前記ノード種別に特定されるサブブロックチェーン権限情報は、ノード種別に従って、予め設定されたノード種別とサブブロックチェーン権限情報との対応関係テーブルからサーチしたものであっても良い。例えば、この対応関係テーブルにおいて、自動車製造企業に対応するサブブロックチェーン権限情報は、サプライチェーン金融のトラフィック種別に対してクエリーが許容されるサブブロックチェーンがサブブロックチェーン２であり、電子伝票のトラフィック種別に対してクエリーが許容されるサブブロックチェーンがサブブロックチェーン３であるものである。その後、このサブブロックチェーン権限情報を認証ポリシーモジュールＴＰＫＩ＿ａｕｓに記憶する。

この実施例では、前記秘密鍵クエリー要求は、前記ノード種別とトラフィック種別とを有し、前記デジタル証明書クエリー要求も、前記ノード種別とトラフィック種別とを有する。前記認証モジュールＴＰＫＩ＿ｃａは、前記ノード種別に特定されたサブブロックチェーン権限情報を認証ポリシーモジュールＴＰＫＩ＿ａｕｓからクエリーし、当該サブブロックチェーン権限情報および当該トラフィック種別に基づいて、クエリーが許容されるサブブロックチェーンを確定し、クエリーが許容されるサブブロックチェーンをデジタル証明書の認証に成功した旨の応答に入れて、前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信する。前記ノードの秘密鍵を前記ノードに送信するステップは、クエリーが許容されるサブブロックチェーンにおける前記ノードの秘密鍵を前記ノードに送信するステップを含む。

例えば、前記ノード種別は自動車製造企業ノードであり、トラフィック種別は電子伝票である場合、認証モジュールＴＰＫＩ＿ｃａは、まずデジタル証明書クエリー要求におけるノード種別である自動車製造企業ノードに基づいて、認証ポリシーモジュールＴＰＫＩ＿ａｕｓから対応するサブブロックチェーン権限情報をクエリーする。すなわち、サプライチェーン金融トラフィック種別に対してクエリーが許容されるサブブロックチェーンは、サブブロックチェーン２であり、電子伝票トラフィック種別に対してクエリーが許容されるサブブロックチェーンはサブブロックチェーン３である。その後、デジタル証明書クエリー要求におけるトラフィック種別である電子伝票に基づいて、クエリーが許容されるサブブロックチェーンがサブブロックチェーン３であると確定する。そして、サブブロックチェーン３をデジタル証明書の認証に成功した旨の応答に入れて、前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信する。この場合、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、サブブロックチェーン３における前記ノードの秘密鍵のみをノードに返送し、他のサブブロックチェーンにおける秘密鍵を前記ノードに返送しない。

このようにすれば、サブブロックチェーンが複数存在する場合、ユーザに対して前記ノード種別やトラフィック種別に適合するサブブロックチェーンにおける秘密鍵を正確に見つけることができ、サブブロックチェーンが複数ある場合に寄託された秘密鍵の精細管理を実現することができるという利点がある。

図１４は、前記ノードに対して寄託された秘密鍵をクエリーするための詳細なインタラクティブのフローを示す図である。ノードＢｅｒｓは、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに寄託された秘密鍵をクエリーするために、先ずは、その秘密鍵を寄託している秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに秘密鍵クエリー要求を送信する。秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、１つのデジタル証明書クエリー要求を認証モジュールＴＰＫＩ＿ｃａに送信する。その後、認証モジュールＴＰＫＩ＿ｃａは、この要求に応じて、当該ノードがデジタル証明書を有しているか、および当該デジタル証明書が期限を過ぎたり取り消されたりするかを検証し、これらの検証がいずれも成功すれば、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓにデジタル証明書の認証に成功した旨の応答を送信する。その後、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、セッション鍵の送信を指示する要求をノードＢｅｒｓに送信する。ノードＢｅｒｓは、第２のランダムセッション鍵を生成して、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵を用いてこの第２のランダムセッション鍵を暗号化する。その後、ノードＢｅｒｓは、暗号化された第２のランダムセッション鍵を秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信する。秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、暗号化された第２のランダムセッション鍵を受信すると、まずは暗号化された第２のランダムセッション鍵をそれが所有する秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの秘密鍵で復号して、第２のランダムセッション鍵を得る。その後、第２のランダムセッション鍵を用いて前記ノードが寄託した秘密鍵を暗号化してノードＢｅｒｓに送信する。ノードＢｅｒｓは、暗号化された情報を受信すると、当該ノードが第２のランダムセッション鍵を保有しているため、この第２のランダムセッション鍵を用いて暗号化した秘密鍵を、当該第２のランダムセッション鍵で復号して、秘密鍵管理モジュール（ＴＰＫＩ＿ｐｋｓ）に寄託した秘密鍵を得ることができる。最終に、ノードＢｅｒｓは、寄託した秘密鍵の受信に成功した旨の確認メッセージを秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに返送する。

ある実施例では、前記登録情報は、前記ノードの識別子を含む。前記デジタル証明書発行センターは、図１５に示すように、認証データベースＴＰＫＩ＿ｃａｄｂを含む。認証データベースＴＰＫＩ＿ｃａｄｂは、発行されたデジタル証明書を記憶するためのデータベースである。

前記方法は、認証モジュールＴＰＫＩ＿ｃａによって前記ノードのデジタル証明書を生成した後に、認証モジュールＴＰＫＩ＿ｃａによって、前記ノードの識別子とノードのデジタル証明書とを認証データベースＴＰＫＩ＿ｃａｄｂに対応付けて記憶するステップ５７０をさらに含む。

この実施例では、前記秘密鍵クエリー要求は、前記ノードの識別子を含み、前記デジタル証明書クエリー要求は、前記ノードの識別子を含むので、前記認証モジュールＴＰＫＩ＿ｃａは、認証データベースＴＰＫＩ＿ｃａｄｂに前記識別子と対応付けて記憶されているデジタル証明書があるか否かに基づいて、認証に成功したか否かを確定することができる。すなわち、認証モジュールＴＰＫＩ＿ｃａは、デジタル証明書クエリー要求を受信して前記ノードが有するデジタル証明書をクエリーすることにより、デジタル証明書の認証に成功した旨の応答を前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信するか否かを確定する場合、デジタル証明書クエリー要求における前記ノードの識別子に基づいて、認証データベースＴＰＫＩ＿ｃａｄｂにおいて対応するデジタル証明書をサーチする。

図１６は、本開示の一実施例に係るデジタル証明書発行センターの詳細を示すブロック図である。この実施例では、デジタル証明書発行センターは、図１６に示すように、以上で説明した公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋ、認証モジュールＴＰＫＩ＿ｃａ、認証ポリシーモジュールＴＰＫＩ＿ａｕｓ、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓ、認証データベースＴＰＫＩ＿ｃａｄｂの以外に登録モジュールＴＰＫＩ＿ｒａを含む。登録モジュールＴＰＫＩ＿ｒａは、前記ノードＢｅｒｓから受信した公開鍵および登録情報を認証モジュールＴＰＫＩ＿ｃａに伝送するとともに、生成したデジタル証明書をノードＢｅｒｓに返送するモジュールであって、ノードＢｅｒｓと認証モジュールＴＰＫＩ＿ｃａとの中継モジュールである。すなわち、ステップ５３０は、登録モジュールＴＰＫＩ＿ｒａによって転送された前記ノードの公開鍵および登録情報を受信するステップを含む。デジタル証明書を前記ノードに送信するステップ５６０は、デジタル証明書を登録モジュールＴＰＫＩ＿ｒａを介して前記ノードに送信するステップを含む。

本開示の一実施例によれば、デジタル証明書発行センターが提供される。当該デジタル証明書発行センターは、図６に示すように、ブロックチェーンネットワークにおけるノードからの公開／秘密鍵要求に応じて、前記ノードに対して前記ノードの公開鍵および秘密鍵を生成して、前記ノードに送信する公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋと、前記ノードの公開鍵および登録情報を受信して、前記登録情報を認証し、かつ、認証に成功すると、平文情報と、認証モジュールＴＰＫＩ＿ｃａの秘密鍵を用いて前記平文情報に対して形成した署名とを含む、前記ノードのデジタル証明書を生成して前記ノードに送信することによって、前記ノードが認証モジュールＴＰＫＩ＿ｃａの公開鍵を用いて前記署名を検証するようにする認証モジュールであって、前記平文情報は、前記ノードの公開鍵を含む認証モジュールＴＰＫＩ＿ｃａと、を含む。

ある実施例では、図６に示すように、前記デジタル証明書発行センターは、ブロックチェーンネットワークにおける各ノードに対応する登録情報認証ポリシーを記憶するための認証ポリシーモジュールＴＰＫＩ＿ａｕｓをさらに含む。

ある実施例では、図８に示すように、前記デジタル証明書発行センターは、前記ノードから送信された秘密鍵を受信して保存するための秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓをさらに含む。

ある実施例では、前記認証モジュールＴＰＫＩ＿ｃａは、前記ノードが秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵を用いて暗号化した第１のランダムセッション鍵を受信し、暗号化された第１のランダムセッション鍵を秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの秘密鍵で復号して、前記第１のランダムセッション鍵を得られ、前記ノードが前記第１のランダムセッション鍵を用いて暗号化した前記ノードの秘密鍵を受信し、復号して得た第１のランダムセッション鍵を用いて、暗号化された前記ノードの秘密鍵を復号して、前記ノードの秘密鍵を得るために用いられる。

ある実施例では、前記認証モジュールＴＰＫＩ＿ｃａは、さらに、前記ノードから送信された前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓのデジタル証明書取得要求を受信し、前記デジタル証明書取得要求に応じて、前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓのデジタル証明書を前記ノードに送信するために用いられる。ここで、前記デジタル証明書は、認証モジュールＴＰＫＩ＿ｃａの秘密鍵を用いて形成した署名を含み、前記ノードは、前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓのデジタル証明書を受信した後に、認証モジュールＴＰＫＩ＿ｃａの公開鍵を用いて認証を行う。

ある実施例では、前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、さらに、前記ノードの秘密鍵クエリー要求を受信し、前記ノードのデジタル証明書クエリー要求を認証モジュールＴＰＫＩ＿ｃａに送信し、前記認証モジュールＴＰＫＩ＿ｃａが前記デジタル証明書クエリー要求に応じて生成したデジタル証明書の認証に成功した旨の応答を受信すると、前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓによって、前記秘密鍵クエリー要求に応じて前記ノードの秘密鍵を前記ノードに送信するために用いられる。

ある実施例では、前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓは、さらに、前記ノードが秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの公開鍵を用いて暗号化した第２のランダムセッション鍵を受信し、暗号化された第２のランダムセッション鍵を秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓの秘密鍵で復号して、前記第２のランダムセッション鍵を得られ、
前記秘密鍵クエリー要求に応じて前記ノードの秘密鍵をクエリーし、前記ノードが前記第２のランダムセッション鍵を用いて暗号化された前記ノードの秘密鍵を復号して前記ノードの秘密鍵を得られるように、前記ノードの秘密鍵を前記第２のランダムセッション鍵を用いて暗号化して前記ノードに送信するために用いられる。

ある実施例では、前記登録情報は、前記ノードの識別子を含む。図１６に示すように、前記デジタル証明書発行センターは、前記ノードの識別子と前記ノードのデジタル証明書とを対応付けて記憶するための認証データベースＴＰＫＩ＿ｃａｄｂを含む。ここで、前記秘密鍵クエリー要求は、前記ノードの識別子を含み、前記デジタル証明書クエリー要求は、前記ノードの識別子を含むので、前記認証モジュールＴＰＫＩ＿ｃａは、認証データベースＴＰＫＩ＿ｃａｄｂに前記識別子と対応付けて記憶されているデジタル証明書があるか否かに基づいて、認証に成功したか否かを確定することができる。

ある実施例では、前記ノードは、会社ノードとサービス事業者ノードとを含む。

前記ノードがサービス事業者ノードである場合、前記ノードの公開鍵および登録情報を受信するステップは、前記ノードの公開鍵、登録情報、およびサービス事業者ノードがサービスを提供している会社の権限情報を受信するステップを含む。

前記デジタル証明書発行センターが認証ポリシーモジュールＴＰＫＩ＿ａｕｓをさらに含む場合、前記認証モジュールＴＰＫＩ＿ｃａは、さらに、認証に成功すると、前記権限情報を認証ポリシーモジュールＴＰＫＩ＿ａｕｓに送信するために用いられる。

前記秘密鍵クエリー要求は、前記サービス事業者ノードの識別子と、前記サービス事業者ノードのクエリーしようとする鍵が所属するノードの識別子とを含む。前記認証モジュールＴＰＫＩ＿ｃａは、さらに、認証ポリシーモジュールＴＰＫＩ＿ａｕｓに記憶される権限情報に基づいて、前記サービス事業者ノードのクエリーしようとする鍵が所属するノードの識別子が、前記サービス事業者ノードがサービスを提供している会社または前記サービス事業者ノードの識別子であると確定した場合、認証に成功するとするために用いられる。

ある実施例では、前記ノードに対応する登録情報認証ポリシーは、前記ノード種別に特定される登録情報認証ポリシーを含む。前記登録情報には、前記ノード種別が含まれる。前記認証モジュールＴＰＫＩ＿ｃａは、認証ポリシーモジュールＴＰＫＩ＿ａｕｓから前記ノード種別に特定される登録情報認証ポリシーを取得するために用いられる。

ある実施例では、前記ブロックチェーンは、複数のサブブロックチェーンを含み、前記ノードに対して前記ノードの公開鍵および秘密鍵を生成するステップは、前記ノードに対して登録対象サブブロックチェーンにおける前記ノードの公開鍵および秘密鍵を生成するステップを含む。前記登録情報は、登録対象サブブロックチェーンを含む。前記認証モジュールＴＰＫＩ＿ｃａは、さらに、登録対象サブブロックチェーンと対応する登録情報認証ポリシーを認証ポリシーモジュールＴＰＫＩ＿ａｕｓから取得し、前記登録対象サブブロックチェーンと対応する登録情報認証ポリシーに基づいて、登録対象サブブロックチェーンにおける前記登録情報の認証を行うために用いられる。前記平文情報は、認証に成功したサブブロックチェーンの公開鍵を含む。

ある実施例では、前記秘密鍵クエリー要求は、クエリーする秘密鍵が所属するサブブロックチェーンを含み、前記ノードのデジタル証明書クエリー要求は、クエリーする秘密鍵が所属するサブブロックチェーンを含むようにして、前記認証モジュールＴＰＫ１＿ｃａは、クエリーする秘密鍵が所属するサブブロックチェーンが前記デジタル証明書の平文情報に含まれる認証に成功した公開鍵と対応するサブブロックチェーンであるか否かに応じて、デジタル証明書の認証に成功した旨の応答を送信するか否かを確定することができる。

ある実施例では、前記ブロックチェーンは、複数のサブブロックチェーンを含み、前記登録情報は、ノード種別を含む。前記公開／秘密鍵生成モジュールＴＰＫＩ＿ｓｄｋは、前記ノードに対して異なるサブブロックチェーンにおける前記ノードの公開鍵および秘密鍵を生成するために用いられる。デジタル証明書発行センターが認証ポリシーモジュールＴＰＫＩ＿ａｕｓをさらに含む場合、認証モジュールＴＰＫ１＿ｃａは、前記登録情報を認証した後、認証に成功すると、前記ノード種別に基づいて前記ノード種別に特定されるサブブロックチェーン権限情報を生成して、当該サブブロックチェーン権限情報を認証ポリシーモジュールＴＰＫＩ＿ａｕｓに記憶するために用いられる。ここで、当該サブブロックチェーン権限情報は、異なるトラフィック種別に対してクエリーが許容されるサブブロックチェーンを含む。前記秘密鍵クエリー要求は、前記ノード種別およびトラフィック種別を含む。前記デジタル証明書クエリー要求は、前記ノード種別およびトラフィック種別を含む。前記認証モジュールＴＰＫ１＿ｃａは、前記ノード種別に特定されるサブブロックチェーン権限情報を認証ポリシーモジュールＴＰＫＩ＿ａｕｓからクエリーし、当該サブブロックチェーン権限情報および当該トラフィック種別に基づいて、クエリーが許容されるサブブロックチェーンを確定し、クエリーが許容されるサブブロックチェーンをデジタル証明書の認証に成功した旨の応答に入れて、前記秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに送信する。前記ノードの秘密鍵を前記ノードに送信するステップは、クエリーが許容されるサブブロックチェーンにおける前記ノードの秘密鍵を前記ノードに送信するステップを含む。

ある実施例では、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓに記憶された秘密鍵は、暗号化方式によって記憶され、暗号化に用いられる暗号は、秘密鍵管理モジュールＴＰＫＩ＿ｐｋｓにハードコーディングされる。

本開示の実施例に係るブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法は、図１８に示すデジタル証明書発行センター１０３により実現することができる。以下、本開示の実施例に係るデジタル証明書発行センター１０３について図１８を参照しながら説明する。図１８に示すデジタル証明書発行センター１０３は、あくまでも一例に過ぎなく、本開示の実施例の機能および使用範囲に何ら制限を与えない。

図１８に示すように、デジタル証明書発行センター１０３は、汎用の計算装置として表現される。デジタル証明書発行センター１０３は、上記の少なくとも１つの処理部７１０と、上記の少なくとも１つの記憶部７２０と、異なるシステム構成要素（記憶部７２０と処理部７１０を含む）を接続するためのバス７３０とを構成要素として含むが、これらに制限されるものではない。

前記記憶部は、プログラムコードを記憶し、前記プログラムコードは、前記処理部７１０が実行することによって、本明細書における上記の例示的な方法についての説明部分に記載された、本開示の様々な実施例に係るステップを前記処理部７１０に実行させるためのものである。例えば、前記処理部７１０は、図５に示す各ステップを実行することができる。

記憶部７２０は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）７２０１および／またはキャッシュメモリ７２０２などの揮発性記憶部のような可読媒体を含んでもよいし、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）７２０３をさらに含んでもよい。

記憶部７２０は、プログラムモジュール７２０５を１組（少なくとも１つ）有するプログラム／ユーティリティツール７２０４をさらに含んでいてもよい。このようなプログラムモジュール７２０５は、オペレーティングシステム、１つまたは複数のアプリケーションプログラム、他のプログラムモジュールおよびプログラムデータを含むが、これらに限定されるものではない。これらの例示のうちのいずれか１つまたは何らかの組み合わせはネットワーク環境の実現を含み得る。

バス７３０は、複数種類のバス構造のうちの１種または複数種類を示すことができ、メモリバスまたはメモリコントローラ、周辺バス、グラフィックス高速化ポート、処理部または複数のバス構造のうちのいずれかを使用するローカルバスを含む。

デジタル証明書発行センター１０３は、１つまたは複数の外部装置９００（例えば、キーボード、ポインティングデバイス、ブルートゥースデバイスなど）と通信してもよいし、ユーザがその記帳ノード２１と対話可能にする１つまたは複数のデバイス、および／または、当該デジタル証明書発行センター１０３が１つまたは複数の他の計算装置と通信可能にする任意のデバイス（例えば、ルータ、モデムなど）と通信してもよい。このような通信は、入出力（I／O）インターフェース７５０を介して行うことができる。また、デジタル証明書発行センター１０３は、ネットワークアダプタ７６０を介して、１つまたは複数のネットワーク（例えば、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）および／または例えばインターネットのような公衆ネットワーク）と通信してもよい。図示されるように、ネットワークアダプタ７６０は、バス７３０を介してデジタル証明書発行センター１０３の他のモジュールと通信する。なお、図示されていないが、他のハードウェアモジュールおよび／またはソフトウェアモジュールを、デジタル証明書発行センター１０３と組み合わせて使用することができる。たとえば、マイクロコード、デバイスドライバ、冗長処理部、外部ディスクドライブアレイ、ＲＡＩＤシステム、テープドライブおよびデータバックアップストレージシステムなどがあるが、これらに限定されるものではない。

当業者であれば、以上の実施例の記載から、ここで述べた実施例がソフトウェアによって実現されてもよいし、必要なハードウェアをソフトウェアと結合することによって実現されてもよいことを容易に理解できろう。そこで、本開示の実施例に係る技術方案は、ソフトウェアプロダクトとして表現されることができ、当該ソフトウェアプロダクトは、１つの不揮発性記憶媒体（ＣＤ－ＲＯＭ、ＵＳＢフラッシュメモリ、モバイルハードディスク等）やネットワークに記憶され、１台の計算装置（パーソナルコンピュータ、サーバ、端末装置、またはネットワーク装置等）に本開示の実施例に係る方法を実行させるための若干の指令を含む。

本開示の実施例では、前記コンピュータのプロセッサによって実行される場合に、上記の方法の実施例に記載された方法をコンピュータに実行させるコンピュータ読取可能な指令を記憶するコンピュータプログラム媒体をさらに提供する。

本開示の一実施例によれば、上記の方法の実施例における方法を実現するためのプログラムプロダクトであって、プログラムコードを含むとともにモバイルコンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）を採用することができ、かつ、例えばパソコンなどの端末装置に動作可能なプログラムプロダクトを提供する。しかし、本開示のプログラムプロダクトは、これに限定されず、本明細書では、可読記憶媒体は、命令実行システム、装置またはデバイスによって使用され、またはそれらと組み合わせて使用されるプログラムを含んだり記憶したりする任意の有形な媒体とすることができる。

前記プログラムプロダクトは、１つまたは複数の可読媒体の任意の組合を採用することができる。可読媒体は、可読信号媒体または可読記憶媒体であってもよい。可読記憶媒体は、例えば電気、磁気、光学、電磁、赤外線、または半導体のシステム、装置またはデバイス、あるいはそれらの任意の組み合わせであってもよいが、これらに限定されない。可読記憶媒体は、更なる具体例として（非網羅的なリスト）、１つまたは複数の導線を有する電気接続、携帯型ディスク、ハードディスク、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＰＲＯＭまたはフラッシュメモリ、光ファイバ、ＣＤ－ＲＯＭ、光学メモリデバイス、磁気メモリデバイス、あるいはこれらの任意の好適な組み合わせを含む。

コンピュータ読み取り可能な信号媒体は、ベースバンドに伝搬され、または搬送波の一部として伝搬され、可読性のプログラムコードが搭載されるデータ信号を含むことができる。このように伝搬されるデータ信号は、電磁気信号、光信号、あるいはこれらの任意の好適な組み合わせなどの多様な形態をとることができるが、これらに限定されるものではない。可読信号媒体は、命令実行システム、装置、またはデバイスにより使用され、またはそれらと組み合わせて使用されるプログラムを送信、伝播または伝送することができる可読記録媒体以外の任意の可読媒体であってもよい。

可読媒体に含まれるプログラムコードは、任意の好適な媒体で伝送することができ、例えば無線、有線、光ケーブル、ＲＦ等、またはそれらの任意の適宜な組み合わせなどがあるが、これらに限定されるものではない。

本開示の動作を実行するプログラムコードは、例えばＪａｖａ、Ｃ＋＋などのようなオブジェクト指向プログラミング言語、Ｃ言語などの通常の手続き型プログラミング言語または類似するプログラミング言語を含む１種または複数種類のプログラミング言語の任意の組み合わせで記述されてもよい。プログラムコードは、全部がユーザの計算装置に実行されたり、一部がユーザ装置に実行されたり、独立した１つのソフトウェアパケットとして実行されたり、一部がユーザの計算装置に実行されるとともに他部がリモート計算装置に実行されたり、全部がリモート計算装置やサーバに実行されたりすることができる。リモート計算装置に関わる場合、リモート計算装置は、ＬＡＮまたはＷＡＮを含む任意の種類のネットワークを介してユーザ計算装置に接続されたり、外部計算装置に接続されたりする（例えば、インターネットのサービスプロバイダーを用いてインターネットを介して接続する）ことができる。

なお、上記の詳細な説明では、動作を実行するための装置のいくつかのモジュールまたはユニットが記載されていたが、このような分割は強制的ではない。実際に、本開示の実施例によれば、以上に説明した２つまたはそれ以上のモジュールまたはユニットの特徴や機能は、１つのモジュールまたはユニットで具現化されてもよい。逆に、以上に説明した１つのモジュールまたはユニットの特徴や機能は、複数のモジュールまたはユニットにより具現化されるようにさらに分けられてもよい。

また、図面には、本開示に係る方法の各ステップを特定の順序で記載したが、これらのステップを当該特定の順序で実行しなければならなく、または、所望の結果を実現できるように全てのステップを実行しなければならないように要求または示唆するものではない。付加または候補として、幾らかのステップを省略したり、複数のステップを１つのステップに合わせて実行したり、および／または１つのステップを複数のステップに分けて実行したりするなどしてもよい。

当業者であれば、以上の実施例の記載から、ここで述べた実施例がソフトウェアによって実現されてもよいし、必要なハードウェアをソフトウェアと結合することによって実現されてもよいことを容易に理解できろう。そこで、本開示の実施例に係る技術方案は、ソフトウェアプロダクトとして表現されることができ、当該ソフトウェアプロダクトは、１つの不揮発性記憶媒体（ＣＤ－ＲＯＭ、ＵＳＢフラッシュメモリ、モバイルハードディスク等）やネットワークに記憶され、１台の計算装置（パーソナルコンピュータ、サーバ、携帯端末、またはネットワーク装置等）に本開示の実施例に係る方法を実行させるための若干の指令を含む。

当業者であれば、明細書およびここに開示した発明の実践を考慮して、本開示の他の実施例を容易に想到することができる。本開示は、本開示の一般的な原理に則し、かつ本開示の開示されていない本技術分野における周知常識または慣用の技術手段を含む任意の変形、用途または適応的変化を含むことを目的とする。なお、明細書および実施例はあくまでも例示に過ぎず、本開示の真正な範囲および精神は特許請求の範囲によって示される。

Claims (16)

1. ブロックチェーンネットワークにおけるノードに対してデジタル証明書を発行する方法であって、前記方法がデジタル証明書発行センターにより実行され、前記デジタル証明書発行センターは公開／秘密鍵生成モジュールと認証モジュールとを含み、
   ブロックチェーンネットワークにおけるノードからの公開／秘密鍵要求に応じて、前記公開／秘密鍵生成モジュールによって、前記ノードに対して前記ノードの公開鍵および秘密鍵を生成して前記ノードに送信するステップと、
   前記認証モジュールによって、前記ノードの公開鍵および登録情報を受信するステップと、
   前記認証モジュールによって前記登録情報を認証するステップと、
   認証に成功すると、前記認証モジュールによって、平文情報と、前記認証モジュールの秘密鍵を用いて前記平文情報に対して形成した署名とを含む、前記ノードのデジタル証明書を生成して前記ノードに送信することによって、前記ノードが前記認証モジュールの公開鍵を用いて前記署名を検証するようにするステップであって、前記平文情報は前記ノードの公開鍵を含む、ステップと、を含む、
   ことを特徴とする方法。
2. 前記デジタル証明書発行センターは、認証ポリシーモジュールをさらに含み、
   前記認証モジュールによって前記登録情報を認証する前記ステップの前に、前記認証モジュールによって、前記ノードに対応する登録情報認証ポリシーを前記認証ポリシーモジュールから取得するステップをさらに含み、
   前記認証モジュールによって前記登録情報を認証する前記ステップは、前記認証モジュールによって、前記ノードに対応する登録情報認証ポリシーに基づいて前記登録情報を認証するステップを含む、
   ことを特徴とする請求項１に記載の方法。
3. 前記デジタル証明書発行センターは、秘密鍵管理モジュールをさらに含み、
   ブロックチェーンネットワークにおけるノードからの公開／秘密鍵要求に応じて、前記公開／秘密鍵生成モジュールによって、前記ノードに対して前記ノードの公開鍵および秘密鍵を生成して前記ノードに送信する前記ステップの後に、前記秘密鍵管理モジュールによって、前記ノードから送信された秘密鍵を受信して保存するステップをさらに含む、
   ことを特徴とする請求項１または２に記載の方法。
4. 前記ノードから送信された秘密鍵を受信する前記ステップは、
   前記ノードが前記秘密鍵管理モジュールの公開鍵を用いて暗号化した第１のランダムセッション鍵を受信するステップと、
   前記暗号化された第１のランダムセッション鍵を、前記秘密鍵管理モジュールの秘密鍵で復号して前記第１のランダムセッション鍵を得るステップと、
   前記ノードが前記第１のランダムセッション鍵を用いて暗号化した前記ノードの秘密鍵を受信するステップと、
   復号して得た第１のランダムセッション鍵を用いて、暗号化された前記ノードの秘密鍵を復号して、前記ノードの秘密鍵を得るステップと、を含む、
   ことを特徴とする請求項３に記載の方法。
5. 前記ノードが前記秘密鍵管理モジュールの公開鍵を用いて暗号化した第１のランダムセッション鍵を受信する前記ステップの前に、
   認証モジュールによって、前記ノードから送信された前記秘密鍵管理モジュールのデジタル証明書取得要求を受信するステップと、
   認証モジュールによって、前記デジタル証明書取得要求に応じて、前記認証モジュールの秘密鍵を用いた署名を含む、前記秘密鍵管理モジュールのデジタル証明書を前記ノードに送信することによって、前記ノードが前記秘密鍵管理モジュールのデジタル証明書を受信した後に、前記認証モジュールの公開鍵を用いて認証を行うようにするステップと、をさらに含む、
   ことを特徴とする請求項４に記載の方法。
6. 前記秘密鍵管理モジュールによって前記ノードから送信された秘密鍵を受信して保存する前記ステップの後に、
   前記秘密鍵管理モジュールによって、前記ノードの秘密鍵クエリー要求を受信するステップと、
   前記秘密鍵管理モジュールによって、前記ノードのデジタル証明書クエリー要求を認証モジュールに送信するステップと、
   前記認証モジュールが前記デジタル証明書クエリー要求に応じて生成したデジタル証明書の認証に成功した旨の応答を受信すると、前記秘密鍵管理モジュールによって、前記秘密鍵クエリー要求に応じて前記ノードの秘密鍵を前記ノードに送信するステップと、をさらに含む、
   ことを特徴とする請求項３～５のいずれか１項に記載の方法。
7. 前記秘密鍵クエリー要求に応じて前記ノードの秘密鍵を前記ノードに送信する前記ステップは、
   前記ノードが前記秘密鍵管理モジュールの公開鍵を用いて暗号化した第２のランダムセッション鍵を受信するステップと、
   前記暗号化された第２のランダムセッション鍵を、前記秘密鍵管理モジュールの秘密鍵で復号して前記第２のランダムセッション鍵を得るステップと、
   前記秘密鍵クエリー要求に応じて前記ノードの秘密鍵をクエリーするステップと、
   前記ノードの秘密鍵を前記第２のランダムセッション鍵で暗号化して前記ノードに送信して、前記ノードが前記第２のランダムセッション鍵を用いて暗号化された前記ノードの秘密鍵を復号して、前記ノードの秘密鍵を得るステップと、を含む、
   ことを特徴とする請求項６に記載の方法。
8. 前記登録情報は、前記ノードの識別子を含み、
   前記デジタル証明書発行センターは、認証データベースを含み、
   前記認証モジュールによって前記ノードのデジタル証明書を生成した後に、
   前記認証モジュールによって、前記ノードの識別子と前記ノードのデジタル証明書とを認証データベースに対応付けて記憶させるステップをさらに含み、
   前記秘密鍵クエリー要求は、前記ノードの識別子を含み、前記デジタル証明書クエリー要求は、前記ノードの識別子を含むことによって、前記認証モジュールは、前記認証データベースに前記識別子と対応付けて記憶されるデジタル証明書があるか否かに基づいて、認証に成功したか否かを確定する、
   ことを特徴とする請求項６または７に記載の方法。
9. 前記ノードは、会社ノードとサービス事業者ノードとを含み、
   前記ノードがサービス事業者ノードである場合、前記ノードの公開鍵および登録情報を受信する前記ステップは、
   前記サービス事業者ノードの公開鍵、登録情報、および前記サービス事業者ノードがサービスを提供している会社の権限情報を受信するステップを含み、
   前記デジタル証明書発行センターが認証ポリシーモジュールをさらに含む場合、前記認証モジュールによって前記登録情報を認証した後に、
   認証に成功すると、前記認証モジュールによって、前記権限情報を前記認証ポリシーモジュールに送信して記憶するステップをさらに含み、
   前記秘密鍵クエリー要求は、前記サービス事業者ノードの識別子と、前記サービス事業者ノードのクエリーしようとする鍵が所属するノードの識別子とを含み、
   前記認証モジュールは、認証ポリシーモジュールに記憶される前記権限情報に基づいて、前記サービス事業者ノードのクエリーしようとする鍵が所属するノードの識別子は、前記サービス事業者ノードがサービスを提供している会社または前記サービス事業者ノードの識別子であると確定した場合、認証に成功する、
   ことを特徴とする請求項６または７に記載の方法。
10. 前記ノードに対応する登録情報認証ポリシーは、ノード種別に特定される登録情報認証ポリシーを含み、
    前記登録情報は、前記ノード種別を含み、
    前記ノードに対応する登録情報認証ポリシーを前記認証ポリシーモジュールから取得する前記ステップは、前記ノード種別に特定される登録情報認証ポリシーを前記認証ポリシーモジュールから取得するステップを含む、
    ことを特徴とする請求項２に記載の方法。
11. ブロックチェーンは、複数のサブブロックチェーンを含み、
    前記登録情報は、ノード種別を含み、
    前記ノードに対して前記ノードの公開鍵および秘密鍵を生成する前記ステップは、前記ノードに対して異なるサブブロックチェーンにおける前記ノードの公開鍵および秘密鍵を生成するステップを含み、
    前記デジタル証明書発行センターが認証ポリシーモジュールをさらに含む場合、認証モジュールによって前記登録情報を認証した後に、
    認証に成功すると、前記認証モジュールによって、前記ノード種別に基づいて前記ノード種別に特定されるサブブロックチェーン権限情報を生成し、前記サブブロックチェーン権限情報を前記認証ポリシーモジュールに記憶するステップをさらに含み、
    前記サブブロックチェーン権限情報は、異なるトラフィック種別ごとにクエリーが許容されるサブブロックチェーンを含み、
    前記秘密鍵クエリー要求は、前記ノード種別とトラフィック種別とを有し、
    前記デジタル証明書クエリー要求は、前記ノード種別とトラフィック種別とを有し、
    前記認証モジュールは、前記ノード種別に特定されたサブブロックチェーン権限情報を前記認証ポリシーモジュールからクエリーし、前記サブブロックチェーン権限情報および当該トラフィック種別に基づいて、クエリーが許容されるサブブロックチェーンを確定し、クエリーが許容されるサブブロックチェーンの識別子をデジタル証明書の認証に成功した旨の応答に入れて、前記秘密鍵管理モジュールに送信し、
    前記ノードの秘密鍵を前記ノードに送信する前記ステップは、クエリーが許容されるサブブロックチェーンにおける前記ノードの秘密鍵を前記ノードに送信するステップを含む、
    ことを特徴とする請求項６に記載の方法。
12. 前記秘密鍵管理モジュールに記憶された秘密鍵は、暗号化によって記憶され、暗号化に用いられる暗号は、前記秘密鍵管理モジュールにハードコーディングされる、
    ことを特徴とする請求項３～９のいずれか１項に記載の方法。
13. デジタル証明書発行センターであって、
    ブロックチェーンネットワークにおけるノードからの公開／秘密鍵要求に応じて、前記ノードに対して前記ノードの公開鍵および秘密鍵を生成して、前記ノードに送信するための公開／秘密鍵生成モジュールと、
    認証モジュールであって、前記ノードの公開鍵および登録情報を受信して、前記登録情報を認証し、かつ、認証に成功すると、平文情報と、前記認証モジュールの秘密鍵を用いて前記平文情報に対して形成した署名とを含む、前記ノードのデジタル証明書を生成して前記ノードに送信することによって、前記ノードが前記認証モジュールの公開鍵を用いて前記署名を検証するようにするための、認証モジュールと、を含み、
    前記平文情報は、前記ノードの公開鍵を含む、
    ことを特徴とするデジタル証明書発行センター。
14. デジタル証明書発行センターであって、
    コンピュータ読み取り可能な指令が記憶されるメモリと、
    メモリに記憶されるコンピュータ読み取り可能な指令を読み取って、請求項１～１２のいずれか１項に記載の方法を実行するプロセッサと、を備える、
    ことを特徴とするデジタル証明書発行センター。
15. コンピュータのプロセッサによって実行される場合、請求項１～１２のいずれか１項に記載の方法をコンピュータに実行させるコンピュータ読み取り可能な指令を記憶するためのコンピュータプログラム記憶媒体。
16. コンピュータで動作することによって、請求項１～１２のいずれか１項に記載の方法をコンピュータに実行させるための指令を含むコンピュータプログラム。

Images