特許 7209518 通信装置、通信方法、および通信プログラム

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

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

(11)【特許番号】

(24)【登録日】2023-01-12

(45)【発行日】2023-01-20

(54)【発明の名称】通信装置、通信方法、および通信プログラム

(51)【国際特許分類】

   H04L 9/08 20060101AFI20230113BHJP

   H04L 9/32 20060101ALI20230113BHJP

   G09C 1/00 20060101ALI20230113BHJP

【ＦＩ】

H04L9/08 F

H04L9/32 200B

G09C1/00 640D

【請求項の数】 8

(21)【出願番号】P 2018226341

(22)【出願日】2018-12-03

(65)【公開番号】P2020092287

(43)【公開日】2020-06-11

【審査請求日】2021-08-10

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100121083

【弁理士】

【氏名又は名称】青木 宏義

(74)【代理人】

【識別番号】100138391

【弁理士】

【氏名又は名称】天田 昌行

(74)【代理人】

【識別番号】100074099

【弁理士】

【氏名又は名称】大菅 義之

(74)【代理人】

【識別番号】100133570

【弁理士】

【氏名又は名称】▲徳▼永 民雄

(72)【発明者】

【氏名】鈴木 大

【審査官】金沢 史明

(56)【参考文献】

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

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

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

【文献】特開２０１８－１１７２８７（ＪＰ，Ａ）

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

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

【文献】国際公開第２０１８／０４３５９９（ＷＯ，Ａ１）

【文献】国際公開第２０１８／０８８４７５（ＷＯ，Ａ１）

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

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

【文献】FROMKNECHT, Conner et al.，A Decentralized Public Key Infrastructure with Identity Retention，Cryptology ePrint Archive，International Association for Cryptologic Research (IACR)，2014年11月11日，Report 2014/803, Ver. 20141111:124302，pp. 1-16，[2022年5月20日検索]，インターネット，<URL：https://eprint.iacr.org/2014/803/20141111:124302>

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

Ｈ０４Ｌ ９／００－ ９／４０

Ｇ０６Ｆ ２１／００－２１／８８

Ｇ０６Ｑ １０／００－９９／００

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

【請求項1】

通信システムを構成する複数のノードの中の１つにおいて使用される通信プログラムであって、
ユーザから前記ユーザのアカウント情報および前記ユーザの公開鍵を受信し、
前記アカウント情報の内容が正しいと判定されたときに、前記アカウント情報の内容が正しいことを表す登録可能メッセージおよび前記ユーザの公開鍵を前記複数のノードに送信し、
前記アカウント情報の内容が正しくないと判定されたときに、前記アカウント情報の内容が正しくないことを表す登録不可メッセージを前記複数のノードに送信し、
他のノードから受信する登録可能メッセージの数および登録不可メッセージの数の和が第１の所定数以上であり、且つ、前記登録可能メッセージの数が第２の所定数を超えたことを検出すると、前記通信システムへの参加が許可されたユーザの公開鍵を保存する公開鍵リストに前記ユーザの公開鍵を登録する
処理をプロセッサに実行させる通信プログラム。

【請求項2】

通信システムを構成する複数のノードの中の１つに設けられる通信装置であって、
ユーザから前記ユーザのアカウント情報および前記ユーザの公開鍵を受信し、
前記アカウント情報の内容が正しいと判定されたときに、前記アカウント情報の内容が正しいことを表す登録可能メッセージおよび前記ユーザの公開鍵を前記複数のノードに送信し、
前記アカウント情報の内容が正しくないと判定されたときに、前記アカウント情報の内容が正しくないことを表す登録不可メッセージを前記複数のノードに送信し、
他のノードから受信する登録可能メッセージの数および登録不可メッセージの数の和が第１の所定数以上であり、且つ、前記登録可能メッセージの数が第２の所定数を超えたことを検出すると、前記通信システムへの参加が許可されたユーザの公開鍵を保存する公開鍵リストに前記ユーザの公開鍵を登録する
プロセッサを備える通信装置。

【請求項3】

複数のノードを含む通信システムにおいて使用される通信方法であって、
前記複数のノードの中の２以上の認証ノードそれぞれにおいて、
ユーザから前記ユーザのアカウント情報および前記ユーザの公開鍵を受信し、
前記アカウント情報の内容が正しいと判定されたときに、前記アカウント情報の内容が正しいことを表す登録可能メッセージおよび前記ユーザの公開鍵を前記複数のノードに送信し、
前記アカウント情報の内容が正しくないと判定されたときに、前記アカウント情報の内容が正しくないことを表す登録不可メッセージを前記複数のノードに送信し、
各ノードは、
他のノードから受信する登録可能メッセージの数および登録不可メッセージの数の和が第１の所定数以上であり、且つ、前記登録可能メッセージの数が第２の所定数を超えたことを検出すると、前記通信システムへの参加が許可されたユーザの公開鍵を保存する公開鍵リストに前記ユーザの公開鍵を登録する
ことを特徴とする通信方法。

【請求項4】

各認証ノードは、
前記アカウント情報の内容が正しいと判定されたときに、前記ユーザの公開鍵に対して自分の秘密鍵で電子署名を生成し、
前記アカウント情報の内容が正しいことを表すメッセージ、前記ユーザの公開鍵、および前記電子署名を前記複数のノードに送信する
ことを特徴とする請求項３に記載の通信方法。

【請求項5】

