JP6480528B2 - 電子証明システム - Google Patents

Description

本発明は、公開鍵基盤において用いる公開鍵などのデータの信頼性の担保を行う、電子証明システムに関する。

従来、インターネットを介した通信等をセキュアに行うために、公開鍵基盤が広く用いられている。これは、公開鍵によって暗号化したデータは秘密鍵によってのみ復号でき、秘密鍵によって暗号化したデータは公開鍵によってのみ復号できる、という特性を利用したものである。

ただし、その特性上、第三者が本来意図される通信相手に成りすまして公開鍵の提供を行った場合、情報を不正に取得されてしまうリスクが伴う。それを回避するために、電子証明書を用いる仕組みが利用されている。

一例として、サーバ−クライアント間において公開鍵基盤を利用した通信を行う場合について説明する。図１４は、サーバ側で、事前に電子証明書を用意する際の処理の流れを示す図である。

サーバでは、まずステップＳ８０１において、自身の秘密鍵と公開鍵の生成を行う。ここで、生成した秘密鍵については、外部への流出等が起きないよう、厳重に管理される必要がある

続くステップＳ８０２において、サーバは認証局へ、署名要求を送信する。ここでの認証局とは、電子署名を行うことによって電子証明書が正規のものである、ということを担保する機関であり、その正当性は、更に上位の認証局による証明書の発行などによって担保される。また、署名要求とは、ステップＳ８０１において生成されたサーバの公開鍵や、サーバの保有者の情報、サーバのＦＱＤＮやＩＰアドレスといったサーバにアクセスする際にクライアントが用いる情報などを含み、認証局へ、それらの情報への電子署名による電子証明書の作成を依頼するものである。

そして、ステップＳ８０３において、認証局による電子署名によってサーバの電子証明書が生成される。ここで、認証局による電子署名は、より具体的には、署名要求に含まれる情報のハッシュ値などを、認証局自身の秘密鍵によって暗号化することによって行われる。そして、ステップＳ８０４において、電子証明書がサーバへと返却される。

以上の処理によってサーバの電子証明書が用意された後、サーバ−クライアントでの通信において、証明書は図１５に示すような処理に用いられる。まず、ステップＳ９０１において、クライアントからの接続要求があると、ステップＳ９０２において、サーバは自身の電子証明書をクライアントへと送信する。

電子証明書を受信したクライアントは、その内容から、当該電子証明書へ電子署名を行った認証局を確認し、ステップＳ９０３において、認証局へと電子署名の検証のための公開鍵を要求する。

ステップＳ９０４で、認証局よりクライアントへと認証局の公開鍵が提供され、クライアントは、ステップＳ９０５において、電子署名の検証を行う。これは、先に述べたような公開鍵と秘密鍵の特性を利用したものであり、すなわち、電子署名を認証局の公開鍵によって復号し、元のハッシュ値などが正しく得られるか、確認を行うものである。

そして、ステップＳ９０５において電子署名の検証が成功すれば、クライアントは電子証明書が正規のものであるとして信頼し、以降のサーバとの通信を行う。サーバとの通信としては、例えば、クライアントからサーバへのデータ送信を行う際に、電子証明書に含まれる公開鍵によってデータの暗号化を行い、対応する秘密鍵を持っているサーバでしか復号ができない状態でデータの送信を行う、といったものである。また、サーバ−クライアント間で双方向の通信をセキュアに保つ必要がある場合には、同様にして、クライアント側の公開鍵をサーバへと送信する処理が行われる。

なお、ここでは説明の簡単のために省略するが、クライアントでは、認証局自体が信用に足るものであるかの検証を行うために認証局の電子証明書を取得し、それを検証する、といった処理が行われ、最終的には、クライアントに登録されたルート証明書が信頼できるものであるという前提のもと、電子証明書が信頼できるものであるという判断が下される。

以上が、公開鍵基盤を利用する場合の電子証明書の準備、サーバ−クライアント間の通信開始時の処理のおおまかな流れである。また、電子証明書は、公開鍵の送信以外にも、例えば、電子メールなどの文書に対して電子署名を行うことにより、文書の送信元や内容に改ざんがないことを担保する、といった目的などにも用いられる。このように、電子証明書を用いた信頼性の担保は、送信元やその内容などに信頼性が求められる種々のデータのやり取りにおいて利用されており、更に、これを応用したシステムなども開発されている。

例えば、特許文献１には、複数台のノードが参加するシステムにおいて、そのうちの複数台の代表ノードによって認証局としての動作を行うことで、認証局への攻撃に対する耐性を高める、分散認証システムが記載されている。これは、複数台の代表ノードが連携して代表鍵の秘密鍵を用いた電子署名を行うが、代表ノードの内の何れのノードも代表鍵の秘密鍵自体を保持しないような構成とすることにより、システムの参加者が電子署名に用いる代表鍵の秘密鍵自体は知り得ないような構成としているものである。

