JP6826290B2 - 証明書配付システム、証明書配付方法、および証明書配付プログラム - Google Patents

Description

本発明は、証明書配付システム、証明書配付方法、および証明書配付プログラムに関する。

ネットワークを介してユーザ間で取引を行うとき、通信相手の身元確認が行われる。ユーザの身元確認には、例えば電子証明書が用いられる。電子証明書は、信頼できる第三者により発行される、情報（例えば公開鍵）の所有者を証明する情報である。

電子証明書は、例えばブロックチェーンを使用したシステムでも利用されている。ブロックチェーンは、分散型のコンピュータネットワークにおいて、集中管理装置を置かずに信憑性のある合意に到達することを可能にする技術である。ここで合意とは、分散データベースにおいて、ユーザＡとユーザＢとの間の取引記録の整合性を取ることである。ブロックチェーンにおいて取引に関する情報を記録する場合、他人のなりすましを防ぐために、電子証明書が用いられる。例えば電子証明書によって所有者が証明された公開鍵で暗号化して取引に関するデータを送信すれば、その公開鍵の所有者が保持している秘密鍵を用いなければ、送信されたデータを復号することができない。従って、送信されたデータが、目的の相手に安全に送信される。このようにして、ネットワークを介した取引の安全性が保たれる。

なお、情報通信の安全性を向上させるために、様々な技術が開発されている。例えば、複数のセキュリティモジュール間で、セキュアメモリの使用量を抑えつつ、ツリー構造のカウンタを共有するカウンタの設定方法がある。また、異なるサービスプロバイダエンティティのネットワーク内では、加入者デバイスを使うことができないように保証するために、加入者デバイスを個別化するための方法がある。さらに、認証デバイスの距離に応じて、制御対象装置の操作可否を制御する制御方法もある。

特開２００９−３８５５号公報 特表２０１３−５３１９１０号公報 特開２０１５−８８８０４号公報

従来の技術では、公開鍵などの電子情報の所有者を証明するための電子証明書は、証明書管理用のサーバで集中管理される。そのため、取引を行うユーザは、端末装置を用いて、本人確認のために、適宜、証明書管理用のサーバにアクセスする。

このように、電子証明書がサーバで集中管理されていると、そのサーバに障害が発生した場合、電子証明書を利用した取引が停止してしまう。すなわち、電子証明書をサーバで集中管理していることが、システム全体の可用性（システムが継続して稼働できる能力）の低下を招いている。

１つの側面では、本件は、システムの可用性を向上させることを目的とする。

１つの案では、第１の端末装置、複数の第２の端末装置、および複数のブロックチェーンノードを有する証明書配付システムが提供される。
第１の端末装置は、ブロックチェーンによって複数のブロックを保持するネットワークへ、ユーザが所有する証明対象情報を含む第１ブロックの登録要求を出力する。複数の第２の端末装置は、ネットワークから、証明対象情報を含むブロックを、承認対象ブロックとして取得し、管理者からの入力に応じて、証明対象情報の登録承認を示す電子署名と承認対象ブロックとを含む第２ブロックの登録要求を、ネットワークへ出力する。複数のブロックチェーンノードは、ネットワークに属し、第１または第２ブロックの登録要求に応じて、第１または第２ブロックをブロックチェーンによって分散して保持し、保持した第２ブロックのなかに、包含する電子署名の数が所定数に達した署名数充足ブロックがある場合、証明対象情報の所有者を証明する電子証明書と署名数充足ブロックとを含む第３ブロックを、ブロックチェーンによって分散して保持する。

１態様によれば、システムの可用性が向上する。

第１の実施の形態に係る証明書配付システムの構成例を示す図である。 第２の実施の形態のネットワークシステムの構成の一例を示す図である。 第２の実施の形態に用いる端末装置のハードウェアの一構成例を示す図である。 第２の実施の形態におけるブロックチェーンネットワークの一例を示す図である。 端末装置とブロックチェーンノードとの機能の一例を示すブロック図である。 証明書の発行および無効化のブロックチェーンの一例を示す図である。 公開鍵登録用のブロックの作成例を示す図である。 最初の登録承認時のブロックの作成例を示す図である。 Ｎ番目の登録承認時のブロックの作成例を示す図である。 スマートコントラクトによる公開鍵証明書の作成例を示す図である。 公開鍵破棄時のブロックの作成例を示す図である。 スマートコントラクトによる公開鍵の無効化の例を示す図である。 公開鍵の使用例を示す図である。 公開鍵登録処理の手順の一例を示すシーケンス図である。 登録承認処理の手順の一例を示すシーケンス図である。 公開鍵証明書発行処理の手順の一例を示すシーケンス図である。 公開鍵の破棄処理の手順の一例を示すシーケンス図である。 公開鍵無効化処理の手順の一例を示すシーケンス図である。 公開鍵の使用手順の一例を示すシーケンス図である。 公開鍵登録画面の一例を示す図である。 登録承認画面の一例を示す図である。 公開鍵無効化画面の一例を示す図である。 第３の実施の形態における公開鍵登録用のブロックの作成例を示す図である。 第３の実施の形態における最初の登録承認時のブロックの作成例を示す図である。 第３の実施の形態におけるＮ番目の登録承認時のブロックの作成例を示す図である。 第３の実施の形態における公開鍵破棄時のブロックの作成例を示す図である。 第３の実施の形態におけるスマートコントラクトによる公開鍵の無効化の例を示す図である。 第３の実施の形態における公開鍵登録処理の手順の一例を示すシーケンス図である。 第３の実施の形態における登録承認処理の手順の一例を示すシーケンス図である。 第３の実施の形態における公開鍵証明書発行処理の手順の一例を示すシーケンス図である。 第３の実施の形態における公開鍵の破棄処理の手順の一例を示すシーケンス図である。 第３の実施の形態における公開鍵無効化処理の手順の一例を示すシーケンス図である。 第３の実施の形態における公開鍵使用手順の一例を示すシーケンス図である。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず第１の実施の形態について説明する。

図１は、第１の実施の形態に係る証明書配付システムの構成例を示す図である。第１の実施の形態では、ブロックチェーンによって複数のブロックを保持するネットワーク１が設けられている。ネットワーク１には、複数のブロックチェーンノード３ａ，３ｂ，３ｃが含まれる。複数のブロックチェーンノード３ａ，３ｂ，３ｃは、例えばプロセッサやメモリを有するコンピュータである。またネットワーク１には、複数の端末装置２ａ，２ｂ，２ｃが接続されている。複数の端末装置２ａ，２ｂ，２ｃは、例えばプロセッサやメモリを有するコンピュータである。

複数の端末装置２ａ，２ｂ，２ｃのうち、例えば端末装置２ａは、証明対象情報４ａに対する電子証明書の発行を希望するユーザ８が使用する。証明対象情報４ａは、例えばユーザ８が有する公開鍵である。また端末装置２ｂ，２ｃは、例えばシステムの管理者９ａ，９ｂが使用する。

ここでユーザ８が、証明対象情報４ａの所有者がユーザ８であることの電子証明書の発行を希望するものとする。その場合、ユーザ８は、端末装置２ａに証明対象情報４ａを入力し、端末装置２ａに、証明対象情報４ａのネットワーク１への登録を指示する。すると端末装置２ａは、ユーザ８が所有する証明対象情報４ａを含むブロック４（第１ブロック）を作成する。ブロック４には、例えばユーザ８の電子署名４ｂ（所有者電子署名）が含まれる。電子署名４ｂは、例えば証明対象情報４ａを、ユーザ８の秘密鍵で暗号化したものである。ブロック４に、ユーザ８を一意に特定する識別子を含めてもよい。

端末装置２ａは、作成したブロック４の登録要求を、ネットワーク１内の複数のブロックチェーンノード３ａ，３ｂ，３ｃのうちの１台に送信する。複数のブロックチェーンノード３ａ，３ｂ，３ｃは、ブロック４の登録要求に応じて、ブロック４をブロックチェーンによって分散して保持する。

複数の第２の端末装置２ｂ，２ｃは、ネットワーク１から、証明対象情報４ａを含むブロック４，４−１（第２ブロック）を、承認対象ブロックとして取得する。そして複数の第２の端末装置２ｂ，２ｃは、管理者９ａ，９ｂからの入力に応じて、証明対象情報４ａの登録承認を示す電子署名５ａ，５ｎと承認対象ブロック４，４−１とを含むブロック４−１，４−２を作成する。すなわち承認対象ブロック４，４−１に電子署名５ａ，５ｎを付加したものが、新たなブロック４−１，４−２となる。

例えば管理者９ａ，９ｂは、承認対象ブロック４，４−１に含まれる証明対象情報４ａの所有者がユーザ８であることを、オフラインなどの別の手続きによって確認し、確認できた場合に、登録承認の入力を行う。そして複数の第２の端末装置２ｂ，２ｃは、ブロック４−１，４−２の登録要求を、ネットワーク１へ出力する。複数のブロックチェーンノード３ａ，３ｂ，３ｃは、ブロック４−１，４−２の登録要求に応じて、ブロック４−１，４−２をブロックチェーンによって分散して保持する。