各認証ノードは、
前記アカウント情報の内容が正しいと判定されたときに、前記アカウント情報および前記ユーザの公開鍵に対して自分の秘密鍵で電子署名を生成し、
前記アカウント情報の内容が正しいことを表すメッセージ、前記アカウント情報、前記ユーザの公開鍵、および前記電子署名を前記複数のノードに送信する
ことを特徴とする請求項３に記載の通信方法。

【請求項6】

前記認証ノード以外の各ノードは、
前記電子署名の送信元ノードの公開鍵で前記電子署名を検証し、
前記ユーザの公開鍵が改ざんされていないことを確認した後に、前記ユーザの公開鍵を前記公開鍵リストに登録する
ことを特徴とする請求項４または５に記載の通信方法。

【請求項7】

各ノードは、
前記ユーザの秘密鍵を使用して作成された電子署名を前記ユーザから受信したとき、前記公開鍵リストに登録されている前記ユーザの公開鍵を用いて前記電子署名を検証し、
前記電子署名に問題がなければ前記ユーザを認証する
ことを特徴とする請求項３～６のいずれか１つに記載の通信方法。

【請求項8】

複数のノードを含む通信システムにおいて使用される通信方法であって、
各ノードにおいて、
ユーザから前記ユーザのアカウント情報および前記ユーザの公開鍵を受信し、
前記アカウント情報の内容が正しいと判定されたときに、前記アカウント情報の内容が正しいことを表す登録可能メッセージを他のすべてのノードに送信し、
前記アカウント情報の内容が正しくないと判定されたときに、前記アカウント情報の内容が正しくないことを表す登録不可メッセージを他のすべてのノードに送信し、
他のノードから受信する登録可能メッセージの数および登録不可メッセージの数の和が第１の所定数以上であり、且つ、前記登録可能メッセージの数が第２の所定数を超えたことを検出すると、前記通信システムへの参加が許可されたユーザの公開鍵を保存する公開鍵リストに前記ユーザの公開鍵を登録する
ことを特徴とする通信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信装置、通信方法、および通信プログラムに係わる。

【背景技術】

【0002】

近年、仮想通貨を実現するための基盤としてブロックチェーン技術が注目されている。また、ブロックチェーン技術は、仮想通貨以外の分野への適用が検討されている。たとえば、企業間または組織間で情報を共有するためにブロックチェーンを利用するケースが注目されている。

【0003】

ブロックチェーン技術を利用するサービスの１つとして、限定されたユーザが参加するデータ流通市場が知られている。データ流通市場の参加者は、自分が保有するデータを市場に提供することができる。また、参加者は、市場に提供されているデータを取得または購入することができる。なお、限定されたユーザが参加するシステムにブロックチェーン技術を適用する形態は、コンソーシアム型ブロックチェーンと呼ばれることがある。

【0004】

コンソーシアム型ブロックチェーンシステムにおいては、認証局として動作する参加ノードがユーザを認証する。このとき、認証局は、例えば、電子証明書を用いてユーザを認証する。

【0005】

例えば、システムへの参加を希望する新規ユーザは、認証局にアカウント情報を送信する。アカウント情報は、ユーザが所属する企業の名称、連絡先情報（住所、電話番号、Ｅメールアドレス等）を含む。そうすると、認証局は、アカウント情報の内容が正しいか否かを確認する。このとき、認証局は、例えば、下記の確認作業を行う。
（１）第３者のデータベースを参照し、その企業が実際に存在するか否かを確認する。
（２）その企業の代表番号に電話をかけて、アカウント情報の申請内容を確認する。
（３）その企業に郵便を送り、返送してもらう。
そして、アカウント情報の内容が正しければ、認証局は、電子証明書を発行する。

【0006】

なお、分散ファイル共有システムにおいて、ブロックチェーンアプリがユーザ／グループ認証、コンテンツの一意性の保証などを実行する方法が提案されている（例えば、特許文献１）。また、簡易かつ迅速に電子認証を行う技術が提案されている（例えば、特許文献２）。

【先行技術文献】

【特許文献】

【0007】

【文献】特開２０１８－０８１４６４号公報

【文献】ＷＯ２０１８／０８８４７５

【発明の概要】

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

【0008】

インターネットの世界では、認証局を運営する事業者は、一度でも信用を失うと、それ以降は事業の継続が困難になる。よって、このような認証局は、可能な限り厳密にユーザの検証を行う。これに対して、限られたユーザが参加するコンソーシアム型のシステムでは、認証局が不正を行いやすいことがある。例えば、悪意のある参加ノードが認証局として電子証明書を発行するおそれがある。

【0009】

複数の参加ノードの中の１つまたは少数の参加ノードが認証局として動作する場合、その参加ノードの負荷が重くなる。たとえば、上述のようなアカウント情報を確認する作業は、認証局として動作する参加ノードの管理者にとって大きな負担である。

【0010】

本発明の１つの側面に係わる目的は、システムに参加する複数のノードでユーザを認証する方法または構成を提供することである。

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

【0011】

本発明の１つの態様の通信方法は、複数のノードを含む通信システムにおいて使用される。前記複数のノードの中の２以上の認証ノードそれぞれにおいて、ユーザから前記ユーザのアカウント情報および前記ユーザの公開鍵を受信し、前記アカウント情報が正しいと判定されたときに、前記アカウント情報が正しいことを表すメッセージおよび前記ユーザの公開鍵を前記複数のノードに送信する。各ノードは、他のノードから受信するメッセージに基づいて所定数以上の認証ノードにおいて前記アカウント情報が正しいと判定されたことを検出すると、前記通信システムへの参加が許可されたユーザの公開鍵を保存する公開鍵リストに前記ユーザの公開鍵を登録する。