また、特許文献２には、電子署名生成者が正規に行った電子署名と、第三者が電子署名生成者に成りすまして行った電子署名とを識別可能とするために、電子署名のログの記録を行い、電子署名の検証時にそのログを確認する構成としたシステムが記載されている。

特開２００８−１８６０６４号公報 特開２００４−４０８３０号公報

従来の電子証明書を用いた信頼モデルは、電子署名を行う認証局が信頼できるものであるという前提の基に成り立っているものである。そのため、仮に認証局が電子署名に用いる秘密鍵の外部への流出等が発生した場合には、当該認証局による電子署名は全く意味をなさなくなってしまう。

これは、特許文献１に記載されるシステムのように、認証局の役割を複数ノードで分担する場合であっても同様で、電子署名に用いる秘密鍵を単一のノード上で管理しない構成であっても、秘密鍵の流出等が起きないことを絶対とすることはできず、それを用いた電子署名によって信頼が担保される構成であれば、秘密鍵の流出によって信頼モデルが崩壊してしまうという点においては、上述した従来技術と同様の問題を有しているといえる。

また、特許文献２に記載されるシステムによれば、認証局が電子署名に用いる秘密鍵が外部に流出した場合においても、電子署名のログを参照することによって、電子署名が正規に行われたものであるか否かの判別は可能であるものの、クライアントにおける検証処理が複雑化するという問題が生じる。すなわち、従来の電子証明書を用いた信頼モデルであっても、実際に検証の対象とする電子証明書の検証、それに電子署名を行った認証局の電子証明書の検証、といった処理が求められる上に、更に、電子署名のログの検証も必要となってしまうため、クライアントにおける処理コストが増大してしまう。

そこで、本発明では、信頼性を向上しながらも、信頼性の検証のための処理を簡単化することのできる、電子証明システムを提供することを課題とする。

上記課題を解決するために、本発明に係る電子証明システムは、
ブロックチェーンに登録された証跡を以て、第１の端末装置から第２の端末装置に対して提供されるデータの信頼性を担保する電子証明システムであって、
前記第１の端末装置が、
前記第１の端末装置、前記第１の端末装置の管理者、前記第１の端末装置上で稼働し前記第２の端末装置と前記データのやり取りを行うプログラムの内の少なくとも１つに関する情報と、前記データと、を前記ブロックチェーンに登録し、登録によって生成されたブロックである前記証跡を前記ブロックチェーンからの返却により取得する証跡登録手段と、
前記第２の端末装置に対して、前記証跡登録手段が前記ブロックチェーンからの返却により取得した前記証跡を送信する証跡提供手段と、を備え、
前記第２の端末装置が、前記証跡提供手段から提供された前記証跡が前記ブロックチェーンに前記ブロックとして登録されている場合に、前記データが信頼できるものであるという判定を行うことを特徴とする。

このように、サーバなどの第１の端末装置から提供するデータをブロックチェーンへ登録し、それをクライアントなどの第２の端末装置が取得する構成とすることによって、ブロックチェーンのデータの削除や上書きが不可能であるという特性から、信頼性の高いデータの提供を行うことができる。また、従来の電子証明書を用いたシステムのように、クライアントなどのデータの受領側での公開鍵による電子署名の復号や、ハッシュ値の演算などの処理を省略することができるため、検証処理に係る通信や処理を大きく削減することができる。

本発明に係る電子証明システムの他の形態は、
ブロックチェーンに登録された証跡を以て、第１の端末装置によってデータストアに登録され、第２の端末装置に対して提供されるデータの信頼性を担保する電子証明システムであって、
前記第１の端末装置が、
前記第１の端末装置、前記第１の端末装置の管理者、前記第１の端末装置上で稼働し前記第２の端末装置と前記データのやり取りを行うプログラムの内の少なくとも１つに関する情報を前記ブロックチェーンに登録し、登録によって生成されたブロックである前記証跡を前記ブロックチェーンからの返却により取得する証跡登録手段と、
前記証跡と、前記データと、を紐づけて前記データストアに登録するストア登録手段と、
前記第２の端末装置に対して、前記証跡登録手段が前記ブロックチェーンからの返却により取得した前記証跡を送信する証跡提供手段と、を備え、
前記第２の端末装置が、前記証跡提供手段から提供された前記証跡が前記ブロックチェーンに前記ブロックとして登録されている場合に、当該証跡を用いて、前記データストアより前記データの取得を行うことを特徴とする。
このように、証跡をブロックチェーンに、信頼性を担保する対象であるデータをデータストアに保持する構成とすることによって、ブロックチェーンの特性を利用した信頼性の担保を行いながら、より多様なデータの提供を行うことができる。