保持したブロック４，４−１，４−２のなかに、包含する電子署名５ａ，５ｎの数が所定数に達した署名数充足ブロックがある場合、そのことを、複数のブロックチェーンノード３ａ，３ｂ，３ｃのうちの１台が検出する。図１の例では、ブロックチェーンノード３ｃが、ブロック４−２が署名数充足ブロックであると検出したものとする。するとブロックチェーンノード３ｃは、証明対象情報４ａの所有者がユーザ８であることを証明する電子証明書６とブロック４−２とを含むブロック４−３（第３ブロック）を作成する。

例えばブロックチェーンノード３ｃは、証明書発行部７を有している。証明書発行部７は、例えばスマートコントラクトである。証明書発行部７は、証明対象情報４ａに対して、証明書発行部７の電子署名６ａ（有効化用電子署名）付与し、電子証明書６とする。なお証明書発行部７の電子署名６ａは、ブロックチェーンノード３ｃの電子署名でもある。そして複数のブロックチェーンノード３ａ，３ｂ，３ｃが、作成されたブロック４−３をブロックチェーンによって分散して保持する。

電子証明書６が付与されたブロック４−３がブロックチェーンによって分散して保持されることで、証明対象情報４ａが有効化される。すなわち、任意のユーザが、自身の使用する端末装置を用いてブロック４−３を参照できる。そしてブロック４−３内に含まれている電子証明書６により、ブロック４−３に含まれている証明対象情報４ａの所有者がユーザ８であることを確認できる。

例えば、証明対象情報４ａを使用するユーザが使用する端末装置（図示せず）は、ブロックチェーンノード３ａ，３ｂ，３ｃから、ブロックチェーンノード３ａ，３ｂ，３ｃ自身の公開鍵（証明書発行部７の公開鍵）を取得する。そして端末装置は、取得した公開鍵により電子証明書６の正当性を検証する。例えば端末装置は、電子証明書６に含まれる電子署名を取得した公開鍵で復号する。端末装置は、復号されたデータと証明対象情報４ａとが一致する場合、電子証明書６が正しいと判断する。端末装置は、正しく検証できた場合、証明対象情報４ａの所有者がユーザ８であると判断する。ブロック４−３にユーザ８の識別子が含まれていれば、証明対象情報４ａの所有者が、その識別子で示されるユーザ８であることが分かる。証明対象情報４ａがユーザ８の公開鍵であれば、例えば証明対象情報４ａを使用するユーザは、ユーザ８の識別子を宛先として送信するデータを、その公開鍵で暗号化することで、データを安全にユーザ８に送信することができる。

このように、電子証明書の発行をブロックチェーンを用いて行うことで、電子証明書の発行が１つのサーバに集中せず、一部のノードが故障しても、電子証明書の発行を継続できる。その結果、電子証明書の発行を安定して継続することができ、システムの可用性が向上する。

しかも、多数の管理者のうちの所定数の管理者が登録承認を行えば、電子証明書が発行されるため、ある承認者が承認できない場合でも他の管理者の承認により、電子証明書が発行できる。そのため、電子証明書の発行手続きが停止することが抑止される。

なお電子証明書６を発行するために要求される管理者の電子署名の数（所定数）は、１以上の任意の数を設定できる。この所定数として、２以上の数を設定することで、複数の管理者が承認することを、電子証明書６の発行条件とすることができる。複数の管理者の登録承認が確認できたときにのみ電子証明書６を発行させることで、管理者の手違いによる誤った電子証明書６の発行を抑止できる。

ユーザ８は、有効化した証明対象情報４ａを、ユーザ８の意思で無効化できる。例えばユーザ８は、端末装置２ａに対して、証明対象情報４ａの破棄を指示する入力を行う。端末装置２ａは、ユーザ８からの、証明対象情報４ａの破棄を指示する入力に応じて、破棄を示すフラグとブロック４−３とを含むブロックの登録要求を、ネットワーク１へ出力する。複数のブロックチェーンノード３ａ，３ｂ，３ｃは、その登録要求に応じて、該当ブロックをブロックチェーンによって分散して保持する。また複数のブロックチェーンノード３ａ，３ｂ，３ｃのうちのいずれか１台が、保持したブロックに破棄を示すフラグが含まれることを検出する。そして検出したブロックチェーンノード３ａ，３ｂ，３ｃは、そのブロックに含まれる情報に対するブロックチェーンノード自身の電子署名（無効化用電子署名）とそのブロックとを含むブロックを生成する。そして複数のブロックチェーンノード３ａ，３ｂ，３ｃが、生成したブロックをブロックチェーンによって分散して保持する。

破棄を示すフラグを含むブロックに、いずれかのブロックチェーンノードが電子署名をすることで、該当ブロックに含まれる証明対象情報４ａは無効となる。このように、証明対象情報４ａを無効化する際には、ユーザ８が、破棄を示すブロックの登録手続きをするだけでよく、管理者の手間をかけずに済む。その結果、証明対象情報４ａを迅速に無効化することができる。

なお、端末装置２ａは、ユーザ８から、証明対象情報４ａの破棄を指示する入力を受け取ったときに生成するブロックに、ブロック４−３内の情報に対するユーザ８の電子署名（所有者電子署名）を含めてもよい。ユーザ８の電子署名は、ブロック４−３内の情報を、ユーザ８の秘密鍵で暗号化したものである。複数のブロックチェーンノード３ａ，３ｂ，３ｃは、登録要求に応じて保持したブロックに破棄を示すフラグが含まれることを検出すると、ユーザ８の公開鍵（所有者公開鍵）を用いて、ユーザ８の電子署名の正当性を検証する。例えば複数のブロックチェーンノード３ａ，３ｂ，３ｃは、ユーザ８の電子署名を、ユーザ８の公開鍵で復号し、復号されたデータとブロック４−３内の情報とを比較し、一致すれば、ユーザ８の電子署名が正当であると判断する。複数のブロックチェーンノード３ａ，３ｂ，３ｃは、ユーザ８の電子署名が正当であることが確認できた場合、そのブロックに含まれる情報に対するブロックチェーンノード自身の電子署名とそのブロックとを含むブロックを生成する。そして複数のブロックチェーンノード３ａ，３ｂ，３ｃが、生成したブロックを、ブロックチェーンによって分散して保持する。

このように、証明対象情報４ａの破棄を示すブロックに、ユーザ８の電子署名を付加し、その電子署名を検証した後に証明対象情報４ａを無効化することで、ユーザ８以外の第三者により証明対象情報４ａが無効化されることを抑止することができる。

〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、ブロックチェーンネットワークにおける電子証明書の発行と管理を、集中管理するサーバを用いずに実現するものである。なお、以下の説明では、電子証明書を、単に証明書と呼ぶこととする。

ブロックチェーンネットワークは、幾つかのノードがダウンしても電子情報を受け渡すことができ、高い可用性が実現されている。しかし、ブロックチェーンネットワークにおいて使用する証明書がサーバで集中管理されていたのでは、そのサーバがダウンするとブロックチェーンネットワークの運用に支障がでる。すなわち証明書管理用のサーバがダウンすると、ブロックチェーンを利用しているユーザの端末装置は、公開鍵の証明書が参照できなくなり、公開鍵を用いたデータの暗号化ができなくなる。

また証明書をサーバで集中管理した場合、ブロックチェーンのノード数が多くなると、証明書管理用のサーバへのアクセスが集中し、処理の遅延が発生しやすくなる。アクセスの集中は、悪意がある者による攻撃でも発生する。証明書管理用のサーバの処理の遅延が、ブロックチェーンを介した取引の遅延を招くこととなる。

しかも証明書管理用のサーバにおいてユーザの証明書は、そのサーバの管理者によるユーザの身元確認などの手続きを経て発行される。このように、特定の管理者の作業が介在するため、管理者のミスにより、不正な証明書が登録される可能性がある。また証明書の発行が集中管理されているため、管理者の作業遅延などが発生すると、なかなか証明書が登録されない可能性がある。

第２の実施の形態は、証明書の発行と管理についてもブロックチェーンを用いて実現することで、証明書の発行と管理を証明書管理用のサーバで集中管理することによる問題点を解決する。

図２は、第２の実施の形態のネットワークシステムの構成の一例を示す図である。第２の実施の形態のネットワークシステムでは、ネットワークスイッチ３１〜３５を介して、複数のブロックチェーンノード２００，２００ａ〜２００ｆが接続されている。ブロックチェーンノード２００，２００ａ〜２００ｆそれぞれは、ブロックチェーンネットワーク上の１ノードとして機能するコンピュータである。またネットワークには、複数の端末装置１００，１００ａ〜１００ｃが接続されている。複数の端末装置１００，１００ａ〜１００ｃは、ネットワークを介した取引を行うユーザ４１，４２、またはネットワークの管理者５１，５２が使用するコンピュータである。

なお第２の実施の形態のネットワークシステムには、ブロックチェーンノード２００，２００ａ〜２００ｆ以外にも、図示していない多数のブロックチェーンノードが接続されている。同様に第２の実施の形態のネットワークシステムには、複数の端末装置１００，１００ａ〜１００ｃ以外にも、図示していない多数の端末装置が接続されている。