【発明の効果】

【0012】

上述の態様によれば、システムに参加する複数のノードでユーザを認証するので、不正なユーザ認証が抑制される。

【図面の簡単な説明】

【0013】

【図1】本発明の実施形態に係わる通信システムの一例を示す図である。

【図2】ユーザ登録手順の一例を示す図（その１）である。

【図3】ユーザ登録手順の一例を示す図（その２）である。

【図4】ユーザ登録手順の一例を示す図（その３）である。

【図5】ユーザ認証手順の一例を示す図である。

【図6】ユーザ登録およびユーザ認証のシーケンスの一例を示す図である。

【図7】１つの認証局により管理されるユーザ登録およびユーザ認証のシーケンスの一例を示す図である。

【図8】ユーザ登録からトランザクションの実行までのシーケンスの一例を示す図である。

【図9】ユーザ認証が失敗するケースのシーケンスの一例を示す図である。

【図10】ユーザ登録処理の一例を示すフローチャートである。

【図11】ユーザ認証処理の一例を示すフローチャートである。

【図12】各ノードに実装されるコンピュータのハードウェア構成の一例を示す図である。

【図13】他の実施形態に係わるユーザ登録手順の一例を示す図（その１）である。

【図14】他の実施形態に係わるユーザ登録手順の一例を示す図（その２）である。

【図15】認証ノードとして動作しないピアにおけるユーザ登録処理の一例を示すフローチャートである。

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

【0014】

図１は、本発明の実施形態に係わる通信システムの一例を示す。この実施例では、通信システム１００は、複数のノードを含む。各ノードには、それぞれ通信装置が設けられている。また、通信システム１００は、たとえば、データ流通サービスを提供する。この場合、各ノードには、データ流通サービスに参加するユーザの通信装置が設けられる。

【0015】

各通信装置は、他の任意の通信装置と通信することができる。したがって、以下の記載では、各ノードに設けられる通信装置を「ピア（Peer）」と呼ぶことがある。なお、図１に示す例では、通信システム１００は、ピアＡ、ピアＢ、ピアＣを含む。ピアＡは、ユーザＡにより使用される通信装置であり、ピアＢは、ユーザＢにより使用される通信装置であり、ピアＣは、ユーザＣにより使用される通信装置である。

【0016】

各ピアＡ～Ｃは、暗号通信を行うために、秘密鍵および公開鍵のペアを生成する。ここで、暗号通信においては、例えば、秘密鍵で暗号化されたデータは、対応する公開鍵で復号される。或いは、公開鍵で暗号化されたデータは、対応する秘密鍵で復号される。したがって、各ピアＡ～Ｃは、予め他のユーザの公開鍵を取得しているものとする。なお、各ピアＡ～Ｃは、自分の秘密鍵を保持している。

【0017】

各ピアＡ～Ｃは、図１に示すように、公開鍵リストを備える。公開鍵リストには、通信システム１００への参加が許可されたユーザの公開鍵が登録される。よって、ピアＡの公開鍵リストには、ユーザＢの公開鍵ＰＢｂおよびユーザＣの公開鍵ＰＢｃが登録されている。ピアＢの公開鍵リストには、ユーザＡの公開鍵ＰＢａおよびユーザＣの公開鍵ＰＢｃが登録されている。ピアＣの公開鍵リストには、ユーザＡの公開鍵ＰＢａおよびユーザＢの公開鍵ＰＢｂが登録されている。なお、図１に示す例では、各ピアの公開鍵リストには自分の公開鍵も登録されている。

【0018】

通信システム１００は、例えば、ブロックチェーンによりサポートされるデータ流通サービスを提供する。この場合、各ユーザまたは各ピアが要求するトランザクションは、通信システム１００内で合意が形成された後に実行される。

【0019】

ユーザＸは、通信システム１００が提供するサービスへの参加を要求する。通信システム１００は、ユーザＸの登録手続を実行する。

【0020】

図２～図４は、ユーザ登録手順の一例を示す。この実施例では、ユーザＸが通信システム１００への参加を要求する。なお、「ユーザＸ」は、ユーザＸにより使用される通信装置を表す。

【0021】

ユーザＸは、通信システム１００に参加している各ピアと暗号通信を行うために、秘密鍵および公開鍵のペアを生成する。そして、ユーザＸは、生成した秘密鍵および公開鍵のペアを保持する。

【0022】

続いて、ユーザＸは、図２に示すように、通信システム１００に既に参加している各ピアに登録申請情報を送信する。即ち、ユーザＸから各ピアＡ～Ｃに登録申請情報が送信される。登録申請情報は、ユーザＸのアカウント情報およびユーザＸの公開鍵を含む。このアカウント情報は、例えば、ユーザＸが所属する企業の名称、ユーザＸの連絡先情報（住所、電話番号、Ｅメールアドレス等）を含む。

【0023】

各ピアＡ～Ｃは、新規ユーザ（すなわち、ユーザＸ）から登録申請情報を受信すると、認証局（または、認証ノード）として動作する。具体的には、各ピアＡ～Ｃは、受信した登録申請情報に含まれるアカウント情報が正しいか否かを確認する。すなわち、各ピアＡ～Ｃは、アカウント情報に基づいて、ユーザＸが正規のユーザであるか否かを判定する。以下の記載では、この確認作業を「実在確認」と呼ぶことがある。

【0024】