本発明に係る電子証明システムの他の形態は、
ブロックチェーンに登録された証跡を以て、第１の端末装置によって電子証明書ストアに登録され、第２の端末装置に対して提供される電子証明書に含まれるデータの信頼性を担保する電子証明システムであって、
前記第１の端末装置が、
前記第１の端末装置、前記第１の端末装置の管理者、前記第１の端末装置上で稼働し前記第２の端末装置と前記データのやり取りを行うプログラムの内の少なくとも１つに関する情報を前記ブロックチェーンに登録し、登録によって生成されたブロックである前記証跡を前記ブロックチェーンからの返却により取得する証跡登録手段と、
前記電子証明書の生成と、前記証跡登録手段が前記ブロックチェーンからの返却により取得した前記証跡と前記電子証明書とを紐づけての前記電子証明書ストアへの登録と、を行う電子証明書登録手段と、
前記ブロックチェーンに前記ブロックとして登録された前記証跡の有効性の検証と、前記電子証明書ストアからの前記証跡に対応する前記電子証明書の取得と、前記電子証明書の前記第２の端末装置への送信と、を行う電子証明書提供手段と、を備え、
前記第２の端末装置が、前記電子証明書提供手段から提供された前記電子証明書より前記データを取り出すことを特徴とする。
このように、証跡の有効性の検証をサーバなどの第１の端末装置側で行い、クライアントなどの第２の端末装置へは電子証明書の形態でデータの提供を行う構成とすることにより、従来の電子証明書を取り扱うことができるクライアントなどで広く利用可能なシステムとすることができる。

本発明の好ましい形態では、前記ブロックチェーンに、前記証跡よりも後に登録された、当該証跡を無効化するブロックが存在することを以て、前記証跡が有効でないとすることを特徴とする。
これにより、データの削除や上書きが不可能であるという特性があるブロックチェーンを利用しながらも、従来の電子証明書のように、有効期限の設定や無効化が可能な構成を実現することができる。

本発明の好ましい形態では、前記データが前記第１の端末装置の公開鍵であることを特徴とする。
このように、公開鍵基盤による通信に用いる公開鍵の信頼性の担保を行うことで、端末装置間におけるセキュアな通信を補助することができる。

ブロックチェーンの特性を利用した信頼性の向上と、信頼性の検証のための処理の軽量化を共に実現することのできる電子証明システムを提供することができる。

本発明の実施形態１に係る電子証明システムの構成図である。 本発明の実施形態１に係る電子証明システムの機能ブロック図である。 本発明の実施形態１における証跡及び公開鍵の登録処理を示すシーケンス図である。 本発明の実施形態１におけるサーバ−クライアント間での通信開始時の処理を示すシーケンス図である。 本発明の実施形態１における証跡の失効処理を示すシーケンス図である。 本発明の実施形態２に係る電子証明システムの構成図である。 本発明の実施形態２に係る電子証明システムの機能ブロック図である。 本発明の実施形態２における証跡及び公開鍵の登録処理を示すシーケンス図である。 本発明の実施形態２におけるサーバ−クライアント間での通信開始時の処理を示すシーケンス図である。 本発明の実施形態３に係る電子証明システムの構成図である。 本発明の実施形態３に係る電子証明システムの機能ブロック図である。 本発明の実施形態３における証跡及び電子証明書の登録処理を示すシーケンス図である。 本発明の実施形態３におけるサーバ−クライアント間での通信開始時の処理を示すシーケンス図である。 従来の認証局による電子証明書の発行処理を示すシーケンス図である。 従来のシステムにおけるサーバ−クライアント間での通信開始時の処理を示すシーケンス図である。

（実施形態１）
以下、図面を参照して、本発明の実施形態１について詳細に説明する。図１は、本実施形態に係る電子証明システムの構成図である。本実施形態に係る電子証明システムは、サーバ１と、ブロックチェーン２と、３ａ〜３ｄの複数のクライアント３（以下、特に区別の必要がない場合、単にクライアント３と呼称する）とが、インターネットなどのネットワークＮＷを介して通信可能に構成される。そして、サーバ１とクライアント３の間において公開鍵基盤を利用して通信を行うためにサーバ１よりクライアント３へと提供されるサーバ１の公開鍵の信頼性の担保を、ブロックチェーン２を利用して行うものである。

なお、ブロックチェーン２は元来、仮想通貨であるビットコインにおいて分散型台帳として利用されるものであり、多数のノードによって構成されるものであるが、ここでは説明の簡単のために、図１に示すように、単一の構成要素として示す。

ブロックチェーン２は、ブロックと呼ばれるデータの連鎖によって構成されるものであり、各ブロックはその前のブロックのハッシュ値の情報を含むものであるため、何れかのブロックの改ざんが行われた場合には、連鎖関係に不整合が生じる。また、多数のノードによって構成される分散型のシステムであることからも、単一のノードの操作などによって、そのような不正な改ざん処理や、ブロックの削除などを行うことができないという特性を有する。なお、本明細書においては、サーバ１に関する情報やサーバ１の公開鍵などのデータの登録によって生成されたブロックを、証跡と呼称する。