図３は、第２の実施の形態に用いる端末装置のハードウェアの一構成例を示す図である。端末装置１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、端末装置１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。

グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、ＣＲＴ（Cathode Ray Tube）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、端末装置１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１０８は、ネットワークスイッチ３１に接続されている。ネットワークインタフェース１０８は、ネットワークスイッチ３１を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

以上のようなハードウェア構成によって、第２の実施の形態における端末装置１００の処理機能を実現することができる。端末装置１００ａ〜１００ｃについても、端末装置１００と同様のハードウェアで実現することができる。ブロックチェーンノード２００，２００ａ〜２００ｆについても、端末装置１００と同様のハードウェアで実現することができる。さらに、第１の実施の形態に示した端末装置２ａ，２ｂ，２ｃやブロックチェーンノード３ａ，３ｂ，３ｃも、図３に示した端末装置１００と同様のハードウェアにより実現することができる。

端末装置１００，１００ａ〜１００ｃまたはブロックチェーンノード２００，２００ａ〜２００ｆは、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。端末装置１００，１００ａ〜１００ｃまたはブロックチェーンノード２００，２００ａ〜２００ｆに実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、端末装置１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。また端末装置１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

第２の実施の形態では、このようなハードウェア構成のシステムを用いて、ブロックチェーンを用いた証明書の発行や管理が行われる。すなわち第２の実施の形態のシステムでは、ビットコインなどの取引を行うブロックチェーンネットワークとは別に、証明書管理用のサーバの代わりとなる新たな証明書格納用のブロックチェーンネットワークが構築されている。

図４は、第２の実施の形態におけるブロックチェーンネットワークの一例を示す図である。第２の実施の形態では、２つのブロックチェーンネットワーク６０，６１が設けられている。ブロックチェーンネットワーク６０は、電子情報の取引に関するブロック６０ａ，６０ｂ保存用のブロックチェーンネットワークである。ブロックチェーンネットワーク６１は、証明書に関するブロック６１ａ，６１ｂ保存用のブロックチェーンネットワークである。

以下、ブロックチェーンネットワーク６０，６１に関する処理を実施するための、端末装置とブロックチェーンノードとの機能について説明する。
図５は、端末装置とブロックチェーンノードとの機能の一例を示すブロック図である。ユーザ４１が使用する端末装置１００は、ＯＳ１１０とＷｅｂブラウザ１２０とを有している。Ｗｅｂブラウザ１２０は、公開鍵の登録要求や参照を行う証明書利用部１２１を有している。証明書利用部１２１が、公開鍵の登録要求の送信処理、公開鍵の破棄要求の送信処理、他のユーザの公開鍵の使用処理などを実行する。

管理者５１が使用する端末装置１００ａは、ＯＳ１１０ａとＷｅｂブラウザ１２０ａとを有している。Ｗｅｂブラウザ１２０ａは、証明書の発行手続きを行う証明書管理部１２２ａを有している。

ブロックチェーンノード２００は、ＯＳ２１０、Ｗｅｂサーバ２２０、およびブロックチェーンサブシステム２３０を有している。ブロックチェーンサブシステム２３０は、２つのブロックチェーンネットワーク６０，６１を介して、ブロックの配布および保持を行う。例えばブロックチェーンサブシステム２３０は、ブロック記憶部２３１を有しており、端末装置１００または他のブロックチェーンノード２００ａから取得したブロックを、ブロック記憶部２３１に格納する。またブロックチェーンサブシステム２３０は、スマートコントラクト２３２を有している。スマートコントラクト２３２は、ブロックチェーンネットワーク６１上での証明書の発行や無効化を行う。

同様にブロックチェーンノード２００ａは、ＯＳ２１０ａ、Ｗｅｂサーバ２２０ａ、およびブロックチェーンサブシステム２３０ａを有している。ブロックチェーンサブシステム２３０ａは、ブロックを保持するためのブロック記憶部２３１ａや、証明書の発行や無効化を行うスマートコントラクト２３２ａを有している。

ブロックチェーン参加者であるユーザ４１は、端末装置１００を用いて、ブロックチェーンネットワーク６０を介して取引を行うと共に、ブロックチェーンネットワーク６１を介して、証明書による本人証明を行う。管理者５１は、端末装置１００ａを用いて、ブロックチェーンネットワーク６０で保持される電子情報の管理や、ブロックチェーンネットワーク６１で保持される証明書の発行および管理を行う。

例えばユーザ４１は、端末装置１００を用いて、リファレンスフラグ「０」（登録）の値と公開鍵とを含むデータを作成し、そのデータに自分の秘密鍵で電子署名を行う。電子署名を行うとは、署名対象のデータまたはそのデータのハッシュ値を、秘密鍵で暗号化することである。以下、電子署名を行うことで生成される暗号化されたデータを、単に「署名」と呼ぶ。そしてユーザ４１は、端末装置１００ａを用いて、署名付きのデータを、ブロックチェーンネットワーク６１上に登録する。この際、秘密鍵は、各参加者が保持しておく。

管理者５１は、端末装置１００ａを用いて、証明書発行前（リファレンスフラグが「０」）のブロックに自分の署名を付与したデータを作成する。そして管理者５１は、端末装置１００ａを用いて、作成したデータを、ブロックチェーンネットワーク６１上に登録する。

ブロックチェーンネットワーク６１上のスマートコントラクト２３２，２３２ａは、規定数以上の数の承認を得たブロックを確認した場合に、そのブロックのリファレンスフラグを「０」より大きい値「１」（有効）に変更する。さらにスマートコントラクト２３２，２３２ａは、そのブロックにスマートコントラクト２３２，２３２ａの署名を付与したブロックを生成する。そしてスマートコントラクト２３２，２３２ａは、生成したブロックを、公開鍵証明書として新たに、ブロックチェーンサブシステム２３０，２３０ａに登録することを要求する。

ユーザ４１に電子情報を送信する他のユーザは、ブロックチェーンネットワーク６１上に登録された、値が「０」より大きいリファレンスフラグの証明書に含まれる公開鍵を、ユーザ４１へ送る情報の暗号化に使用する。

ユーザ４１の公開鍵の証明書の無効化は、ユーザ４１がリファレンスフラグの値を「−１」（無効）にしたデータに電子署名を行い、ブロックチェーンサブシステム２３０に登録を要求する。スマートコントラクト２３２は、このリファレンスフラグの値が「−１」のブロックを読み込み、ユーザ４１自身が登録したかを署名によって検証する。スマートコントラクト２３２は、検証できれば、そのブロックにスマートコントラクト２３２自身の署名を付けて、ブロックチェーンサブシステム２３０に登録する。これにより、管理者５１の手を煩わせずに、証明書を無効化できる。

以下、図６を参照して、証明書の発行、および管理のためのブロックチェーンについて説明する。
図６は、証明書の発行および無効化のブロックチェーンの一例を示す図である。ブロックチェーンの参加者であるユーザ４１は、例えば端末装置１００を用いて、ユーザ４１宛てのデータの暗号化に使用する公開鍵６２ｂと、その公開鍵６２ｂで暗号化されたデータの復号に使用する秘密鍵とを生成する。そして公開鍵６２ｂの所有者であるユーザ４１は、端末装置１００を用いてブロック６２−１を生成し、そのブロック６２−１の登録要求を、ブロックチェーンノード２００に送信する。

ブロック６２−１には、値が「０」のリファレンスフラグ６２ａ、ユーザ４１の公開鍵６２ｂ、公開鍵６２ｂに対する鍵所有者（ユーザ４１）の署名６２ｃが含まれる。このブロック６２−１は、ブロックチェーンネットワーク６１を介して、すべてのブロックチェーンノードに配布される。

そしてブロック６２−１に対して、複数の管理者が、公開鍵６２ｂの承認を示す電子署名を行う。例えば、最初に管理者５１が電子署名を行うことで、１番目の管理者５１の署名６２ｄを付与したブロック６２−２が、ブロックチェーンネットワーク６１上に登録される。このブロック６２−２には、前のブロック６２−１のハッシュ値６２ｅが含まれている。同様に、所定数の管理者が電子署名を行う。図６の例では、Ｎ人（Ｎは１以上の整数）の管理者が電子署名を行うことが、公開鍵６２ｂの証明書の発行条件となっている。

例えば管理者５２がＮ番目の管理者として、登録承認の電子署名を行う。管理者５２が電子署名を行うことで、Ｎ番目の管理者５２の署名６２ｆを含むブロック６２−３が、ブロックチェーンネットワーク６１上に登録される。ブロック６２−３には、Ｎ−１番目の管理者が登録承認を行ったことで生成されたブロックのハッシュ値６２ｇが含まれる。ブロック６２−３では、リファレンスフラグ６２ａの値がまだ「０」のままである。

規定数（Ｎ）の管理者の承認が得られた場合、ブロックチェーンネットワーク６１上のスマートコントラクト２３２ａが、登録されたブロック６２−３のリファレンスフラグ６２ａを「１」（有効）に変更し、リファレンスフラグ６２ａの電子署名を行う。その結果、ブロック６２−４が生成される。ブロック６２−４には、ユーザ４１の署名６２ｃと、登録承認を行った管理者の署名６２ｄ，６２ｆに加え、スマートコントラクトの署名６２ｈが含まれる。またブロック６２−４には、前のブロック６２−３のハッシュ値６２ｉと公開鍵証明書６２ｊが含まれる。公開鍵証明書６２ｊは、公開鍵６２ｂを含んでおり、この公開鍵６２ｂの所有者がユーザ４１であることを示している。