実在確認は、例えば、各ピアＡ～Ｃのユーザ（または、管理者）により実施される。この場合、実在確認は、例えば、下記の作業のうちの１つ以上を含む。
（１）第３者のデータベースを参照し、アカウント情報に記載されている企業が実際に存在するか否かを確認する。
（２）アカウント情報に記載されている企業の代表番号に電話をかけ、アカウント情報の記載内容を確認する。
（３）アカウント情報に記載されている企業に郵便を送り、返送してもらう。

【0025】

各ピアＡ～Ｃは、図３に示すように、実在確認の結果（以下、検証結果）を他のすべてのピアに通知する。すなわち、各ピアＡ～Ｃは、アカウント情報が正しいか否かを表すメッセージを他のすべてのピアに送信する。例えば、ピアＡによる検証結果はピアＢ、Ｃに送信され、ピアＢによる検証結果はピアＡ、Ｃに送信され、ピアＣによる検証結果はピアＡ、Ｂに送信される。検証結果は、ユーザＸのアカウント情報が正しいか否かを表す。

【0026】

また、各ピアＡ～Ｃは、自分が行った実在確認においてユーザＸのアカウント情報が正しいことが確認されたときには、検証結果と共に、ユーザＸの公開鍵を他のピアに送信する。このとき、各ピアＡ～Ｃは、ユーザＸの公開鍵に電子署名を添付する。例えば、ピアＡは、ピアＡの秘密鍵を用いて電子署名を作成する。具体的には、ピアＡは、例えば、ユーザＸの公開鍵のハッシュ値を計算し、ピアＡの秘密鍵でこのハッシュ値を暗号化することにより電子署名を作成する。そして、ピアＡは、この電子署名が添付されたユーザＸの公開鍵をピアＢ、Ｃに送信する。同様に、ピアＢは、ピアＢの秘密鍵を用いて作成した電子署名をユーザＸの公開鍵に添付してピアＡ、Ｃに送信する。ピアＣは、ピアＣの秘密鍵を用いて作成した電子署名をユーザＸの公開鍵に添付してピアＡ、Ｂに送信する。

【0027】

なお、各ピアＡ～Ｃは、自分が行った実在確認においてユーザＸのアカウント情報が正しくないことが確認されたときには、ユーザＸの公開鍵の送信を行わない。この場合、アカウント情報が正しくないことを表す検証結果のみが送信される。

【0028】

各ピアＡ～Ｃは、自分自身による検証結果および他のピアから受信する検証結果に基づいて、ユーザＸを通信システム１００に参加させるか否かについて合意形成を行う。例えば、ピアＡは、ピアＡ自身による検証結果、ピアＢから受信した検証結果、およびピアＣから受信した検証結果に基づいて、ユーザＸを通信システム１００に参加させるか否かを判定する。

【0029】

合意形成は、通信システム１００において事前に決められている合意ポリシに従う。合意ポリシの例を下記に記載する。
（１）所定数以上のピアによりアカウント情報が正しいと判定されたときに、そのアカウント情報が正しいと判定する。
（２）合意形成に係わるピアの総数に対して所定の割合以上のピアによりアカウント情報が正しいと判定されたときに、そのアカウント情報が正しいと判定する（例えば、多数決による判定）。
（３）合意形成に係わる全ピアによりアカウント情報が正しいと判定されたときに、そのアカウント情報が正しいと判定する。

【0030】

なお、合意ポリシ１、２において、ピアの数は、自分自身を含むものとする。また、合意ポリシ２において、「合意形成に係わるピアの総数」は既知なので、所定の割合は、アカウント情報が正しいを判定したピアの数に一意に対応する。よって、合意ポリシ２は、実質的には、合意ポリシ１の一例である。また、合意ポリシ３において、合意形成に係わる全ピアの数を合意ポリシ１の「所定数」と考えると、合意ポリシ３も、実質的には、合意ポリシ１の一例である。

【0031】

以下の記載では、各ピアＡ～ＣにおいてユーザＸのアカウント情報が正しいと判定されたものとする。また、各ピアＡ～Ｃにおいて合意ポリシ１が使用される。ここで、合意ポリシ１において、所定数は「２」であるものとする。

【0032】

ピアＡは、図４に示すように、ユーザＸが通信システム１００に参加することについて合意が形成されたか否かを判定する。この実施例では、すべてのピアＡ～ＣにおいてユーザＸのアカウント情報が正しいと判定されている。すなわち、３個のピアによりユーザＸのアカウント情報が正しいと判定されている。したがって、ピアＡは、合意ポリシ１に従い、ユーザＸが通信システム１００に参加することを許可する。そして、ピアＡは、自分の公開鍵リストにユーザＸの公開鍵ＰＫｘを登録する。同様に、ピアＢ、Ｃも、それぞれ自分の公開鍵リストにユーザＸの公開鍵ＰＫｘを登録する。

【0033】

なお、ユーザ登録の信頼性を高めるためには、各ピアＡ～Ｃは、ユーザＸの公開鍵が改ざんされていないことを検証してもよい。例えば、図３に示すように、ピアＡは、ピアＢの電子署名が添付されたユーザＸの公開鍵ＰＫｘをピアＢから受信している。ここで、この電子署名は、公開鍵ＰＫｘのハッシュ値をピアＢの秘密鍵で暗号化することで生成されている。よって、ピアＡは、ピアＢの電子署名をピアＢの公開鍵で復号することで、ピアＢから受信した公開鍵ＰＢｘが改ざんされていないことを確認できる。同様に、ピアＡは、ピアＣの電子署名をピアＣの公開鍵で復号することにより、ピアＣから受信した公開鍵ＰＢｘが改ざんされていないことを確認できる。そして、ピアＡは、ユーザＸから受信した公開鍵ＰＢｘ、ピアＢから受信した公開鍵ＰＢｘ、ピアＣから受信した公開鍵ＰＢｘがすべて一致したときに、自分の公開鍵リストに公開鍵ＰＫｘを登録する。ピアＢ、Ｃも同様の手順で自分の公開鍵リストに公開鍵ＰＫｘを登録する。