図２に、本実施形態に係る電子証明システムの機能ブロック図を示す。ここに示すように、サーバ１は、サーバ１の公開鍵及び秘密鍵を生成する鍵生成手段１０１と、鍵生成手段１０１によって生成された公開鍵とサーバ１に関する情報などをブロックチェーン２へと登録し、ブロックチェーン２より証跡の取得を行う証跡登録手段１０２と、証跡のクライアント３への提供を行う証跡提供手段１０３と、鍵生成手段１０１によって生成された公開鍵及び秘密鍵を用いた公開鍵基盤を利用したサービスをサーバ１よりクライアント３へと提供するサービス提供手段１０４と、を有する。

サーバ１としては、ＣＰＵなどの演算装置、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの主記憶装置、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリなどの補助記憶装置、ネットワークＮＷへの接続手段を含む種々の入出力装置等を備えた、サーバ機器などの一般的なコンピュータ装置を利用することができる。より詳細には、補助記憶装置に予め、あるいはサーバ１の管理者の操作などによって、上述したような各手段としてサーバ１を動作させるためのプログラムを格納しておき、それらのプログラムを主記憶装置上に展開して演算装置による演算を行い、入出力手段の制御などを行うことで、コンピュータ装置を本実施形態に係る電子証明システムにおけるサーバ１として利用することができる。なお、本実施形態においては、単一のコンピュータ装置によってサーバ１を実現する構成を示したが、本発明はこれに限るものではない。例えば、サービス提供手段１０４を別のコンピュータ装置に備えるような構成など、複数のコンピュータ装置によってサーバ１を実現するような構成としてもよい。

クライアント３としても、演算装置、主記憶装置、補助記憶装置、ネットワークＮＷへの接続手段を含む種々の入出力装置等を備えた、一般的なコンピュータ装置を利用することができる。図１においては、一例として、パーソナルコンピュータ３ａ、タブレット型端末３ｂ、ネットワークカメラ３ｃ、車載機器３ｄを示したが、本発明はこれに限るものでなく、他の種々のコンピュータ装置についても、クライアント３として用いることができる。

＜証跡の登録処理＞
図３は、サーバ１によるブロックチェーン２への証跡の登録処理の流れを示すシーケンス図である。まず、ステップＳ１０１において、鍵生成手段１０１により、サーバ１の秘密鍵、公開鍵の生成処理が行われる。ここで、より詳細には、秘密鍵の生成後に、それを用いて対応する公開鍵を生成するような処理であってもよい。ここで生成された公開鍵は、ブロックチェーン２へ登録するために、証跡登録手段１０２へと受け渡される。一方で秘密鍵は、外部への流出等が起きないよう取り扱う必要がある。

続くステップＳ１０２で、証跡登録手段１０２よりブロックチェーン２へと、証跡の登録要求が行われる。これはすなわち、サーバ１に関する情報やサーバ１の管理者に関する情報、後にこの公開鍵を用いた公開鍵基盤による通信を行うサービス提供手段１０４に関する情報、といった情報と、公開鍵をブロックチェーン２への登録によるブロックの生成を依頼する処理である。

ステップＳ１０３では、証跡登録手段１０２からの要求に基づいて、ブロックチェーン２へのサーバ１に関する情報などと公開鍵の登録処理、すなわち、ブロックの生成処理が行われる。そして、ここで生成されたブロックが、ステップＳ１０４において、証跡としてサーバ１へと返却される。以上の処理によって、サーバ１によるブロックチェーン２への証跡の登録処理が完了する。

なお、ブロックチェーン２への証跡の登録については、ＩＳＭＳ（Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｃｕｒｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ，情報セキュリティマネジメントシステム）を取得している団体など、適切な監査を受けた団体によって管理されることが好ましい。このようにすることによって、ブロックチェーン２への不適切な証跡の登録などを防ぎ、本実施形態に係る電子証明システムの信頼性を更に向上することができる。また、仮に不正な証跡の登録が行われた場合にも、不正な登録の痕跡が削除できない状態でブロックチェーン２上に残るため、事態の把握や再発防止のための対策に活用することができる。

＜公開鍵の提供処理＞
図４は、サーバ１とクライアント３との間での、公開鍵基盤を利用した通信の開始時における処理の流れを示すシーケンス図である。まず、ステップＳ２０１において、クライアント３よりサーバ１へと接続要求が送信される。それを受けたサーバ１は、ステップＳ２０２において、証跡提供手段１０３により、証跡をクライアント３へと送信する。

証跡を受信したクライアント３は、ステップＳ２０３において、当該証跡の有効性のブロックチェーン２への確認処理を行う。これはすなわち、当該証跡がブロックチェーン２上に存在するかを問い合わせるものである。

そして、ステップＳ２０４においてブロックチェーン２よりクライアント３へ、証跡の有効性についての返答がなされる。ここで、当該証跡がブロックチェーン２上に存在するのであれば、クライアント３は、当該証跡に含まれる情報によって特定されるサーバ１との間で、同じく当該証跡に含まれるサーバ１の公開鍵を用いて通信を行うことが安全であると判断することができる。