公開鍵証明書６２ｊを含むブロック６２−４によって、公開鍵６２ｂの所有者がユーザ４１であることが証明される。他のユーザは、ブロック６２−４から取得した公開鍵６２ｂを用いてユーザ４１に送信する電子情報を暗号化することで、その電子情報を安全にユーザ４１に渡すことができる。

ユーザ４１は、公開鍵６２ｂを無効化させる場合、ブロック６２−４におけるリファレンスフラグ６２ａの値を「−１」（無効）にしたブロック６２−５を、ブロックチェーンネットワーク６１上に登録する。ブロック６２−５には、ブロック６２−４のハッシュ値６２ｋが含まれている。ブロック６２−５が登録されると、例えばスマートコントラクト２３２ａが電子署名を行う。

なお、第２の実施の形態では、リファレンスフラグ６２ａの値が「１」のブロックで、ブロックチェーンネットワーク６１上のスマートコントラクトの署名があるものだけが、有効でかつ他のユーザから参照可能なブロックである。

以下、ブロックチェーンネットワーク６１上に登録するブロックの作成方法について、図７〜図１３を参照して説明する。
図７は、公開鍵登録用のブロックの作成例を示す図である。ユーザ４１は、例えば端末装置１００に対して公開鍵６２ｂと、その公開鍵６２ｂで暗号化したデータの復号に用いる秘密鍵６２ｍとを入力する。なお秘密鍵６２ｍで暗号化したデータは、公開鍵６２ｂで復号することができる。ユーザ４１は、公開鍵６２ｂの登録指示を、端末装置１００に入力する。

すると端末装置１００は、ユーザ４１の公開鍵６２ｂに対して、秘密鍵６２ｍで電子署名を行う。例えば端末装置１００は、公開鍵６２ｂのハッシュ値を秘密鍵６２ｍで暗号化する。これにより、鍵の所有者であるユーザ４１の署名６２ｃが生成される。端末装置１００は、ユーザ４１の公開鍵６２ｂ、値が「０」のリファレンスフラグ６２ａ、および鍵所有者（ユーザ４１）の署名６２ｃを含む登録ブロック６３を生成する。そして端末装置１００は、ブロックチェーンノード２００に登録ブロック６３を送信し、ブロックチェーンサブシステム２３０に、登録ブロック６３のブロックチェーンネットワーク６１への登録を依頼する。

ブロックチェーンサブシステム２３０は、登録ブロック６３を、図６に示したブロック６２−１としてブロック記憶部２３１に格納すると共に、他のブロックチェーンノードに送信する。

図８は、最初の登録承認時のブロックの作成例を示す図である。管理者５１は、自身の公開鍵７１と、公開鍵７１で暗号化したデータの復号に用いる秘密鍵７２とを有している。なお、秘密鍵７２で暗号化したデータは、公開鍵７１で復号することができる。また、管理者５１が使用する端末装置１００ａに接続されたブロックチェーンノード２００ａのブロックチェーンサブシステム２３０ａは、ブロック記憶部２３１ａ内に、ユーザ４１が登録したブロック６２−１を記憶している。

端末装置１００ａは、管理者５１からの入力に応じて、リファレンスフラグ６２ａの値が「０」のブロック６２−１を、ブロックチェーンサブシステム２３０ａ内のブロック記憶部２３１ａから読み込む。そして端末装置１００ａは、公開鍵６２ｂの登録承認処理を行う。例えば管理者５１は、秘密鍵７２を端末装置１００ａに入力する。端末装置１００ａは、公開鍵６２ｂと、その公開鍵６２ｂの所有者の署名６２ｃとのハッシュ値を算出する。次に端末装置１００ａは、算出したハッシュ値を、１番目の管理者５１の秘密鍵７２で暗号化する。暗号化されたデータが、１番目の管理者５１の署名６２ｄとなる。端末装置１００ａは、値が「０」のリファレンスフラグ６２ａ、公開鍵６２ｂ、鍵所有者の署名６２ｃ、および１番目の管理者５１の署名６２ｄを含む登録ブロック６４を生成する。そして端末装置１００ａは、ブロックチェーンノード２００ａに登録ブロック６４を送信し、ブロックチェーンサブシステム２３０ａに、登録ブロック６４のブロックチェーンネットワーク６１への登録を依頼する。

ブロックチェーンサブシステム２３０ａは、登録ブロック６４に、ブロック６２−１のハッシュ値を追加して、ブロック６２−２を生成する。そしてブロックチェーンサブシステム２３０ａは、ブロック６２−２を、ブロック記憶部２３１ａに格納すると共に、他のブロックチェーンノードに送信する。

以後同様に、他の管理者も、管理者の署名の数がＮ個になるまで、登録承認を行う。
図９は、Ｎ番目の登録承認時のブロックの作成例を示す図である。管理者５２は、自身の公開鍵７３と、公開鍵７３で暗号化したデータの復号に用いる秘密鍵７４とを有している。なお、秘密鍵７４で暗号化したデータは、公開鍵７３で復号することができる。また、管理者５２が使用する端末装置１００ｂに接続されたブロックチェーンノード２００ａのブロックチェーンサブシステム２３０ａは、ブロック記憶部２３１ａ内に、Ｎ−１番目に登録承認を行った管理者が登録したブロック６２−６を記憶している。

このブロック６２−６のリファレンスフラグ６２ａの値は、まだ「０」である。またブロック６２−６には、公開鍵６２ｂ、公開鍵６２ｂの所有者の署名６２ｃ、および既に登録承認を行った各管理者の署名が含まれる。図９の例では、ブロック６２−６には、１番目の管理者の署名６２ｄからＮ−１番目の管理者の署名６２ｎが含まれている。

端末装置１００ｂは、管理者５２からの入力に応じて、リファレンスフラグ６２ａの値が「０」のブロック６２−６を、ブロックチェーンサブシステム２３０ａ内のブロック記憶部２３１ａから読み込む。そして端末装置１００ｂは、公開鍵６２ｂの登録承認処理を行う。例えば管理者５２は、秘密鍵７４を端末装置１００ｂに入力する。端末装置１００ｂは、公開鍵６２ｂ、その公開鍵６２ｂの所有者の署名６２ｃ、および１番目からＮ−１番目の管理者の署名のハッシュ値を算出する。次に端末装置１００ａは、算出したハッシュ値を、Ｎ番目の管理者５２の秘密鍵７４で暗号化する。暗号化されたデータが、Ｎ番目の管理者５２の署名６２ｆとなる。端末装置１００ｂは、値が「０」のリファレンスフラグ６２ａ、公開鍵６２ｂ、鍵所有者の署名６２ｃ、および１番目〜Ｎ番目の各管理者の署名を含む登録ブロック６５を生成する。そして端末装置１００ｂは、ブロックチェーンノード２００ａに登録ブロック６５を送信し、ブロックチェーンサブシステム２３０ａに、登録ブロック６５のブロックチェーンネットワーク６１への登録を依頼する。

ブロックチェーンサブシステム２３０ａは、登録ブロック６５に、ブロック６２−６のハッシュ値を追加して、ブロック６２−３を生成する。そしてブロックチェーンサブシステム２３０ａは、ブロック６２−３を、ブロック記憶部２３１ａに格納すると共に、他のブロックチェーンノードに送信する。

このようにして、規定の人数分の登録承認が完了すると、いずれかのブロックチェーンノードで実行されているスマートコントラクトが公開鍵証明書を発行する。
図１０は、スマートコントラクトによる公開鍵証明書の作成例を示す図である。スマートコントラクト２３２ａは、自身の公開鍵７５と、公開鍵７５で暗号化したデータの復号に用いる秘密鍵７６とを有している。なお、秘密鍵７６で暗号化したデータは、公開鍵７５で復号することができる。また、ブロックチェーンサブシステム２３０ａは、ブロック記憶部２３１ａ内に、Ｎ番目に登録承認を行った管理者が登録したブロック６２−３を記憶している。

このブロック６２−３のリファレンスフラグ６２ａの値は、まだ「０」である。またブロック６２−３には、公開鍵６２ｂ、公開鍵６２ｂの所有者の署名６２ｃ、および既に登録承認を行った各管理者の署名が含まれる。図１０の例では、ブロック６２−３には、１番目の管理者の署名６２ｄからＮ番目の管理者の署名６２ｆが含まれている。