【0034】

このように、本発明の実施形態に係わる通信方法においては、複数のピアの合意に基づいて新規ユーザの登録が許可される。したがって、新規ユーザ登録に係わる不正が抑制される。

【0035】

図５は、ユーザ認証手順の一例を示す。なお、この実施例では、図２～図４に示すユーザ登録手順は完了しているものとする。すなわち、各ピアＡ～Ｃの公開鍵リストには、ユーザＸの公開鍵ＰＢｘが登録されている。

【0036】

ユーザＸは、通信システム１００を使用する通信を行うときは、通信システム１００の各ピア（すなわち、ピアＡ～Ｃ）にユーザＸを認証してもらう必要がある。したがって、ユーザＸは、ユーザＸのＩＤ情報およびユーザＸの電子署名を各ピアＡ～Ｃに送信する。なお、電子署名は、例えば、擬似乱数および暗号化擬似乱数を含む。この場合、擬似乱数は、ユーザＸにより生成される。また、この擬似乱数のハッシュ値をユーザＸの秘密鍵で暗号化することで、暗号化擬似乱数が生成される。

【0037】

各ピアＡ～Ｃは、ユーザＸから受信する電子署名を検証する。例えば、ピアＡは、電子署名と共に受信するＩＤ情報に基づいて、その電子署名の送信元がユーザＸであると判定する。続いて、ピアＡは、自分の公開鍵リストからユーザＸの公開鍵ＰＢｘを取得する。そして、ピアＡは、電子署名に含まれる暗号化擬似乱数をユーザＸの公開鍵ＰＢｘで復号することにより、ユーザＸを認証する。具体的には、電子署名に含まれる擬似乱数のハッシュ値と、電子署名に含まれる暗号化擬似乱数をユーザＸの公開鍵ＰＢｘで復号した結果とが一致すれば、ユーザＸが正規の参加者であると判定される。ピアＢ、Ｃも、同様の手順でユーザＸを認証する。

【0038】

図６は、ユーザ登録およびユーザ認証のシーケンスの一例を示す。なお、通信システム１００は、図１に示すように、ピアＡ～Ｃを備えるものとする。

【0039】

Ｓ１において、ユーザＸは、ピアＡ～Ｃに登録申請情報を送信する。登録申請情報は、上述したように、ユーザＸのアカウント情報およびユーザＸの公開鍵を含む。

【0040】

Ｓ２において、各ピアＡ～Ｃは、ユーザＸの実在確認を行う。すなわち、各ピアＡ～Ｃは、ユーザＸから受信したアカウント情報が正しいか否かを確認する。

【0041】

Ｓ３において、各ピアＡ～Ｃは、実在確認の結果を表すメッセージを他のピアに送信する。このとき、各ピアＡ～Ｃは、メッセージと共に、ユーザＸの公開鍵に自分の電子署名を添付して他のピアに送信してもよい。

【0042】

Ｓ４において、各ピアＡ～Ｃは、事前に決められている合意ポリシに従って、ユーザＸのアカウント情報が正しいか否かを判定する。そして、通信システム１００にユーザＸが参加することについて合意が形成されると、各ピアＡ～Ｃは、自分の公開鍵リストにユーザＸの公開鍵ＰＢｘを登録する。これにより、通信システム１００（すなわち、各ピアＡ～Ｃ）へのユーザ登録が完了する。

【0043】

Ｓ１１において、ユーザＸは、ユーザＸの秘密鍵を使用して電子署名を作成する。そして、ユーザＸは、作成した電子署名をピアＡ～Ｃに送信する。

【0044】

Ｓ１２において、各ピアＡ～Ｃは、ユーザＸから受信する電子署名を検証することにより、ユーザＸのＩＤ確認を実行する。このとき、各ピアＡ～Ｃは、ユーザ登録において取得したユーザＸの公開鍵ＰＢｘを用いて電子署名を検証する。これにより、各ピアＡ～Ｃによるユーザ認証が完了する。

【0045】

図７は、１つの認証局により管理されるユーザ登録およびユーザ認証のシーケンスの一例を示す。このケースでは、ユーザＸは、認証局ＣＡに登録申請情報を送信する。この登録申請情報は、ユーザＸのアカウント情報を含むが、ユーザＸの公開鍵を含まなくてもよい。そして、認証局ＣＡは、ユーザＸの実在確認を行った後、ユーザ証明書を発行してユーザＸに送信する。このように、１つの認証局によりユーザ登録が管理されるシステムでは、認証局ＣＡが不正にユーザ登録を行うことが可能である。なお、本発明の実施形態においては、図６に示すように、複数のピアの合意に基づいてユーザ登録が行われるので、不正なユーザ登録は困難である。

【0046】

図７において、ユーザ認証時には、ユーザＸは、認証局ＣＡにより発行されたユーザ証明書をピアＡ～Ｃに送信する。そうすると、各ピアＡ～Ｃは、そのユーザ証明書の検証を認証局ＣＡに依頼する。このように、１つの認証局によりユーザ登録が管理されるシステムでは、認証局ＣＡの負荷が大きい。