クライアント３がサーバ１の公開鍵の安全性を確認した後には、サーバ１の秘密鍵によって暗号化されたデータがクライアント３へと送信され、クライアント３はそれをサーバ１の公開鍵によって復号し、クライアント３はサーバ１の公開鍵によってデータの暗号化を行ってサーバ１へと送信し、サーバ１はそれをサーバ１の秘密鍵によって復号する、といったような、公開鍵基盤を利用した通信を行うことができる。

このように、ブロックチェーン２上に証跡が存在するか否かの確認処理によって公開鍵の信頼性の検証を行う構成とすることによって、従来の電子証明書の検証のような、電子署名の検証用の公開鍵の取得、電子署名の復号化やハッシュ値の算出、といった処理をルート証明書に到達するまで行う、といった処理を不要とし、クライアント３上での処理量や通信量を大きく削減することができる。

＜証跡の失効処理＞
場合によっては、例えば所定の期間の経過などを以て、サーバ１の公開鍵を変更し、古い公開鍵を登録した証跡をブロックチェーン２より削除する必要が生じることが考えられる。しかし、先に述べた通り、ブロックチェーン２の特徴は、ブロックの上書きや削除を許容しない点にある。そのため、そのような場合には、図５のシーケンス図に示したような処理により、証跡の無効化を行う。

まず、ステップＳ３０１において、サーバ１よりブロックチェーン２へと、自身が過去に登録した証跡の失効処理の依頼が送信される。これはすなわち、特定の証跡が無効であることを示す、新たなブロックの生成の依頼である。そして、ステップＳ３０２において、ブロックチェーン２上にそのようなブロックの生成が行われ、証跡の失効処理が終了する。

このようにして、証跡が無効化された場合には、サーバ１とクライアント３の間での通信開始時に、ステップＳ２０３においてクライアント３よりブロックチェーン２へと証跡の有効性の確認を行う際に、当該証跡がブロックチェーン２上に存在していても、それを無効化するブロックが存在する場合には、証跡は無効である、という判定を行う。

これにより、ブロックの上書きや削除ができないという特性を持つブロックチェーン２を利用しながらも、公開鍵の無効化などの処理を行うことができる。

＜他のデータに対する信頼性の担保＞
本実施形態においては、サーバ１とクライアント３の間での通信に用いるサーバ１の公開鍵の信頼性の担保を行う例を示したが、本発明はこれに限るものではなく、従来、電子証明書によってその信頼性が担保されていたような、種々のデータについての信頼性の担保を行うことができる。

例えば、電子メールなどの文書について、改ざんされていないことを担保するのであれば、図３を参照して説明した証跡の登録処理におけるステップＳ１０１で、秘密鍵、公開鍵の生成に代えて、文書のハッシュ値を算出し、続くステップＳ１０２、Ｓ１０３でそれをブロックチェーン２へと登録すればよい。このように、文書のハッシュ値をブロックチェーン２へと登録しておき、文書の提供時に証跡を共に提供することによって、提供を受けた側で、文書のハッシュ値の算出を行い、その結果と証跡の内容とが一致すれば、文書は改ざんされていない、という判断をすることができる。

なお、本実施形態においては、サーバ１としてサーバ機器を、クライアント３として、パーソナルコンピュータをはじめとしたいわゆるクライアント機器を適用する例を示したが、本明細書における「サーバ」、「クライアント」の語は、このような具体的な機器を特定するものではなく、クライアントサーバモデルを構成する複数の機器について、データを送信する役割を担う機器を「サーバ」、データを受信する役割を担う機器を「クライアント」と呼称しているに過ぎない。すなわち、クライアント証明書のように、パーソナルコンピュータやモバイル機器などのクライアント機器が正当なものである、ということを、接続先のサーバ機器などに対して証明する、という用途であれば、自身に関する情報等を送信するクライアント機器が「サーバ」の役割を、それを受信し、検証するサーバ機器などが「クライアント」の役割を、それぞれ担うこととなる。

更に、クライアントサーバモデルに限らず、より単純に、２以上のデバイス間において任意の物理記憶媒体などを介してデータのやり取りを行うような場合においても、データの提供先の端末装置に対して、データの信頼性の担保を行うことができる。すなわち、１の端末装置から他の端末装置へとデータのやり取りを行う場合であれば、本実施形態に示したように、ネットワークを介しての証跡の提供を行う場合でも、物理記憶媒体を介すような他の方法での証跡の提供を行う場合でも、本発明に係る電子証明システムを適用し、データの信頼性を担保することができる。

以上のように、本実施形態に係る電子証明システムによれば、ブロックチェーンのデータの削除や上書きが不可能であるという特性を利用し、クライアント側（すなわち、データの受領側）における、署名の検証処理などを省略でき、かつ、高い信頼性を担保することができる。

また、従来の電子証明書を用いた信頼モデルのように、認証局への電子署名の依頼や、認証局による依頼者や依頼内容の確認といった処理を省略し、ブロックチェーン２への証跡の登録を以て信頼性の担保を行うことができる。これにより、多量の端末装置について、それぞれの端末装置が公開鍵／秘密鍵を有する場合のように、多量のデータの正当性を担保する必要があるような場合において、特に大きな効果が期待できる。