スマートコントラクト２３２ａは、リファレンスフラグ６２ａの値が「０」のブロック６２−３をブロック記憶部２３１ａから読み込む。そしてスマートコントラクト２３２ａは、公開鍵６２ｂについての公開鍵証明書６２ｊを作成する。例えばスマートコントラクト２３２ａは、公開鍵６２ｂのハッシュ値を、スマートコントラクト２３２ａの秘密鍵７６で暗号化する。暗号化されたデータが、スマートコントラクト２３２ａの署名である。スマートコントラクト２３２ａは、署名を公開鍵６２ｂに付与し、公開鍵証明書６２ｊとする。またスマートコントラクト２３２ａは、リファレンスフラグ６２ａの値を、有効を表す値「１」に変更する。そしてスマートコントラクト２３２ａは、値が「１」のリファレンスフラグ６２ａ、公開鍵６２ｂ、鍵所有者の署名６２ｃ、１番目〜Ｎ番目の各管理者の署名、および公開鍵証明書６２ｊを含む登録ブロック６６を生成する。そしてスマートコントラクト２３２ａは、ブロックチェーンサブシステム２３０ａに登録ブロック６６のブロックチェーンネットワーク６１への登録を依頼する。

ブロックチェーンサブシステム２３０ａは、登録ブロック６６に、ブロック６２−３のハッシュ値を追加して、ブロック６２−４を生成する。そしてブロックチェーンサブシステム２３０ａは、ブロック６２−４を、ブロック記憶部２３１ａに格納すると共に、他のブロックチェーンノードに送信する。

このようにしてユーザ４１が登録した公開鍵６２ｂに関する公開鍵証明書６２ｊが発行され、他のユーザが公開鍵６２ｂを安心して使用できるようになる。使用可能となった公開鍵６２ｂは、ユーザ４１の意思で破棄することができる。

図１１は、公開鍵破棄時のブロックの作成例を示す図である。ユーザ４１は、公開鍵６２ｂの破棄指示を、端末装置１００に入力する。すると端末装置１００は、ブロックチェーンサブシステム２３０からブロック６２−４を読み込む。次に端末装置１００は、公開鍵６２ｂ、鍵所有者の署名６２ｃ、各管理者の署名６２ｄ，・・・，６２ｆ、および公開鍵証明書６２ｊのハッシュ値を秘密鍵６２ｍで暗号化する。これにより、鍵の所有者であるユーザ４１の署名６２ｎが生成される。また端末装置１００は、リファレンスフラグ６２ａの値を、無効であることを示す値「−１」に変更する。さらに端末装置１００は、ユーザ４１の公開鍵６２ｂ、値が「−１」のリファレンスフラグ６２ａ、鍵所有者の署名６２ｃ、各管理者の署名６２ｄ，・・・，６２ｆ、公開鍵証明書６２ｊ、および追加された鍵所有者の署名６２ｎを含む登録ブロック６７を生成する。そして端末装置１００は、ブロックチェーンノード２００に登録ブロック６７を送信し、ブロックチェーンサブシステム２３０に、登録ブロック６７のブロックチェーンネットワーク６１への登録を依頼する。

ブロックチェーンサブシステム２３０は、ブロック６２−４のハッシュ値を登録ブロック６７に追加して、ブロック６２−５を作成する。そしてブロックチェーンサブシステム２３０は、ブロック６２−５をブロック記憶部２３１に格納すると共に、他のブロックチェーンノードに送信する。

ユーザ４１の公開鍵６２ｂの破棄を示すブロック６２−５がブロックチェーンネットワーク６１に登録されると、いずれかのブロックチェーンノードで実行されているスマートコントラクトにより、公開鍵６２ｂの無効化処理が行われる。

図１２は、スマートコントラクトによる公開鍵の無効化の例を示す図である。スマートコントラクト２３２は、自身の公開鍵７７と、公開鍵７７で暗号化したデータの復号に用いる秘密鍵７８とを有している。なお、秘密鍵７８で暗号化したデータは、公開鍵７７で復号することができる。また、ブロックチェーンサブシステム２３０は、ブロック記憶部２３１内に、破棄の処理が行われたブロック６２−５を記憶している。

このブロック６２−５のリファレンスフラグ６２ａの値は「−１」である。またブロック６２−５には、公開鍵６２ｂ、公開鍵６２ｂの所有者の署名６２ｃ、既に登録承認を行った各管理者の署名、公開鍵証明書６２ｊ、および破棄の処理で追加された公開鍵６２ｂの所有者の署名６２ｎが含まれる。

スマートコントラクト２３２は、リファレンスフラグ６２ａの値が「−１」のブロック６２−５をブロック記憶部２３１から読み込む。そしてスマートコントラクト２３２は、ブロック６２−５に含まれるすべての署名（公開鍵証明書６２ｊを含む）とリファレンスフラグ６２ａとのハッシュ値を、スマートコントラクト２３２の秘密鍵７８で暗号化する。暗号化されたデータが、スマートコントラクト２３２の署名６２ｏである。スマートコントラクト２３２は、ブロック６２−５に含まれていた情報に署名６２ｏを追加した登録ブロック６８を生成する。そしてスマートコントラクト２３２は、ブロックチェーンサブシステム２３０に登録ブロック６８のブロックチェーンネットワーク６１への登録を依頼する。

ブロックチェーンサブシステム２３０は、登録ブロック６８に、ブロック６２−５のハッシュ値を追加して、ブロック６２−８を生成する。そしてブロックチェーンサブシステム２３０は、ブロック６２−８を、ブロック記憶部２３１に格納すると共に、他のブロックチェーンノードに送信する。

ブロックチェーンネットワーク６１では、関連する複数のブロックのうち、最後に更新されたブロックのみが有効となる。そのため、ブロック６２−８が登録されたことにより、ブロック６２−４は使用不能となる。またブロック６２−８には、公開鍵６２ｂが無効であることを示すリファレンスフラグ６２ａ「−１」が設定されている。その結果、以後の公開鍵６２ｂの使用が抑止される。

なお無効化される前であれば、ユーザ４１以外のユーザは、ブロック６２−４を参照して、ユーザ４１の公開鍵６２ｂを利用することができる。
図１３は、公開鍵の使用例を示す図である。ユーザ４２が端末装置１００ｃに対して、ユーザ４１の公開鍵６２ｂの取得を指示する。すると端末装置１００ｃは、ブロックチェーンノード２００ｃのブロックチェーンサブシステム２３０ｃ内のブロック記憶部２３１ｃから、ブロック６２−４を読み込む。また端末装置１００ｃは、ブロックチェーンサブシステム２３０ｃ内のブロック記憶部２３１ｃから、スマートコントラクト２３２ａの公開鍵７５を含むブロック６２−７を読み込む。ブロック６２−７には、例えば公開鍵７５についての公開鍵証明書が含まれる。その公開鍵７５は、例えば、端末装置１００ｃが既に有している鍵によって検証できるものとする。

端末装置１００ｃは、スマートコントラクト２３２ａの公開鍵７５を用いて、公開鍵証明書６２ｊの検証を行う。例えば端末装置１００ｃは、公開鍵証明書６２ｊに含まれるスマートコントラクト２３２ａの署名を、スマートコントラクト２３２ａの公開鍵７５で復号する。次に端末装置１００ｃは、復号されたデータと、ブロック６２−４に含まれている公開鍵６２ｂのハッシュ値とを比較する。復号されたデータと公開鍵６２ｂのハッシュ値とが一致した場合、公開鍵６２ｂの所有者がユーザ４１であることが確認される。

公開鍵６２ｂの所有者がユーザ４１であることが確認できた場合、端末装置１００ｃは、ユーザ４２の指示に従って、公開鍵６２ｂを使用して、ユーザ４１に渡す電子情報を暗号化する。端末装置１００ｃは、暗号化した電子情報を含む登録ブロックを生成し、そのブロックのブロックチェーンネットワーク６０への登録要求を、ブロックチェーンサブシステム２３０ｃに送信する。

以下、図１４〜図１９を参照して、証明書の発行、および管理処理の手順について、詳細に説明する。
図１４は、公開鍵登録処理の手順の一例を示すシーケンス図である。端末装置１００は、ユーザ４１によって指定された場所から、公開鍵ファイルを取得する（ステップＳ１０１）。公開鍵ファイルには、ユーザ４１の公開鍵６２ｂが含まれる。次に端末装置１００は、公開鍵ファイルと、値が「０」のリファレンスフラグ６２ａを生成する（ステップＳ１０２）。次に端末装置１００は、ユーザ４１の公開鍵６２ｂのハッシュ値に、ユーザ４１の秘密鍵６２ｍで電子署名をする（ステップＳ１０３）。そして端末装置１００は、登録ブロック６３を作成し、登録ブロック６３の登録要求を、ブロックチェーンノード２００に送信する（ステップＳ１０４）。

ブロックチェーンノード２００は、受信した登録ブロック６３を、ブロックチェーンネットワーク６１上のブロック６２−１（図６参照）として記憶する（ステップＳ１０５）。またブロックチェーンノード２００は、ブロック６２−１を、他のブロックチェーンノードに配布する（ステップＳ１０６）。

図１５は、登録承認処理の手順の一例を示すシーケンス図である。管理者５１が使用する端末装置１００ａは、リファレンスフラグ６２ａの値が「０」のブロックの取得要求を、ブロックチェーンノード２００ａに送信する（ステップＳ１１１）。ブロックの取得要求に応じて、ブロックチェーンノード２００ａは、登録されているブロックのうち、リファレンスフラグ６２ａの値が「０」のブロック６２−１を、端末装置１００ａに送信する（ステップＳ１１２）。