【0047】

図８は、ユーザ登録から処理の実行までのシーケンスの一例を示す。なお、ユーザ登録手続は、図６および図８において実質的に同じなので、説明を省略する。

【0048】

Ｓ１１において、ユーザＸは、電子署名およびトランザクション（Ｔｘ）をピアＡ～Ｃに送信する。トランザクションは、実行すべき通信処理の内容を表す。

【0049】

Ｓ１２において、各ピアＡ～Ｃは、ユーザＸから受信する電子署名を検証する。この実施例では、ユーザＸは、Ｓ１～Ｓ４において、正規のユーザとして各ピアＡ～Ｃに登録されている。すなわち、各ピアＡ～Ｃにおいて、ユーザＸの認証が成功する。そうすると、各ピアＡ～Ｃは、Ｓ１３において、ユーザＸから受信したトランザクションを実行する。この後、トランザクションの実行結果についての合意が形成されると、Ｓ１４において、トランザクションの実行結果が確定する。

【0050】

図９は、ユーザ認証が失敗するケースのシーケンスの一例を示す。この実施例では、ピアＡが不正な認証ノードとして動作するものとする。また、ユーザＸは、ピアＡと連携して通信システム１００への参加を試みるものとする。

【0051】

Ｓ１において、ユーザＸは、ピアＡ～Ｃに登録申請情報を送信する。ただし、このアカウント情報は、正しくない情報を含んでいるものとする。

【0052】

Ｓ２～Ｓ３において、各ピアＡ～Ｃは、ユーザＸの実在確認を行う。ここで、アカウント情報は正しくない情報を含んでいるので、ピアＢ、Ｃにおいて、実在確認は失敗する。したがって、ピアＢ、Ｃは、アカウント情報が正しくないことを表すメッセージをそれぞれ他のピアに送信する。一方、ピアＡは、アカウント情報が正しくないにもかかわらず、アカウント情報が正しいことを表すメッセージをピアＢ、Ｃに送信する。

【0053】

Ｓ４において、各ピアＡ～Ｃは、合意ポリシに従って、ユーザＸを登録するか否かを判定する。ここで、アカウント情報が正しいことを表す検証結果は１つだけである。したがって、ピアＢ、Ｃは、ユーザＸを登録しない。一方、ピアＡは、検証結果が合意ポリシを満足しないにもかかわらず、ユーザＸを不正に登録するものとする。

【0054】

Ｓ１１において、ユーザＸは、電子署名およびトランザクション（Ｔｘ）をピアＡ～Ｃに送信する。Ｓ１２において、各ピアＡ～Ｃは、ユーザＸから受信する電子署名を検証する。ピアＡにおいては、ユーザＸが登録されている。したがって、Ｓ１３において、ピアＡは、ユーザＸから受信したトランザクションを実行する。これに対して、ピアＢ、Ｃにおいては、ユーザＸは登録されていない。したがって、ピアＢ、Ｃは、ユーザＸから受信したトランザクションを実行しない。

【0055】

このように、ユーザＸのトランザクションは、ピアＡにより実行されるが、他のピアによっては実行されない。そうすると、トランザクションの実行結果についての合意が形成されず、トランザクションの実行結果は確定しない。したがって、不正なユーザによるトランザクションの実行が回避される。

【0056】

図１０は、各ピアにおいて実行されるユーザ登録処理の一例を示すフローチャートである。このフローチャートの処理は、図２～図４に示す例では、ピアＡ～Ｃによりそれぞれ実行される。以下の記載では、各ノードに設けられる通信装置がユーザ登録処理を実行するものとする。

【0057】

Ｓ２１において、通信装置は、新規ユーザからの登録申請を待ち受ける。そして、登録申請を受信すると、Ｓ２２～Ｓ２３において、新規ユーザのアカウント情報が正しいか否かの検証が行われる。なお、Ｓ２２～Ｓ２３の処理は、例えば、人手により行われる。この場合、この検証結果は、通信装置に与えられる。

【0058】

アカウント情報が正しいときは、Ｓ２４において、通信装置は、登録許可を表すメッセージを他のノードに送信する。このとき、通信装置は、このメッセージと共に、新規ユーザの公開鍵に電子署名を添付して他の通信装置に送信してもよい。一方、アカウント情報が正しくないときは、Ｓ２５において、通信装置は、登録不可を表すメッセージを他のノードに送信する。なお、Ｓ２４～Ｓ２５において送信されるメッセージは、図３に示す検証結果に相当する。この後、通信装置は、Ｓ２６において、他の通信装置から送信されるメッセージを待ち受ける。

【0059】

通信装置は、所定数以上のメッセージを受信すると、Ｓ２７において、新規ユーザを登録するか否かを判定する。所定数は、新規ユーザを登録するか否かを判定するために十分な数を表す。また、新規ユーザを登録するか否かは、予め決められた合意ポリシに従う。そして、新規ユーザを登録する場合には、通信装置は、Ｓ２８において、自分の公開鍵リストに新規ユーザの公開鍵を登録する。

【0060】

図１１は、各ピアにおいて実行されるユーザ認証処理の一例を示すフローチャートである。以下の記載では、ユーザＸが各通信装置に電子署名およびトランザクションを送信するものとする。

【0061】

Ｓ３１において、通信装置は、ユーザＸから電子署名およびトランザクションを受信する。Ｓ３２において、通信装置は、電子署名の送信元（すなわち、ユーザＸ）の公開鍵が自分の公開鍵リストに登録されているか判定する。

【0062】