（実施形態２）
以下、図面を参照して本発明の実施形態２について詳細に説明する。なお、上述した実施形態１と基本的に同一の構成要素については、同一の符号を付してその説明を簡略化す
る。図６は、本実施形態に係る電子証明システムの構成図である。ここに示すように、本実施形態に係る電子証明システムは、サーバ１、ブロックチェーン２、クライアント３に加え、公開鍵記憶部４０１を備える公開鍵ストア４がネットワークＮＷを介して通信可能に接続されている。

図７は、本実施形態に係る電子証明システムの機能ブロック図である。ここに示すように、サーバ１は、鍵生成手段１０１、証跡登録手段１０２、証跡提供手段１０３、サービス提供手段１０４に加えて、公開鍵ストア４に対して公開鍵の登録を依頼する、公開鍵登録手段１０５を備える。

＜証跡の登録処理＞
図８は、本実施形態に係る電子証明システムにおけるブロックチェーン２への証跡の登録処理、及び、公開鍵ストア４への公開鍵の登録処理の流れを示すシーケンス図である。まず、ステップＳ４０１において、鍵生成手段１０１により、サーバ１の秘密鍵、公開鍵の生成処理が行われる。

ステップＳ４０２では、証跡登録手段１０２よりブロックチェーン２へと、証跡の登録処理が行われる。本実施形態においては、ここで、サーバ１に関する情報やサーバ１の管理者に関する情報、後にサーバ１の公開鍵を用いた公開鍵基盤による通信を行うサービス提供手段１０４に関する情報、といった情報をブロックチェーン２への登録によるブロックの生成を依頼する処理であり、サーバ１の公開鍵自体については、ブロックチェーン２への登録を行わない。ステップＳ４０２における以来の後には、ステップＳ４０３でブロックの生成が行われ、ステップＳ４０４で、それが証跡としてサーバ１へ返却される。

ここまでの処理でブロックチェーン２へと証跡の登録を行った後、ステップＳ４０５で、サーバ１より公開鍵ストア４へ、公開鍵の登録が要求される。この要求は、ステップＳ４０４で返却を受けた証跡と、ステップＳ４０１で生成した公開鍵とを紐づけて、公開鍵ストア４の備える公開鍵記憶部４０１へと記録することを依頼するものである。依頼を受けた公開鍵ストア４は、ステップＳ４０６において、公開鍵記憶部４０１への証跡、公開鍵の記録を行う。

以上の処理によって、サーバ１に関する情報などが証跡としてブロックチェーン２に、サーバ１の公開鍵が証跡と紐づいた状態で公開鍵ストア４に、それぞれ保管される状態となる。

＜公開鍵の提供処理＞
図９は、サーバ１とクライアント３との間での、公開鍵基盤を利用した通信の開始時における処理の流れを示すシーケンス図である。ステップＳ５０１からステップＳ５０４までの処理については、証跡が公開鍵そのものを含まない点を除いて、図４のステップＳ２０１からＳ２０４を参照して説明した、実施形態１における処理と同様である。

本実施形態においては、ステップＳ５０４までの処理においてサーバ１から提供された証跡の有効性が確認できた場合には、ステップＳ５０５において、クライアント３から公開鍵ストア４への、サーバ１の公開鍵の要求が行われる。公開鍵ストア４には、サーバ１の公開鍵が証跡と紐づけられた状態で保管されているため、ステップＳ５０５では、クライアント３からブロックチェーン２へ、サーバ１から提供された証跡の送信を行い、それに対応する公開鍵を要求する、といった処理となる。

そして、ステップＳ５０６において、クライアント３からの要求への返答として、公開鍵ストア４よりサーバ１の公開鍵が送信され、クライアント３への公開鍵の提供処理は終了する。以上のようにして、公開鍵そのものをブロックチェーン２へと登録せずとも、公開鍵ストア４を利用して、クライアント３への公開鍵の提供を行うことができる。

なお、公開鍵の失効処理についても、実施形態１において、図５を参照して説明したように、ブロックチェーン２上に証跡の失効を示すようなブロックの登録を行うことによって実現することができる。

また、本実施形態においても、サーバ１で利用する公開鍵の公開鍵ストア４への記録は一例に過ぎず、その他の種々のデータについて、信頼性を担保する目的で利用することができる。特に、データサイズの比較的大きなデータについて信頼性の担保が必要となる場合においては、公開鍵ストア４のようなデータストアへとデータの保存を行う本実施形態に係る構成を好適に用いることができる。

（実施形態３）
以下、図面を参照して本発明の実施形態３について詳細に説明する。なお、上述した実施形態１と基本的に同一の構成要素については、同一の符号を付してその説明を簡略化す
る。図１０は、本実施形態に係る電子証明システムの構成図である。ここに示すように、本実施形態に係る電子証明システムは、サーバ１、ブロックチェーン２、クライアント３に加え、電子証明書記憶部５０１を備える電子証明書ストア５がネットワークＮＷを介して通信可能に接続されている。