ブロックを取得した端末装置１００ａは、管理者５１の秘密鍵７２で、ユーザ４１の公開鍵６２ｂと署名６２ｃとのハッシュ値に電子署名を行う（ステップＳ１１３）。このとき、リファレンスフラグ６２ａの値は「０」のままである。端末装置１００ａは、取得したブロック６２−１に、管理者５１の署名６２ｄを追加した登録ブロック６４の登録要求を、ブロックチェーンノード２００ａに送信する（ステップＳ１１４）。

ブロックチェーンノード２００ａは、受信した登録ブロック６４にブロック６２−１のハッシュ値を追加し、ブロックチェーンネットワーク６１上のブロック６２−２（図６参照）として記憶する（ステップＳ１１５）。またブロックチェーンノード２００ａは、ブロック６２−２を、他のブロックチェーンノードに配布する（ステップＳ１１６）。

このような登録承認が、Ｎ人の管理者によって行われると、公開鍵６２ｂを有効化するための公開鍵証明書の発行処理が行われる。
図１６は、公開鍵証明書発行処理の手順の一例を示すシーケンス図である。なお、公開鍵証明書発行処理は、ブロックチェーンノード２００ａの内部処理であるため、図１６では、ブロックチェーンノード２００ａ内の各要素の処理をシーケンス図で表している。

スマートコントラクト２３２ａは、ブロックチェーンサブシステム２３０ａに登録されているブロックのうち、公開鍵６２ｂの登録要求に関するブロックの承認状況を監視する（ステップＳ１２１）。例えばスマートコントラクト２３２ａは、ブロックチェーンサブシステム２３０ａに対して、管理者の署名がＮ個以上となった未承認（リファレンスフラグ６２ａの値が「０」）のブロック６２−３を要求する。ブロックチェーンサブシステム２３０ａは、管理者の署名がＮ個以上となった未承認のブロック６２−３を検出すると、そのブロック６２−３をスマートコントラクト２３２ａに送信する（ステップＳ１２２）。

スマートコントラクト２３２ａは、管理者の署名がＮ個以上となった未承認のブロック６２−３を取得できたか否かを判断する（ステップＳ１２３）。該当ブロック６２−３が取得できない場合、スマートコントラクト２３２ａは、ブロックの承認状況の監視を続ける。該当ブロック６２−３が取得できた場合、スマートコントラクト２３２ａは、取得したブロックのリファレンスフラグ６２ａの値を「１」に変更する（ステップＳ１２４）。次にスマートコントラクト２３２ａは、取得したブロック６２−３に含まれる公開鍵６２ｂのハッシュ値にスマートコントラクト２３２ａの秘密鍵７６で署名した公開鍵証明書６２ｊを作成する（ステップＳ１２５）。そしてスマートコントラクト２３２ａは、取得したブロック６２−３に公開鍵証明書６２ｊを含めた登録ブロック６６の登録要求を、ブロックチェーンサブシステム２３０ａに送信する（ステップＳ１２６）。

ブロックチェーンサブシステム２３０ａは、受信した登録ブロック６６にブロック６２−３のハッシュ値を追加し、ブロックチェーンネットワーク６１上のブロック６２−４（図６参照）として記憶する（ステップＳ１２７）。またブロックチェーンサブシステム２３０ａは、ブロック６２−４を、他のブロックチェーンノードに配布する（ステップＳ１２８）。

公開鍵証明書６２ｊが発行されることで、公開鍵６２ｂは有効化される。公開鍵６２ｂは所有者であるユーザ４１からの指示で破棄される。
図１７は、公開鍵の破棄処理の手順の一例を示すシーケンス図である。端末装置１００は、ユーザ４１から公開鍵６２ｂの破棄の指示が入力されると、ブロックチェーンノード２００に、リファレンスフラグ６２ａの値が「１」のブロック６２−４の取得要求を送信する（ステップＳ１３１）。ブロックチェーンノード２００は、取得要求に応じて、リファレンスフラグ６２ａの値が「１」のブロック６２−４を、端末装置１００に送信する（ステップＳ１３２）。

ブロック６２−４を取得した端末装置１００は、リファレンスフラグ６２ａの値を「−１」（無効）に更新する（ステップＳ１３３）。次に端末装置１００は、取得したブロック６２−４に含まれる公開鍵６２ｂ、各種署名、および公開鍵証明書６２ｊのハッシュ値を計算し、そのハッシュ値にユーザ４１の秘密鍵６２ｍで電子署名を行う（ステップＳ１３４）。そして端末装置１００は、取得したブロック６２−４に、新たに生成した署名６２ｎを追加した登録ブロック６７の登録要求を、ブロックチェーンノード２００に送信する（ステップＳ１３５）。

ブロックチェーンノード２００は、受信した登録ブロック６７にブロック６２−４のハッシュ値を追加し、ブロックチェーンネットワーク６１上のブロック６２−５（図６参照）として記憶する（ステップＳ１３６）。またブロックチェーンノード２００は、ブロック６２−５を、他のブロックチェーンノードに配布する（ステップＳ１３７）。

公開鍵６２ｂの破棄処理が行われると、ブロックチェーンネットワーク６１上で、公開鍵６２ｂが無効化される。
図１８は、公開鍵無効化処理の手順の一例を示すシーケンス図である。なお、公開鍵無効化処理は、ブロックチェーンノード２００の内部処理であるため、図１８では、ブロックチェーンノード２００内の各要素の処理をシーケンス図で表している。

スマートコントラクト２３２は、ブロックチェーンサブシステム２３０に登録されているブロックのうち、破棄された公開鍵６２ｂに関するブロックの有無を監視する（ステップＳ１４１）。例えばスマートコントラクト２３２は、ブロックチェーンサブシステム２３０に対して、リファレンスフラグ６２ａの値が「−１」のブロック６２−５を要求する。ブロックチェーンサブシステム２３０は、該当するブロック６２−５を検出すると、そのブロック６２−５をスマートコントラクト２３２に送信する（ステップＳ１４２）。

スマートコントラクト２３２は、リファレンスフラグ６２ａの値が「−１」（無効）のブロック６２−５を取得できたか否かを判断する（ステップＳ１４３）。該当ブロック６２−５が取得できない場合、スマートコントラクト２３２は、破棄ブロックの監視を続ける。該当ブロック６２−５が取得できた場合、破棄時にユーザ４１が追加した署名６２ｎを検証する（ステップＳ１４４）。例えばスマートコントラクト２３２は、署名６２ｎを、ユーザ４１の公開鍵６２ｂで復号した結果と、署名に用いられたデータのハッシュ値とを比較し、一致していれば、ユーザ４１の正しい署名であると判断する。

署名が正しければ、スマートコントラクト２３２は、ブロック６２−５に含まれるすべての署名（公開鍵証明書６２ｊを含む）とリファレンスフラグ６２ａとのハッシュ値に、スマートコントラクト２３２の秘密鍵７８で電子署名をする（ステップＳ１４５）。そしてスマートコントラクト２３２は、取得したブロック６２−５に、スマートコントラクト２３２による新たな署名６２ｏを含めた登録ブロック６８の登録要求を、ブロックチェーンサブシステム２３０に送信する（ステップＳ１４６）。

ブロックチェーンサブシステム２３０は、受信した登録ブロック６８にブロック６２−５のハッシュ値を追加し、ブロックチェーンネットワーク６１上のブロック６２−８として記憶する（ステップＳ１４７）。またブロックチェーンサブシステム２３０は、ブロック６２−８を、他のブロックチェーンノードに配布する（ステップＳ１４８）。

このようにして、ユーザ４１が破棄を指示した公開鍵６２ｂが無効化される。
次に、他のユーザ４１による有効な公開鍵６２ｂの使用手順について説明する。
図１９は、公開鍵の使用手順の一例を示すシーケンス図である。公開鍵６２ｂの使用者であるユーザ４２は、端末装置１００ｃに対して、例えばユーザ４１の公開鍵６２ｂを使用したデータの暗号化を指示する。すると端末装置１００ｃは、公開鍵証明書を含むユーザ４１の最新ブロックの取得要求を、ブロックチェーンノード２００ｃに送信する（ステップＳ１５１）。ブロックチェーンノード２００ｃは、ユーザ４１の公開鍵６２ｂを含む最新のブロックを、端末装置１００ｃに送信する（ステップＳ１５２）。

ブロックを取得した端末装置１００ｃは、取得したブロックに示されているリファレンスフラグ６２ａの値が「０」より大きいか否かを判断する（ステップＳ１５３）。端末装置１００ｃは、リファレンスフラグ６２ａの値が「０」より大きければ、処理をステップＳ１５４に進める。また端末装置１００ｃは、リファレンスフラグ６２ａの値が「０」以下であれば、処理をステップＳ１５７に進める。

端末装置１００ｃは、ハッシュ値の比較により、取得したブロックに含まれる公開鍵証明書に付与されているスマートコントラクト２３２ａの署名を検証する（ステップＳ１５４）。例えば端末装置１００ｃは、ブロックチェーンネットワーク６１を介してスマートコントラクト２３２ａの公開鍵６２ｂを取得し、その公開鍵６２ｂで署名を復号する。端末装置１００ｃは、復号されたデータと、公開鍵６２ｂのハッシュ値とを比較し、一致すれば、正しい署名であると判断する。