ユーザＸの公開鍵が公開鍵リストに登録されているときは、通信装置は、Ｓ３３～Ｓ３４において、受信した電子署名をユーザＸの公開鍵で検証する。そして、電子署名の検証が成功したときは、通信装置は、Ｓ３５において、ユーザＸから受信したトランザクションを実行する。なお、ユーザＸの公開鍵が公開鍵リストに登録されていないとき、又は、電子署名の検証が失敗したときは、通信装置は、ユーザＸから受信したトランザクションを実行しない。

【0063】

図１２は、各ノードに実装されるコンピュータのハードウェア構成の一例を示す。このコンピュータ３００は、プロセッサ３０１、メモリ３０２、記憶装置３０３、Ｉ／Ｏデバイス３０４、記録媒体デバイス３０５、通信インタフェース３０６を備える。なお、各ピアは、図１２に示すコンピュータにより実現され得る。

【0064】

プロセッサ３０１は、記憶装置３０３に格納されている通信プログラムを実行することにより、ユーザ登録およびユーザ認証を実現することができる。なお、ユーザ登録においては、プロセッサ３０１は、図１０に示すフローチャートの処理を記述した通信プログラムを実行する。ユーザ認証においては、プロセッサ３０１は、図１１に示すフローチャートの処理を記述した通信プログラムを実行する。

【0065】

メモリ３０２は、例えば半導体メモリであり、プロセッサ３０１の作業領域として使用される。記憶装置３０３は、コンピュータ３００内に実装されていてもよいし、コンピュータ３００に接続されていてもよい。公開鍵リストは、メモリ３０２または記憶領域３０３に保存される。Ｉ／Ｏデバイス３０４は、ユーザまたはネットワーク管理者の指示を受け付ける。また、Ｉ／Ｏデバイス３０４は、プロセッサ３０１による処理結果を出力してもよい。記録媒体デバイス３０５は、可搬型記録媒体３０７に記録されている信号を読み取る。なお、上述の通信プログラムは、可搬型記録媒体３０７に記録されていてもよい。通信インタフェース３０６は、ネットワークとの間のインタフェースを提供する。

【0066】

なお、説明の簡素化のため図示していないが、ユーザＸが通信システム１００への参加が認められた場合には、ユーザＡ～ＣおよびユーザＸの公開鍵がユーザＸのノード（ピア）の公開鍵リストに登録される。また、ユーザＸは、ピアＡ～Ｃを利用するユーザが通信を行う際の認証局の一つとして機能してもよい。

【0067】

＜他の実施形態＞
図１３～図１４は、本発明の他の実施形態に係わるユーザ登録手順の一例を示す。この実施例では、通信システム２００は、ピアＡ～Ｅを備える。そして、図２～図４に示す例と同様に、ユーザＸが通信システム２００への参加を要求する。

【0068】

図２～図４に示す例では、通信システム１００に参加するすべてのピアが認証ノードとして動作する。これに対して、図１３～図１４に示す実施形態では、通信システム２００に参加するピアの一部が認証ノードとして動作する。ここでは、ピアＡ～Ｅのうち、ピアＡ～Ｃが認証ノードとして動作する。

【0069】

ユーザＸは、図１３に示すように、認証ノードとして動作するピアＡ～Ｃに登録申請情報を送信する。すなわち、ユーザＸから各ピアＡ～Ｃに登録申請情報が送信される。

【0070】

各ピアＡ～Ｃは、新規ユーザ（すなわち、ユーザＸ）から登録申請情報を受信すると、認証ノードとして動作する。すなわち、各ピアＡ～Ｃは、実在確認を実行する。具体的には、各ピアＡ～Ｃは、受信した登録申請情報に含まれるアカウント情報が正しいか否かを確認する。そして、この実施例では、ピアＡ、Ｂにおいて、それぞれユーザＸのアカウント情報が正しいと判定され、ピアＣにおいて、ユーザＸのアカウント情報が正しくないと判定されるものとする。

【0071】

各ピアＡ～Ｃは、ユーザＸのアカウント情報の検証結果を表すメッセージを全ノードに送信する。検証結果は、上述したように、ユーザＸのアカウント情報が正しいか否かを表す。なお、以下の記載においては、アカウント情報が正しいときに送信される検証結果を「登録ＯＫメッセージ」と呼び、アカウント情報が正しくないときに送信される検証結果を「登録ＮＧメッセージ」と呼ぶことがある。

【0072】

ピアＡは、登録ＯＫメッセージをピアＢ、Ｃ、Ｄ、Ｅに送信する。ピアＢは、登録ＯＫメッセージをピアＡ、Ｃ、Ｄ、Ｅに送信する。ピアＣは、登録ＮＧメッセージをピアＡ、Ｂ、Ｄ、Ｅに送信する。なお、図１４において、実線矢印は、登録ＯＫメッセージの伝送を表す。破線矢印は、登録ＮＧメッセージの伝送を表す。

【0073】

また、各ピアＡ～Ｃは、自ノードにおいてユーザＸのアカウント情報が正しいと判定されたときは、登録ＯＫメッセージと共に、ユーザＸの登録申請情報（即ち、ユーザＸのアカウント情報およびユーザＸの公開鍵）を全ノードに送信する。図１４に示す例では、ピアＡ、Ｂは、登録ＯＫメッセージと共に、ユーザＸの登録申請情報を全ノードに送信している。

【0074】