図１１は、本実施形態に係る電子証明システムの機能ブロック図である。ここに示すように、サーバ１は、鍵生成手段１０１、証跡登録手段１０２、証跡提供手段１０３、サービス提供手段１０４に加えて、電子証明書ストア５に対してサーバ１の公開鍵を含む電子証明書の登録を依頼する電子証明書登録手段１０６と、クライアント３に対して電子証明書の提供を行う電子証明書提供手段１０７と、を備える。

＜証跡の登録処理＞
図１２は、本実施形態に係る電子証明システムにおけるブロックチェーン２への証跡の登録処理、及び、電子証明書ストア５への電子証明書の登録処理の流れを示すシーケンス図である。まず、ステップＳ６０１において、鍵生成手段１０１により、サーバ１の秘密鍵、公開鍵の生成処理が行われる。

ステップＳ６０２では、ステップＳ６０１で生成したサーバ１の公開鍵や、サーバ１に関する情報などに対して電子署名を行い、電子証明書が生成される。なお、ここでの電子署名は、サーバ１が予め、あるいは、鍵生成手段１０１による生成処理によって、ステップＳ６０１で生成した公開鍵、秘密鍵とは別に、電子署名用の秘密鍵（以後、署名用秘密鍵と呼称する）と、その検証を行うための公開鍵（以後、検証用公開鍵と呼称する）を用意しておき、署名用秘密鍵によって、ステップＳ６０１で生成したサーバ１の公開鍵を含む電子証明書への署名を行うものである。すなわち、ここで生成される電子証明書は、サーバ１による自己署名による、自己発行証明書にあたる。あるいは、署名用秘密鍵及び検証用公開鍵を別途用意せず、ステップＳ６０１で生成した公開鍵に対して、同じくステップＳ６０１で生成した秘密鍵によって電子署名を行い、自己署名証明書を生成してもよい。

ステップＳ６０３では、証跡登録手段１０２よりブロックチェーン２へと、証跡の登録処理が行われる。本実施形態においては、ここで、サーバ１に関する情報やサーバ１の管理者に関する情報、後にサーバ１の公開鍵を用いた公開鍵基盤による通信を行うサービス提供手段１０４に関する情報、といった情報をブロックチェーン２への登録によるブロックの生成を依頼する処理であり、電子証明書自体については、ブロックチェーン２への登録を行わない。

ここまでの処理でブロックチェーン２へと証跡の登録を行った後、ステップＳ６０６で、サーバ１より電子証明書ストア５へ、電子証明書の登録が要求される。この要求は、ステップＳ６０５で返却を受けた証跡と、ステップＳ６０２で生成した電子証明書とを紐づけて、電子証明書ストア５の備える電子証明書記憶部５０１へと記録することを依頼するものである。依頼を受けた電子証明書ストア５は、ステップＳ６０７において、電子証明書記憶部５０１への証跡、電子証明書の記録を行う。

以上の処理によって、サーバ１に関する情報などが証跡としてブロックチェーン２に、サーバ１の電子証明書が証跡と紐づいた状態で電子証明書ストア５に、それぞれ保管される状態となる。

＜公開鍵の提供処理＞
図１３は、サーバ１とクライアント３との間での、公開鍵基盤を利用した通信の開始時における処理の流れを示すシーケンス図である。まず、ステップＳ７０１において、クライアント３よりサーバ１へと接続要求が送信される。それを受けたサーバ１は、ステップＳ７０２において、ブロックチェーン２に対して、自身の証跡が有効な状態で存在するか否かの確認を行う。

ステップＳ７０３において、自己の証跡が有効であるという回答が得られた場合には、ステップＳ７０４に進み、当該証跡に紐づいた電子証明書の要求を行い、ステップＳ７０５で、電子証明書がサーバ１へと送信される。そして、ステップＳ７０６において、サーバ１よりクライアント３へ、電子証明書が送信され、ステップＳ７０７において、電子証明書の検証処理が行われる。

ステップＳ７０７における検証処理では、電子証明書への署名が、署名用秘密鍵で行われたものである場合、すなわち、電子証明書が自己発行証明書である場合には、サーバ１より検証用公開鍵の提供を受けて検証行われ、電子証明書がそれに含まれる公開鍵とペアとなっているサーバ１の秘密鍵によって署名された自己署名証明書である場合には、電子証明書に含まれる公開鍵を用いて検証が行われる。

なお、ここでは、サーバ１より提供される電子証明書は、自己発行電子証明書あるいは自己署名電子証明書であるため、クライアント３には予め、サーバ１が信頼できるサーバであるとして登録されている必要がある。

以上のような手順によってサーバ１の公開鍵を含む電子証明書がクライアント３へと提供される。なお、電子証明書の失効処理についても、実施形態１において、図５を参照して説明したように、ブロックチェーン２上に証跡の失効を示すようなブロックの登録を行うことによって実現することができる。