端末装置１００は、スマートコントラクト２３２ａの署名が正しく検証できたか否かを判断する（ステップＳ１５５）。端末装置１００ｃは、正しく検証できた場合、処理をステップＳ１５６に進める。また端末装置１００ｃは、正しく検証できなかった場合、処理をステップＳ１５７に進める。

正しく検証できた場合、端末装置１００ｃは、公開鍵６２ｂを使用して、ユーザ４１に送信するデータの暗号化などの処理を行う（ステップＳ１５６）。また端末装置１００ｃは、リファレンスフラグ６２ａが「０」以下であるか、スマートコントラクト２３２ａの公開鍵６２ｂの正当性が確認できない場合、ユーザ４１の公開鍵６２ｂが使用できない旨のメッセージを出力する（ステップＳ１５７）。

このようにして、スマートコントラクト２３２ａの署名によって正当性が担保されている場合に限り、公開鍵６２ｂを使用することができる。
次に、第２の実施の形態に係る処理をブロックチェーンシステムに実行させるためのユーザインタフェースについて、図２０〜図２２を参照して説明する。

図２０は、公開鍵登録画面の一例を示す図である。ユーザ４１が使用する端末装置１００が、公開鍵登録画面８１を表示する。公開鍵登録画面８１には、公開鍵ファイル指定用のテキストボックス８１ａ、ファイル選択用のボタン８１ｂ、ＯＫボタン８１ｃ、およびキャンセルボタン８１ｄが含まれている。公開鍵６２ｂを登録するユーザ４１は、例えばテキストボックス８１ａに、公開鍵６２ｂを含むファイルの名称を入力する。またユーザ４１は、ボタン８１ｂを選択することで、端末装置１００内のファイルのリストを画面表示させることができる。ユーザ４１は、表示されたファイルのリストの中から、公開鍵６２ｂを含むファイルを選択する。すると選択されたファイルのファイル名が、テキストボックス８１ａに設定される。

ユーザ４１がＯＫボタン８１ｃを押下すると、端末装置１００は、テキストボックス８１ａに示されているファイル内の公開鍵６２ｂを含むブロックの登録要求を、ブロックチェーンノード２００に送信する。またユーザ４１がキャンセルボタン８１ｄを押下すると、端末装置１００は、ブロックの登録要求を送信せずに、公開鍵登録画面８１を閉じる。

図２１は、登録承認画面の一例を示す図である。管理者５１が使用する端末装置１００ａが、登録承認画面８２を表示する。登録承認画面８２には、公開鍵表示部８２ａ、管理者数表示部８２ｂ、既承認人数表示部８２ｃ、署名ファイル指定用のテキストボックス８２ｄ、署名ファイル選択用のボタン８２ｅ、承認ボタン８２ｆ、およびキャンセルボタン８２ｇが含まれる。

公開鍵表示部８２ａには、ユーザ４１の公開鍵６２ｂが表示される。管理者数表示部８２ｂには、登録承認を行うことができる管理者の人数が表示される。既承認人数表示部８２ｃには、既に登録承認を行った管理者の人数が表示される。

公開鍵６２ｂを承認する管理者５１は、例えばテキストボックス８２ｄに、管理者５１の秘密鍵を含むファイルの名称を入力する。また管理者５１は、ボタン８２ｅを選択することで、端末装置１００ａ内のファイルのリストを画面表示させることができる。管理者５１は、表示されたファイルのリストの中から、秘密鍵を含むファイルを選択する。すると選択されたファイルのファイル名が、テキストボックス８２ｄに設定される。

管理者５１が承認ボタン８２ｆを押下すると、端末装置１００ａは、管理者５１の署名を含む登録ブロックの登録要求を、ブロックチェーンノード２００ａに送信する。登録承認が正常に終了すると、例えば端末装置１００ａの画面に、登録承認結果画面８３が表示される。登録承認結果画面８３には、例えば登録承認を行った管理者の人数が表示される。また登録承認結果画面８３には、求められている人数の管理者が登録承認を行い、公開鍵６２ｂが有効化された場合、公開鍵６２ｂの有効化を示すメッセージが表示される。管理者５１がＯＫボタン８３ａを押下すると、端末装置１００ａは、登録承認結果画面８３を閉じる。

また管理者５１がキャンセルボタン８２ｇを押下すると、端末装置１００ａは、ブロックの登録要求を送信せずに、登録承認画面８２を閉じる。
図２２は、公開鍵無効化画面の一例を示す図である。ユーザ４１が使用する端末装置１００が、公開鍵無効化画面８４を表示する。公開鍵無効化画面８４には、公開鍵ファイル指定用のテキストボックス８４ａ、ファイル選択用のボタン８４ｂ、ＯＫボタン８４ｃ、およびキャンセルボタン８４ｄが含まれている。公開鍵６２ｂを無効化するユーザ４１は、例えばテキストボックス８４ａに、公開鍵６２ｂを含むファイルの名称を入力する。またユーザ４１は、ボタン８４ｂを選択することで、端末装置１００内のファイルのリストを画面表示させることができる。ユーザ４１は、表示されたファイルのリストの中から、公開鍵６２ｂを含むファイルを選択する。すると選択されたファイルのファイル名が、テキストボックス８４ａに設定される。

ユーザ４１がＯＫボタン８４ｃを押下すると、端末装置１００は、テキストボックス８４ａに示されているファイル内の公開鍵６２ｂの破棄を示すブロック（リファレンスフラグ６２ａの値が「−１」）の登録要求を、ブロックチェーンノード２００に送信する。またユーザ４１がキャンセルボタン８４ｄを押下すると、端末装置１００は、ブロックの登録要求を送信せずに、公開鍵無効化画面８４を閉じる。

無効化が正常に終了すると、例えば端末装置１００の画面に、無効化結果画面８５が表示される。無効化結果画面８５には、公開鍵表示部８５ａに、無効化された公開鍵６２ｂが表示される。ユーザ４１がＯＫボタン８５ｂを押下すると、端末装置１００は、無効化結果画面８５を閉じる。

以上のようにして、ブロックチェーンネットワーク６１を用いて公開鍵証明書の発行および管理を行うことができる。その結果、証明書管理サーバで公開鍵証明書の発行や管理を行う場合に比べ、可用性が向上する。すなわち第２の実施の形態では、公開鍵６２ｂの発行や管理処理が集中化してしまうことがなく、特定のサーバのダウンにより、公開鍵証明書が発行できなくなったり、公開鍵６２ｂが参照できなくなったりすることが抑止される。

しかも、第２の実施の形態では、複数の管理者の多数決で承認を行うため、登録ミスを防止できる。さらに、複数の管理者で承認を行うため、ある承認者が公開鍵６２ｂを承認できない場合でも他の管理者がその公開鍵６２ｂを承認することができる。その結果、公開鍵証明書が発行されるまでの時間を短縮できる。

さらに第２の実施の形態では、公開鍵６２ｂを管理するブロックにリファレンスフラグ６２ａを設け、リファレンスフラグ６２ａによって登録・有効・無効の各状態を管理している。これにより、例えば公開鍵６２ｂを無効化する場合、ユーザ４１自身が、公開鍵６２ｂの破棄を示すブロックを登録するだけでよい、管理者の手間をかけずに済むとともに、無効化を迅速に行うことができる。

〔第３の実施の形態〕
次に、第３の実施の形態について説明する。第３の実施の形態は、電子署名をする際に、署名の対象のハッシュ値を計算せず、直接署名を付与するものである。ハッシュ値の計算を省略することで、処理の効率化が可能となる。以下、図２３〜図３１を参照し、第３の実施の形態における第２の実施の形態との相違点を説明する。

図２３は、第３の実施の形態における公開鍵登録用のブロックの作成例を示す図である。第３の実施の形態では、端末装置１００は、公開鍵６２ｂを、ユーザ４１の秘密鍵６２ｍで暗号化する。そして公開鍵６２ｂを直接暗号化したデータが、ユーザ４１の署名６２ｃ−１となる。

図２４は、第３の実施の形態における最初の登録承認時のブロックの作成例を示す図である。第３の実施の形態では、端末装置１００ａは、公開鍵６２ｂと、その公開鍵６２ｂの所有者の署名６２ｃ−１とを、管理者５１の秘密鍵７２で暗号化する。暗号化したデータが、管理者５１の署名６２ｄ−１となる。

図２５は、第３の実施の形態におけるＮ番目の登録承認時のブロックの作成例を示す図である。端末装置１００ｂは、公開鍵６２ｂ、その公開鍵６２ｂの所有者の署名６２ｃ−１、および１番目からＮ−１番目の管理者の署名６２ｄ−１，・・・，６２ｎ−１を、管理者５２の秘密鍵７４で暗号化する。暗号化したデータが、管理者５２の署名６２ｆ−１となる。

図２６は、第３の実施の形態における公開鍵破棄時のブロックの作成例を示す図である。端末装置１００は、公開鍵６２ｂ、その公開鍵６２ｂの所有者の署名６２ｃ−１、および１番目からＮ番目の管理者の署名６２ｄ−１，・・・，６２ｆ−１を、ユーザ４１の秘密鍵６２ｍで暗号化する。暗号化したデータが、ユーザ４１の署名６２ｎ−１となる。