このとき、登録申請情報には、電子署名が添付される。例えば、ピアＡは、登録申請情報に対してハッシュ値を計算し、このハッシュ値をピアＡの秘密鍵で暗号化することで電子署名を作成する。そして、ピアＡは、登録申請情報に電子署名を添付して全ノードに送信する。同様に、ピアＢは、登録申請情報にピアＢの秘密鍵を使用して作成した電子署名を添付して全ノードに送信する。

【0075】

各ピアＡ～Ｅは、図２～図４に示す実施例と同様に、事前に決定されている合意ポリシに従って、通信システム２００にユーザＸが参加することを許可するか否かを判定する。この実施例では、「２以上のピアにおいてユーザＸのアカウント情報が正しいと判定されたときは、通信システム２００にユーザＸが参加することを許可する」という合意ポリシが使用されるものとする。

【0076】

ピアＡにおいては、ユーザＸのアカウント情報が正しいと判定されている。また、ピアＡは、ピアＢから登録ＯＫメッセージを受信している。すなわち、２つのピアにおいてユーザＸのアカウント情報が正しいと判定されている。よって、ピアＡは、通信システム２００にユーザＸが参加することを許可し、自分の公開鍵リストにユーザＸの公開鍵を登録する。

【0077】

ピアＢにおいては、ユーザＸのアカウント情報が正しいと判定されている。また、ピアＢは、ピアＡから登録ＯＫメッセージを受信している。すなわち、２つのピアにおいてユーザＸのアカウント情報が正しいと判定されている。よって、ピアＢも、通信システム２００にユーザＸが参加することを許可し、自分の公開鍵リストにユーザＸの公開鍵を登録する。

【0078】

ピアＣにおいては、ユーザＸのアカウント情報が正しくないと判定されている。ところが、ピアＣは、ピアＡおよびピアＢから登録ＯＫメッセージを受信している。すなわち、２つのピアにおいてユーザＸのアカウント情報が正しいと判定されている。よって、ピアＣも、通信システム２００にユーザＸが参加することを許可し、自分の公開鍵リストにユーザＸの公開鍵を登録する。

【0079】

ピアＤ、Ｅは、ピアＡおよびピアＢから登録ＯＫメッセージを受信している。よって、ピアＤ、Ｅは、通信システム２００にユーザＸが参加することを許可する。この場合、ピアＤ、Ｅは、ピアＡまたはピアＢから受信した登録申請情報を確認する。

【0080】

例えば、ピアＤは、ピアＡから受信した登録申請情報を確認するものとする。ここで、ピアＡから受信した登録申請情報には、ピアＡの電子署名が添付されている。ピアＡの電子署名は、登録申請情報のハッシュ値をピアＡの秘密鍵で暗号化することで作成されている。したがって、ピアＤは、受信した登録申請情報のハッシュ値を計算する。また、ピアＤは、受信した電子署名をピアＡの公開鍵を復号する。そして、登録申請情報のハッシュ値と電子署名の復号結果とが一致すれば、ピアＤは、ピアＡから受信した登録申請情報が改ざんされていないと判定する。

【0081】

ピアＤ、Ｅは、ユーザＸの登録申請情報が改ざんされないことを確認すると、その登録申請情報に含まれているユーザＸの公開鍵を、自分の公開鍵リストに登録する。これにより、ピアＤ、Ｅの公開鍵リストにそれぞれユーザＸの公開鍵が登録される。

【0082】

なお、図１３～図１４に示す例では、ピアＣは、ユーザＸのアカウント情報は正しくないと判定している。したがって、ピアＣは、合意ポリシに従わず、通信システム２００にユーザＸが参加することを許可しない可能性がある。この場合、ピアＣは、ユーザＸの認証要求を拒否することになる。ところが、複数の参加者の合意に基づいて各トランザクションの実行および確定が行われるシステム（例えば、ブロックチェーンネットワーク）においては、ピアＣがユーザＸの認証を拒否しても、他の多くのピアがユーザＸを認証すれば、ユーザＸのトランザクションは実行され得る。

【0083】

図１５は、認証ノードとして動作しないピアにおけるユーザ登録処理の一例を示すフローチャートである。このフローチャートの処理は、図１３～図１４に示す例では、ピアＤ、Ｅにより実行される。

【0084】

Ｓ２６～Ｓ２７の処理は、認証ノードとして動作するピアおよび認証ノードとして動作しないピアにおいて実質的に同じである。すなわち、認証ノードとして動作しない通信装置も、新規ユーザを登録するか否かを判定する。なお、認証ノードとして動作する通信装置は、新規ユーザのアカウント情報が正しいと判定したときは、登録ＯＫメッセージと共に、新規ユーザの登録申請情報を送信する。この登録申請情報には、電子署名が添付されている。

【0085】

新規ユーザを登録すると判定したときは、通信装置は、Ｓ４１～Ｓ４２において、受信した登録申請情報が改ざんされていないかを確認する。そして、受信した登録申請情報が改ざんされてなければ、通信装置は、Ｓ２８において、自分の公開鍵リストに新規ユーザの公開鍵を登録する。

【0086】

ユーザ認証は、図５または図１１に示す手順と実質的に同じである。すなわち、ユーザＸは、通信システム２００を使用するときは、ピアＡ～Ｅに電子署名を送信する。各ピアＡ～Ｅは、自分の公開鍵リストに登録されているユーザＸの公開鍵でその電子署名を検証する。そして、電子署名の検証が成功すれば（即ち、ユーザＸの公開鍵が公開鍵リストに登録されていれば）、ユーザＸのトランザクションが実行される。

【符号の説明】

【0087】

１００、２００ 通信システム
３０１ プロセッサ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】