また、本実施形態においても、サーバ１で利用する公開鍵を含む電子証明書の電子証明書ストア５への記録は一例に過ぎず、その他の種々のデータについて、信頼性を担保する目的で利用することができる。すなわち、先に例示した電子メールのような文書などに対して、そのハッシュ値を含む電子証明書を電子証明書ストア５へと登録し、クライアント３へと提供する、といった利用である。

本実施形態に係る電子証明システムにおいては、クライアント３によるサーバ１からの証跡の受信や、クライアント３からブロックチェーン２への証跡の有効性確認などの処理が不要であり、クライアント３は、従来の電子証明書を用いた仕組みと同様に、自己発行証明書や自己署名証明書の検証を行うことができればよいため、より幅広いクライアント３を利用して、本発明に係る電子証明システムを実現することができるものである。

１ サーバ
１０１ 鍵生成手段
１０２ 証跡登録手段
１０３ 証跡提供手段
１０４ サービス提供手段
１０５ 公開鍵登録手段
１０６ 電子証明書登録手段
１０７ 電子証明書提供手段
２ ブロックチェーン
３ クライアント
４ 公開鍵ストア
４０１ 公開鍵記憶部
５ 電子証明書ストア
５０１ 電子証明書記憶部
ＮＷ ネットワーク

Claims (5)

1. ブロックチェーンに登録された証跡を以て、第１の端末装置から第２の端末装置に対して提供されるデータの信頼性を担保する電子証明システムであって、
   前記第１の端末装置が、
   前記第１の端末装置、前記第１の端末装置の管理者、前記第１の端末装置上で稼働し前記第２の端末装置と前記データのやり取りを行うプログラムの内の少なくとも１つに関する情報と、前記データと、を前記ブロックチェーンに登録し、登録によって生成されたブロックである前記証跡を前記ブロックチェーンからの返却により取得する証跡登録手段と、
   前記第２の端末装置に対して、前記証跡登録手段が前記ブロックチェーンからの返却により取得した前記証跡を送信する証跡提供手段と、を備え、
   前記第２の端末装置が、前記証跡提供手段から提供された前記証跡が前記ブロックチェーンに前記ブロックとして登録されている場合に、前記データが信頼できるものであるという判定を行うことを特徴とする、電子証明システム。
2. ブロックチェーンに登録された証跡を以て、第１の端末装置によってデータストアに登録され、第２の端末装置に対して提供されるデータの信頼性を担保する電子証明システムであって、
   前記第１の端末装置が、
   前記第１の端末装置、前記第１の端末装置の管理者、前記第１の端末装置上で稼働し前記第２の端末装置と前記データのやり取りを行うプログラムの内の少なくとも１つに関する情報を前記ブロックチェーンに登録し、登録によって生成されたブロックである前記証跡を前記ブロックチェーンからの返却により取得する証跡登録手段と、
   前記証跡と、前記データと、を紐づけて前記データストアに登録するストア登録手段と、
   前記第２の端末装置に対して、前記証跡登録手段が前記ブロックチェーンからの返却により取得した前記証跡を送信する証跡提供手段と、を備え、
   前記第２の端末装置が、前記証跡提供手段から提供された前記証跡が前記ブロックチェーンに前記ブロックとして登録されている場合に、当該証跡を用いて、前記データストアより前記データの取得を行うことを特徴とする、電子証明システム。
3. ブロックチェーンに登録された証跡を以て、第１の端末装置によって電子証明書ストアに登録され、第２の端末装置に対して提供される電子証明書に含まれるデータの信頼性を担保する電子証明システムであって、
   前記第１の端末装置が、
   前記第１の端末装置、前記第１の端末装置の管理者、前記第１の端末装置上で稼働し前記第２の端末装置と前記データのやり取りを行うプログラムの内の少なくとも１つに関する情報を前記ブロックチェーンに登録し、登録によって生成されたブロックである前記証跡を前記ブロックチェーンからの返却により取得する証跡登録手段と、
   前記電子証明書の生成と、前記証跡登録手段が前記ブロックチェーンからの返却により取得した前記証跡と前記電子証明書とを紐づけての前記電子証明書ストアへの登録と、を行う電子証明書登録手段と、
   前記ブロックチェーンに前記ブロックとして登録された前記証跡の有効性の検証と、前記電子証明書ストアからの前記証跡に対応する前記電子証明書の取得と、前記電子証明書の前記第２の端末装置への送信と、を行う電子証明書提供手段と、を備え、
   前記第２の端末装置が、前記電子証明書提供手段から提供された前記電子証明書より前記データを取り出すことを特徴とする、電子証明システム。
4. 前記ブロックチェーンに、前記証跡よりも後に登録された、当該証跡を無効化するブロックが存在することを以て、前記証跡が有効でないとすることを特徴とする、請求項１から請求項３の何れかに記載の電子証明システム。
5. 前記データが前記第１の端末装置の公開鍵であることを特徴とする、請求項１から請求項４の何れかに記載の電子証明システム。