図２７は、第３の実施の形態におけるスマートコントラクトによる公開鍵の無効化の例を示す図である。スマートコントラクト２３２は、ブロック６２−５に含まれるすべての署名（公開鍵証明書６２ｊを含む）と、値が「−１」のリファレンスフラグ６２ａとを、スマートコントラクト２３２の秘密鍵７８で暗号化する。暗号化されたデータが、スマートコントラクト２３２の署名６２ｏ−１である。

図２８は、第３の実施の形態における公開鍵登録処理の手順の一例を示すシーケンス図である。図２８に示す処理のうち、第２の実施の形態（図１４参照）と相違するのは、ステップＳ１０３ａの処理である。第３の実施の形態では、ステップＳ１０３ａにおいて、端末装置１００は、ハッシュ値を計算せずに、ユーザ４１の公開鍵６２ｂに、ユーザ４１の秘密鍵６２ｍで電子署名をする。

図２９は、第３の実施の形態における登録承認処理の手順の一例を示すシーケンス図である。図２９に示す処理のうち、第２の実施の形態（図１５参照）と相違するのは、ステップＳ１１３ａの処理である。第３の実施の形態では、ステップＳ１１３ａにおいて、端末装置１００ａは、ハッシュ値を計算せずに、ユーザ４１の公開鍵６２ｂと署名とに、管理者５１の秘密鍵７２で電子署名をする。

図３０は、第３の実施の形態における公開鍵証明書発行処理の手順の一例を示すシーケンス図である。図３０に示す処理のうち、第２の実施の形態（図１６参照）と相違するのは、ステップＳ１２５ａの処理である。第３の実施の形態では、ステップＳ１２５ａにおいて、スマートコントラクト２３２ａは、ハッシュ値を計算せずに、ユーザ４１の公開鍵６２ｂにスマートコントラクト２３２ａの秘密鍵７６で署名した公開鍵証明書６２ｊを作成する。

図３１は、第３の実施の形態における公開鍵の破棄処理の手順の一例を示すシーケンス図である。図３１に示す処理のうち、第２の実施の形態（図１７参照）と相違するのは、ステップＳ１３４ａの処理である。第３の実施の形態では、ステップＳ１３４ａにおいて、端末装置１００は、ハッシュ値を計算せずに、公開鍵６２ｂ、各種署名、および公開鍵証明書６２ｊに、ユーザ４１の秘密鍵６２ｍで電子署名をする。

図３２は、第３の実施の形態における公開鍵無効化処理の手順の一例を示すシーケンス図である。図３２に示す処理のうち、第２の実施の形態（図１８参照）と相違するのは、ステップＳ１４５ａの処理である。第３の実施の形態では、ステップＳ１４５ａにおいて、スマートコントラクト２３２は、ハッシュ値を計算せずに、すべての署名（公開鍵証明書６２ｊを含む）とリファレンスフラグ６２ａに、スマートコントラクト２３２の秘密鍵７８で電子署名をする。

図３３は、第３の実施の形態における公開鍵使用手順の一例を示すシーケンス図である。図３３に示す処理のうち、第２の実施の形態（図１９参照）と相違するのは、ステップＳ１５４ａの処理である。第３の実施の形態では、ステップＳ１５４ａにおいて、端末装置１００ｃは、ハッシュ値ではなく、ユーザ４１の公開鍵６２ｂの比較により、スマートコントラクト２３２ａの署名を検証する。

このように第３の実施の形態では、ハッシュ値の計算を省略しているため、処理を効率的に行うことができる。
〔その他の実施の形態〕
第２、第３の実施の形態では、ブロックチェーンネットワーク６０を用いた取引に使用する公開鍵証明書をブロックチェーンネットワーク６１で発行しているが、これは、公開鍵証明書の用途の一例である。すなわち、ブロックチェーンネットワーク６１を用いた公開鍵証明書は、ブロックチェーンネットワーク６０以外にも利用できる。

また第２、第３の実施の形態では、公開鍵６２ｂについて証明書を発行しているが、他の情報について、その情報の所有者の証明する証明書を発行することもできる。
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ ネットワーク
２ａ，２ｂ，２ｃ 端末装置
３ａ，３ｂ，３ｃ ブロックチェーンノード
４，４−１，４−２，４−３ ブロック
４ａ 証明対象情報
４ｂ，５ａ，５ｎ，６ａ 電子署名
６ 電子証明書
７ 証明書発行部
８ ユーザ
９ａ，９ｂ 管理者

Claims (6)

1. ブロックチェーンによって複数のブロックを保持するネットワークへ、ユーザが所有する証明対象情報を含む第１ブロックの登録要求を出力する第１の端末装置と、
   前記ネットワークから、前記証明対象情報を含むブロックを、承認対象ブロックとして取得し、管理者からの入力に応じて、前記証明対象情報の登録承認を示す電子署名と前記承認対象ブロックとを含む第２ブロックの登録要求を、前記ネットワークへ出力する複数の第２の端末装置と、
   前記ネットワークに属し、前記第１または第２ブロックの登録要求に応じて、前記第１または第２ブロックをブロックチェーンによって分散して保持し、保持した前記第２ブロックのなかに、包含する前記電子署名の数が所定数に達した署名数充足ブロックがある場合、前記証明対象情報の所有者を証明する電子証明書と前記署名数充足ブロックとを含む第３ブロックを、ブロックチェーンによって分散して保持する複数のブロックチェーンノードと、
   を有する証明書配付システム。
2. 前記複数のブロックチェーンノードのうちの一ブロックチェーンノードは、前記証明対象情報を前記一ブロックチェーンノード自身の秘密鍵で暗号化した有効化用電子署名を、前記証明対象情報に付与することで、前記電子証明書を作成し、
   さらに、
   前記一ブロックチェーンノードの公開鍵を取得し、取得した前記公開鍵により前記電子証明書の正当性を検証し、正しく検証できた場合、前記証明対象情報の所有者が前記ユーザであると判断する第３端末装置を有する、
   請求項１記載の証明書配付システム。
3. 前記第１の端末装置は、前記ユーザからの、前記証明対象情報の破棄を指示する入力に応じて、破棄を示すフラグと前記第３ブロックとを含む第４ブロックの登録要求を、前記ネットワークへ出力し、
   前記複数のブロックチェーンノードは、前記第４ブロックの登録要求に応じて、前記第４ブロックをブロックチェーンによって分散して保持すると共に、前記第４ブロックに破棄を示す前記フラグが含まれることを検出すると、前記第４ブロックに含まれる情報に対するブロックチェーンノード自身の無効化用電子署名と前記第４ブロックとを含む第５ブロックを、ブロックチェーンによって分散して保持する、
   請求項１または２に記載の証明書配付システム。
4. 前記第１の端末装置は、前記第４ブロックに、前記第３ブロック内の情報に対する前記ユーザの所有者電子署名を含め、
   前記複数のブロックチェーンノードは、前記第４ブロックに破棄を示す前記フラグが含まれることを検出した場合、前記ユーザの所有者公開鍵を用いて、前記第３ブロック内の情報に対する前記所有者電子署名の正当性を検証し、正当であることが確認できた場合、前記第５ブロックを作成し、作成した前記第５ブロックをブロックチェーンによって分散して保持する、
   請求項３記載の証明書配付システム。
5. 第１の端末装置が、ブロックチェーンによって複数のブロックを保持するネットワークへ、ユーザが所有する証明対象情報を含む第１ブロックの登録要求を出力し、
   前記ネットワークに属する複数のブロックチェーンノードが、前記第１ブロックの登録要求に応じて、前記第１ブロックをブロックチェーンによって分散して保持し、
   複数の第２の端末装置が、前記ネットワークから、前記証明対象情報を含むブロックを、承認対象ブロックとして取得し、管理者からの入力に応じて、前記証明対象情報の登録承認を示す電子署名と前記承認対象ブロックとを含む第２ブロックの登録要求を、前記ネットワークへ出力し、
   前記複数のブロックチェーンノードが、前記第２ブロックの登録要求に応じて、前記第２ブロックをブロックチェーンによって分散して保持し、
   複数のブロックチェーンノードのうちの１台が、保持した前記第２ブロックのなかに、包含する前記電子署名の数が所定数に達した署名数充足ブロックがある場合、前記証明対象情報の所有者を証明する電子証明書と前記署名数充足ブロックとを含む第３ブロックを作成し、
   複数のブロックチェーンノードが、前記第３ブロックをブロックチェーンによって分散して保持する、
   証明書配付方法。
6. ブロックチェーンによって複数のブロックを保持するネットワークに属するコンピュータに、
   前記複数のブロックのなかに、ユーザが所有する証明対象情報と、前記証明対象情報の登録承認を示す、所定数に達した電子署名とを含む署名数充足ブロックがある場合、前記証明対象情報の所有者を証明する電子証明書と前記署名数充足ブロックとを含むブロックを作成し、
   作成した前記ブロックを保持すると共に、前記ネットワークに属する他のコンピュータに、前記ブロックを送信する、
   処理を実行させる証明書配付プログラム。

Images