JPWO2019163040A1 - アクセス管理システム、及びそのプログラム - Google Patents

Abstract

暗号化ベースのアクセス制御において、耐障害性を向上させることができる。トランザクションが管理される分散型データベースにアクセス可能なコンピュータを、第１ユーザのアクセス権限を示すための第１鍵であって、分散型データベースにおいて第１ユーザに関連づけられていない第１鍵を取得する取得手段、第１鍵の検証を行う検証手段、第１鍵に関する情報を、分散型データベースにアクセス可能な１以上の第２ユーザのコンピュータと共有する共有手段、第１鍵の情報と、第１ユーザのデジタル署名とを含み、第１鍵の使用の承認を依頼する第１トランザクションを生成する生成手段、及び第１トランザクションが、１以上の第２ユーザにデジタル署名され、分散型データベースに登録されるために、第１トランザクションを１以上の第２ユーザのコンピュータに送信する送信手段、として機能させる。

Description

本発明は、アクセス管理システム、及びそのプログラム等に関する。

近年、アクセス制御の方法として、暗号化ベースの制御方法が注目されている。暗号化ベースのアクセス制御方法では、アクセスが許可される主体のみが復号可能にデータが暗号化され、当該データの復号可否に基づいて、主体の権限の検証が行われる（例えば非特許文献１）。

S. Kamara and K. Lauter, "Cryptographic cloud storage," in Proc. FC 2010, Jan. 2010, pp. 136-149

非特許文献１をはじめとする従来の暗号化ベースのアクセス制御方法では、認証局（ＣＡ：Certificate Authority）等の中央サーバが、アクセス制御用の暗号鍵や復号鍵を発行する。したがって、従来の暗号化ベースのアクセス制御方法によって管理されるシステムでは、システムの信頼性は、中央サーバの信頼度に依存することになる。このようなシステムでは、中央サーバが乗っ取られると、中央サーバの信頼性に基づいて発行されたすべての鍵が信頼できなくなることから、中央サーバが単一障害点（ＳＰＯＦ：Single Point Of Failure）となってしまう。これを防ぐために中央サーバのセキュリティレベルを強化するには大きな費用がかかってしまう。

そこで、本発明は、上記事情に鑑み、暗号化ベースのアクセス制御において、耐障害性を向上させることを目的とするものである。

本発明によるプログラムは、トランザクションが管理される分散型データベースにアクセス可能なコンピュータを、第１ユーザのアクセス権限を示すための第１鍵であって、分散型データベースにおいて第１ユーザに関連づけられていない第１鍵を取得する取得手段、第１鍵の検証を行う検証手段、第１鍵に関する情報を、分散型データベースにアクセス可能な１以上の第２ユーザのコンピュータと共有する共有手段、第１鍵の情報と、第１ユーザのデジタル署名とを含み、第１鍵の使用の承認を依頼する第１トランザクションを生成する生成手段、及び第１トランザクションが、１以上の第２ユーザにデジタル署名され、分散型データベースに登録されるために、第１トランザクションを１以上の第２ユーザのコンピュータに送信する送信手段、として機能させる。

本発明のプログラムは、ＣＤ−ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又は通信ネットワークなどを介してダウンロードすることにより、コンピュータにインストール又はロードすることができる。

また、本明細書等において、「部」とは、単に物理的構成を意味するものではなく、その構成が有する機能をソフトウェアによって実現する場合も含む。また、１つの構成が有する機能が２つ以上の物理的構成により実現されても、２つ以上の構成の機能が１つの物理的構成により実現されてもよい。

本発明によれば、暗号化ベースのアクセス制御において、耐障害性を向上させることができる。

本発明の実施形態におけるアクセス管理システムの構成図である。 本発明の実施形態におけるノードの機能ブロックの一例を示す図である。 本発明の実施形態におけるトランザクションのデータ構造の一例を模式的に示す図である。 本発明の実施形態におけるトランザクションのデータ構造の一例を模式的に示す図である。 本発明の実施形態におけるトランザクションのデータ構造の一例を模式的に示す図である。 本発明の実施形態におけるノードの処理の流れの一例を示すフローチャートである。 本発明の実施形態におけるノードの機能ブロックの一例を示す図である。 本発明の実施形態におけるノードの処理の流れの一例を示すフローチャートである。 本発明の実施形態におけるユーザ認証の仕組みを模式的に示す図である。 本発明の実施形態における端末のハードウェア構成の一例を示す図である。

［第１の実施形態］
以下、本発明の実施の形態の１つについて詳細に説明する。なお、以下の実施の形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。また、本発明は、その要旨を逸脱しない限り、さまざまな変形が可能である。さらに、当業者であれば、以下に述べる各要素を均等なものに置換した実施の形態を採用することが可能であり、かかる実施の形態も本発明の範囲に含まれる。

＜１．システム構成の概要＞
図１は、本発明に係るアクセス管理システム１のシステム構成の一例を示している。アクセス管理システム１は、暗号化ベースのアクセス制御に用いられる鍵への操作の管理を行う。鍵は、暗号化ベースのアクセス制御において、ユーザのアクセス権限を示す情報として用いられる。本実施形態では、アクセス管理システム１で用いられる鍵は、公開鍵暗号方式における公開鍵及び秘密鍵である。ただし、アクセス管理システム１において用いられる鍵の暗号方式は、公開鍵暗号方式に限定されず、例えば共通鍵暗号方式でもよい。

鍵への操作は、鍵の生成、更新、又は失効を含む。アクセス管理システム１では、あるユーザ（操作者）が鍵に対して操作を行う場合、他の１以上のユーザ（承認者）が承認を行う。ここで、「鍵への操作を承認する」とは、鍵への操作が生成・更新である場合、使用される鍵を承認することであり、鍵への操作が失効である場合、失効操作を承認することである。１以上の承認者が、鍵への操作を承認することで、鍵の信頼性をユーザが相互に担保することが可能となる。これにより、アクセス管理システム１においては、一部の承認者の信頼性が損なわれたとしても、他の承認者の信頼性に基づいて、システム全体の信頼性を継続することができる。

さらにアクセス管理システム１では、承認者は、固定のユーザである必要はなく、操作対象の鍵の所有者に応じて異なってもよく、また、鍵の所有者が同一であっても、鍵への操作のたびに異なるユーザが承認者になってもよい。この結果、ある承認者の信頼性が損なわれたとしても、影響範囲を、信頼性が損なわれた承認者にのみ承認された鍵に限定することができる。これによって、システム全体としては、信頼性を継続することができる。

図１に示すように、アクセス管理システム１は、インターネット等のネットワークＮに接続された複数のノード１０Ａ、１０Ｂ、１０Ｃ（以下、これらのノードをまとめて単に「ノード１０」とも呼ぶ。）と、データベース３０とを備えている。図１の例では、一例として３つのノードを記載しているが、ノードの数に限定はない。

ネットワークＮは、無線ネットワークや有線ネットワークにより構成される。通信ネットワークの一例としては、携帯電話網や、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙ−ｐｈｏｎｅ Ｓｙｓｔｅｍ）網、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、４Ｇ（４ｔｈ Ｇｅｎｅｒａｔｉｏｎ ）、ＷｉＭａｘ（登録商標）、赤外線通信、Ｂｌｕｅｔｏｏｔｈ（登録商標）、有線ＬＡＮ、電話線、電灯線ネットワーク、ＩＥＥＥ１３９４等に準拠したネットワークがある。

ノード１０は、ネットワークＮに接続されたコンピュータであり、アクセス管理システム１が提供する所定のアプリケーションがインストールされている。なお、所定のアプリケーションは、ノード１０にあらかじめインストールされていてもよいし、ダウンロード等によってノード１０に事後的にインストールされてもよい。

典型的には、ノード１０は、携帯電話やスマートフォン、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、タブレット、ウェアラブル（Ｗｅａｒａｂｌｅ）端末、サーバ装置、ゲーム機等である。ノード１０Ａ、１０Ｂ、及びノード１０Ｃは、ネットワークＮを介して互いにＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）接続されており、分散型台帳システムを構成している。もっとも、ノード１０は分散型台帳システムにアクセス可能に構成されていればよく、必ずしも分散型台帳システムを構成する態様に限定されない。なお、各ノードはネットワークＮを介さずに直接Ｐ２Ｐ接続されてもよい。

以下の説明では、ノード１０Ａ，１０Ｂ，１０Ｃのユーザを、それぞれユーザＡ，Ｂ，Ｃとする。ユーザＡ，Ｂ，Ｃのそれぞれにはアクセス管理システム１で一意な識別子が割り当てられている。識別子は、例えば、ユーザがアクセス管理システム１に登録を行う場合に付与される一意な識別子や、メールアドレス、ノードの識別子、ノードにインストールされるアプリケーションにより識別されるＩＤ等である。

一例として、ユーザＡを操作者、ノード１０Ａを操作ノードとし、ユーザＢ，Ｃを承認者、ノード１０Ｂ，１０Ｃを承認ノードとして説明する。なお、操作ノードと承認ノードとは別ノードである必要はなく、単一のノードが操作ノードと承認ノードとの双方の機能を有する構成でもよい。また、各ノードのユーザは一人に限定されず、１つのノードが複数のユーザによって共有されてもよい。

データベース３０は、本実施形態ではネットワークＮに接続される、ストレージ管理用のサーバに構築される。なお、これに限定されず、データベース３０は、例えばネットワークＮに接続されるＷＥＢサーバ上に構築されてもよい。

なお、本実施形態では、アクセス管理システム１の各構成は、ネットワークＮを介して接続される例を説明するが、これに限定されない。例えば、ノード１０はプライベートなネットワークに接続され、データベース３０はノード１０が接続されるプライベートなネットワークとインターネットを介して接続される構成でもよい。同様に、ノード１０はインターネットを介して接続され、データベース３０はインターネットに接続可能なプライベートなネットワークに接続される構成でもよい。

＜２．データベース３０＞
データベース３０には、アクセス管理システム１において管理される鍵の情報が登録されている。一例として、データベース３０には、公開鍵と、暗号化された秘密鍵と、が対応付けられたレコードが登録されている。この場合には、後述するトランザクションには公開鍵と、暗号化された秘密鍵のハッシュ値が含まれることが好ましい。なお、後述するように、トランザクションに公開鍵の本体が含まれる場合には、データベース３０はなくてもよい。また、データベース３０の各レコードは、鍵の所有者であるユーザの識別子や、登録されている鍵に操作を行ったトランザクションのＩＤ、ユーザの信頼度を示す情報等を含んでもよい。ユーザの信頼度を示す情報は、例えば、アクセス管理システム１においてそのユーザが過去に不正を行ったか等を示す情報である。さらに、データベース３０には、公開鍵や秘密鍵の識別子が管理される構成でもよい。

＜３．ノード１０＞
＜３−１．操作ノード（ノード１０Ａ）＞
次に、図２を用いて操作ノードであるノード１０Ａの機能構成について説明する。図２は、本実施形態に係るノード１０Ａの機能ブロック図である。図２に示すように、ノード１０Ａは、記憶部１３０と、鍵取得部１１１と、鍵検証部１１２と、トランザクション生成部１１４と、署名実行部１１５と、データベース制御部１１６と、を有している。さらに、図２に示すように、記憶部１３０には、ユーザＡの秘密鍵と、分散型台帳１３１が記録されている。分散型台帳１３１は、分散型台帳システムを構成する複数のノード１０に格納される分散型データベースである。ただし、すべてのノード１０が分散型台帳１３１を有している必要はなく、一部のノード１０のみが分散型台帳１３１を有している構成でもよい。

（１）分散型台帳
図３乃至図５は、分散型台帳１３１(分散型データベースの一例である。）で管理するトランザクションのデータ構造の一部を模式的に示す図である。分散型台帳１３１では、複数のトランザクションそれぞれを格納したブロックが、１列に連なった数珠つなぎの構造で記録されている。なお、図３乃至図５の例では、１つのブロックは１つのトランザクションしか有していない例を示しているが、１つのブロックが複数のトランザクションを有してもよい。また、トランザクションは必ずしもブロックに格納されている必要はなく、トランザクションそのものが数珠つなぎとなっている構成でもよい。

図３は、分散型台帳１３１において管理される鍵生成トランザクション（第１トランザクションの一例である。）を含むブロック１の構造の一例を示す図である。鍵生成トランザクションは、生成した新たな鍵の承認を求めるトランザクションである。図３では一例として、ユーザＡ（第１ユーザの一例である。）が生成した鍵（第１鍵の一例である。）の承認のための鍵生成トランザクションを示している。

鍵生成トランザクションには、例えば、以下のデータが格納されている。
・ユーザＡの生成された鍵のデータ
・ユーザＡの署名
・他ユーザ（承認者ともいう。１以上の第２ユーザの一例である。）の署名

生成された鍵のデータは、ユーザＡが新たに使用する鍵を識別可能な情報であり、例えば鍵生成トランザクションにおいて承認される鍵ペアの公開鍵のハッシュ値である。なお、生成された鍵のデータとして、公開鍵のハッシュ値の代わりに公開鍵のデータそのものや、公開鍵のアクセス管理システム１において一意な識別子が鍵生成トランザクションに格納される構成でもよい。また、鍵生成トランザクションは、さらに生成される公開鍵あるいは既存の別の公開鍵で暗号化された秘密鍵を含んでもよい。また、生成される公開鍵と秘密鍵の鍵ペアは、ユーザＡ個人の鍵ペアに限定されず、ユーザＡが提供するサービスで利用される鍵ペアでもよい。

ユーザＡの署名は、鍵生成トランザクションにおいて承認される鍵ペアの秘密鍵を用いて生成されたデジタル署名である。なお、以下の説明では「デジタル署名」を単に「署名」ともいい、「鍵を用いてデジタル署名を生成」することを、単に「署名する」や「署名を行う」ともいう。

承認者の署名は、ユーザＡ以外の任意の数のユーザが、生成された鍵を承認する際に、自身の秘密鍵を用いて生成した署名である。図３の例では、鍵生成トランザクションには２人のユーザ（ユーザＢ，Ｃ）の署名が含まれているが、承認者の署名の数は、１以上の任意の数でよい。また、承認者として署名を生成するユーザは、例えば、ユーザＡ（つまり、新たに鍵を生成するユーザ）が指定することができる。他にも、承認者は、アクセス管理システム１に含まれるノード１０のユーザからランダムに選択されてもよいし、あらかじめアクセス管理システム１の管理者によって選択されたユーザでもよい。また、必要な承認者の署名の数は、あらかじめアクセス管理システム１の管理者により定められてもよいし、ユーザＡにより指定されてもよいし、ランダムに決定されてもよい。つまり、鍵生成トランザクションにおいて承認者として選ばれるユーザは、固定ではなく不定である。

なお、本実施形態では、各ユーザの署名は、鍵生成トランザクションのうち、署名が生成される領域を除いたデータ（すなわち、「ユーザＡの生成された鍵のデータ（本実施形態では公開鍵のハッシュ値）」）のハッシュ値をダイジェストとし、自身の秘密鍵を用いて当該ダイジェストを暗号化することで生成される。

図４は分散型台帳１３１において管理される鍵更新トランザクション（第２トランザクションの一例である。）を含むブロックＢ２の構造の一例を示す図である。鍵更新トランザクションは、アクセス管理システム１において承認された鍵（第１鍵の一例である。）を新たな鍵（第２鍵の一例である。）に更新することについて、承認を求めるためのトランザクションである。図４では一例として、図３に示した鍵生成トランザクションにおいて承認されたユーザＡの鍵についてｎ回目の更新を行う際の鍵更新トランザクションを示している。

鍵更新トランザクションには、例えば、以下のデータが格納されている。
・１つ前のトランザクションデータのハッシュ値
・ユーザＡの更新済みの鍵のデータ
・ユーザＡの署名
・他ユーザ（承認者）の署名
なお、鍵更新トランザクションは、上記の他に、１つ前のトランザクションへのポインタを含んでもよい。

１つ前のトランザクションとは、鍵のｎ回目の更新を行う鍵更新トランザクションの場合、鍵のｎ−１回目の更新を行ったトランザクションを指す。なお、今回の鍵更新トランザクションが初めて鍵を更新するものである場合、１つ前のトランザクションは、鍵生成トランザクションを指す。鍵更新トランザクションの１つ前のトランザクションも当然さらに１つ前のトランザクションデータのハッシュ値を含む構成である。このように、すべての鍵更新トランザクションは、鍵生成トランザクションまで数珠つなぎとなるデータ構造を有している。そうすると、鍵更新トランザクションは、鍵が生成されたトランザクションから鍵更新トランザクションまでのすべての鍵の更新履歴のハッシュ値を含んでいることになる。鍵更新トランザクションがこのような構成をとることで、途中のトランザクションに改ざんが行われたとしても、検知が容易になる。

更新済みの鍵のデータは、例えば鍵更新トランザクションにおいて、新たな鍵として承認される更新後の公開鍵のハッシュ値である。なお、更新済みの鍵データは新たな鍵を識別可能な情報であればよく、例えば公開鍵の識別子でもよい。鍵更新トランザクションには、さらに更新後の公開鍵で暗号化された更新後の秘密鍵が含まれてもよい。

ユーザＡの署名は、更新前後のそれぞれの秘密鍵を用いて生成された署名である。言い換えると、今回（ｎ回目）の更新後の秘密鍵と、前回（ｎ−１回目）の更新後の秘密鍵とを用いて生成された署名である。ただし、鍵更新トランザクションにおいて更新される鍵が、ユーザＡが提供するサービスで利用される鍵等、ユーザＡ自身の署名に用いる鍵とは別の鍵である場合には、ユーザＡは署名用の鍵を用いて署名を生成することも可能である。

承認者の署名は、ユーザＡ以外の任意の数のユーザが、更新された鍵を承認する際に、自身の秘密鍵を用いて生成した署名である。承認者の署名は、例えば鍵更新トランザクションの起源となる鍵生成トランザクションが有する承認者の署名と同一のユーザの署名である。ただし、これに限定されず、承認者として署名するユーザ及びその数は、鍵更新トランザクションのたびにユーザＡ（鍵の更新者）が選択する構成でもよいし、ランダムに決められる構成でもよいし、更新の回数に応じて署名するユーザをあらかじめアクセス管理システム１の管理者が設定しておく構成でもよい。つまり、鍵更新トランザクションにおいて承認者として選ばれるユーザは、固定ではなく不定である。

鍵更新トランザクションにおいても、各ユーザの署名は、鍵更新トランザクションのうち、署名を行う領域を除いたデータ（すなわち、「１つ前のトランザクションデータのハッシュ値」と「ユーザＡの更新済みの鍵のデータ（本実施形態では公開鍵のハッシュ値）」）のハッシュ値をダイジェストとし、自身の秘密鍵を用いて当該ダイジェストを暗号化することで生成される。

図５は分散型台帳１３１において管理される鍵失効トランザクション（第３トランザクションの一例である。）を含むブロックＢ３の構造の一例を示す図である。鍵失効トランザクションは、アクセス管理システム１において生成した鍵を失効させるトランザクションである。図５では一例として、図３に示した鍵生成トランザクションにおいて生成したユーザＡの鍵を失効させる鍵失効トランザクションを示している。

鍵失効トランザクションには、例えば、以下のデータが格納されている。
・１つ前のトランザクションデータのハッシュ値
・ユーザＡの鍵の失効情報
・ユーザＡの署名
・他ユーザ（承認者）の署名
なお、鍵失効トランザクションは、上記の他に、１つ前のトランザクションへのポインタを含んでもよい。

ユーザＡの鍵の失効情報は、ユーザＡの鍵が失効したことを特定可能な情報である。失効情報は、例えば、鍵の失効日、失効理由等を含む。失効理由は、典型的には鍵の所有者からの申請（秘密鍵の紛失や盗難、サービスの利用停止等）の他、システム管理者による失効登録（利用者の義務違反等）が挙げられる。なお、失効情報には、さらに失効対象となる鍵を識別可能な情報（例えば公開鍵本体と暗号化された秘密鍵等）が含まれてもよい。

ユーザＡの署名は、例えば、失効対象となる鍵を用いて生成された署名である。ただし、鍵失効トランザクションにおいて失効される鍵が、ユーザＡが提供するサービスで利用される鍵等、ユーザＡ自身の署名に用いる鍵とは別の鍵である場合には、ユーザＡは署名用の鍵を用いて署名を生成することも可能である。なお、失効操作を行うのがユーザＡ以外のユーザ（すなわち失効対象の鍵の所有者以外のユーザ）である場合には、ユーザＡ（鍵の所有者）の署名はなくてもよい。この場合には、鍵失効トランザクションには、ユーザＡの署名の代わりに失効操作者の署名が含まれる。

承認者の署名は、ユーザＡ以外の任意の数のユーザが、鍵の失効を承認する際に、自身の秘密鍵を用いて生成した署名である。承認者として署名するユーザ及びその数は、鍵更新トランザクションと同様、起源となる鍵生成トランザクションに含まれる承認者の署名と同一のユーザの署名でもよいし、失効者やアクセス管理システム１の管理者が指定してもよいし、ランダムに決められてもよい。つまり、鍵失効トランザクションにおいて承認者として選ばれるユーザは、固定ではなく不定である。

鍵失効トランザクションにおいても、各ユーザの署名は、鍵更新トランザクションのうち、署名が生成される領域を除いたデータ（すなわち、「１つ前のトランザクションデータのハッシュ値」と「ユーザＡの鍵の失効情報」）のハッシュ値をダイジェストとし、自身の秘密鍵を用いて当該ダイジェストを暗号化することで生成される。

図２に戻り、ノード１０の各機能部の詳細について説明する。以下の説明では、鍵生成トランザクション、鍵更新トランザクション、及び鍵失効トランザクションをまとめて単「トランザクション」ともいう。

（２）鍵取得部１１１
鍵取得部１１１（取得手段の一例である。）は、操作対象となる鍵の情報を取得する。例えば操作が鍵の生成である場合には、鍵取得部１１１は、鍵を生成することができる。生成される鍵は、分散型台帳１３１、及び／又はデータベース３０において、ユーザＡと関連付けられていない鍵である。

また、操作が鍵の更新である場合には、鍵取得部１１１は、更新後の新たな鍵を生成する。更新後の新たな鍵は、分散型台帳１３１、及び／又はデータベース３０において、ユーザＡと関連付けられていない鍵である。さらに鍵取得部１１１は、データベース３０を参照して、更新対象の鍵を取得する。

操作が鍵の失効である場合には、鍵取得部１１１は、処理を行わない。ただし、この場合にも、鍵取得部１１１は、データベース３０を参照して失効対象の鍵を取得してもよい。

なお、鍵取得部１１１はデータベース３０から鍵を取得する際には、操作対象の鍵が承認されたトランザクションのＩＤやユーザＡの識別子に基づいてデータベース３０を検索することができる。また、鍵取得部１１１は、鍵を生成する代わりに、他ノードに鍵の生成を依頼し、他ノードにおいて生成された鍵を取得する構成でもよい。この場合、鍵を生成する他ノードは、例えばアクセス管理システム１の管理ノードであることが好ましい。

（３）鍵検証部１１２
鍵検証部１１２（検証手段の一例である。）は、鍵取得部１１１が取得した鍵のうち、少なくともユーザＡが新たに使用する鍵について、正常に機能するか検証を行う。例えば鍵検証部１１２は、鍵取得部１１１が生成した鍵ペアや、他ノードに生成を依頼した鍵ペアについて、一方の鍵が暗号化したデータを他方の鍵で復号可能か否かの検証を行う。

（４）トランザクション生成部１１３
トランザクション生成部１１３（生成手段の一例である。）は、鍵の操作に関するトランザクションを生成する。トランザクションの各構成の生成処理について具体的に説明する。

まず、トランザクション生成部１１３は、鍵のデータとして、例えば、鍵検証部１１２が検証した公開鍵から所定のハッシュ関数を使ってハッシュ値を生成する。なお、トランザクション生成部１１３は鍵のデータとして、公開鍵の識別子を用いてもよい。また、トランザクションが暗号化された秘密鍵を含む場合には、トランザクション生成部１１３は、秘密鍵に対応する公開鍵もしくは既存の別の公開鍵を用いて、秘密鍵の暗号化を行う。

次に、トランザクション生成部１１３は、生成するトランザクションが鍵更新トランザクション又は鍵失効トランザクションである場合には、１つ前のトランザクションのハッシュ値を生成する。今回生成するトランザクションの１つ前のトランザクションは、操作（更新・失効）対象の鍵が承認されたトランザクションである。そこでまず、トランザクション生成部１１３は、操作対象となる鍵が承認されたトランザクションＩＤを特定する。例えば、トランザクション生成部１１３は、トランザクションＩＤをユーザＡから指定される構成でもよいし、ユーザＡから更新対象となる鍵の指定を受け付け、データベース３０を参照して、指定された鍵に対応するトランザクションＩＤを特定する構成でもよい。トランザクションＩＤを特定すると、トランザクション生成部１１３は、分散型台帳１３１を参照して、特定したトランザクションＩＤに対応するトランザクションを取得し、当該トランザクションのハッシュ値を算出する。

なお、生成するトランザクションが鍵失効トランザクションの場合には、トランザクション生成部１１３は、さらに失効情報を生成する。失効情報は、例えばユーザＡからの入力を受付けて生成することができる。

最後にトランザクション生成部１１３は、ネットワークＮにおいて一意なトランザクションＩＤを採番し、トランザクションを生成する。

（５）署名実行部１１４
署名実行部１１４は、ユーザＡの署名用の鍵を用いてトランザクションに署名を行う。一例として、署名実行部１１４は、トランザクション生成部１１３が生成したトランザクションのうち、署名が格納される領域を除くデータのハッシュ値を計算し、ダイジェストを生成する。そして、署名実行部１１４は生成したダイジェストをユーザＡの秘密鍵を用いて暗号化することで、署名を行う。ここで署名に用いられる秘密鍵は、例えば鍵生成トランザクションの場合は生成された秘密鍵であり、鍵更新トランザクションの場合は更新前後の秘密鍵であり、鍵失効トランザクションの場合は失効対象の秘密鍵である。なお、トランザクションで操作される鍵と署名を生成する鍵とは必ずしもペアである必要はない。例えば、トランザクションで操作される公開鍵が、ユーザＡの署名用の秘密鍵に対応する公開鍵とは異なる場合には、署名実行部１１４は、ユーザＡの既存の署名用の鍵（すなわちトランザクションで操作される鍵とは異なる鍵）を用いて、生成したダイジェストを暗号化することで署名を生成する。

（６）送信部１１５
送信部１１５（送信手段の一例である。）は、署名実行部１１５が署名したトランザクションを、承認依頼先のノードに送信する。このとき、送信部１１５は、トランザクションに承認を依頼する（すなわち署名を求める）他ユーザ（承認者）の識別子を宛先に承認依頼先として設定する。例えば送信部１１５は、ノード１０ＡのユーザＡから、承認依頼先の承認者の指定を受け付ける構成でもよいし、アクセス管理システム１の管理者からあらかじめ定められている承認者を設定する構成でもよいし、アクセス管理システム１のユーザからランダムに選択して設定する構成でもよい。

なお、送信部１１５はトランザクションを承認依頼先に送信する際に、署名実行部１１５が行った署名を復号可能な公開鍵（つまり、新たに生成された公開鍵や、更新後の公開鍵、失効対象となる公開鍵）を併せて送信してもよい。また、送信部１１５は、トランザクションをネットワークＮ全体に送信することも可能である。

（７）データベース制御部１１６
データベース制御部１１６（共有手段の一例である。）は、鍵検証部１１２が検証した鍵を分散型台帳システムを構成する他のノード（ノード１０Ｂ、１０Ｃ）と共有する。一例として、データベース制御部１１６は、鍵検証部１１２が検証した鍵をデータベース３０に登録する。具体的には、鍵に対する操作が、「生成」である場合には、データベース制御部１１６は、データベース３０に新なレコードを追加して、公開鍵と、当該公開鍵で暗号化された秘密鍵を登録する。

鍵に対する操作が、「更新」である場合には、データベース制御部１１６は、データベース３０を参照して、更新対象の鍵に対応するレコードを抽出し、抽出したレコードに更新後の公開鍵及び当該公開鍵で暗号化された秘密鍵を追加する。なお、データベース制御部１１６は、更新前の公開鍵及び暗号化された秘密鍵を更新後の公開鍵及び暗号化された秘密鍵に置き換える構成でもよい。

鍵に対する操作が、「失効」である場合には、データベース制御部１１６は、データベース３０を参照して、失効対象の鍵に対応するレコードを削除する。なお、データベース制御部１１６は、レコードを削除する代わりに抽出したレコードに失効情報を追加する構成でもよい。

データベース制御部１１６は、データベース３０に対して鍵の登録を行う場合には、鍵と対応付けてトランザクション生成部１１４が生成したトランザクションの識別子（以下「トランザクションＩＤ」ともいう。）をデータベース３０に登録しておくことが好ましい。

なお、データベース制御部１１６が他のノードと鍵を共有する方法は、データベース３０に登録する方法の他、鍵を直接他のノードに送信する方法でもよい。

また、本実施形態では、データベース制御部１１６は、送信部１１５がトランザクションを送信する前にデータベース３０に検証された鍵を登録する。この場合、データベース制御部１１６は、送信されたトランザクションが承認者によって承認されなかった場合には、登録内容をロールバックする。ただし、登録処理のタイミングはこれに限定されず、データベース制御部１１６は、データベース制御部１１６は、検証された鍵のデータベース３０への登録処理を、承認者によるトランザクションへの署名が完了した場合に行う構成でもよい。この場合、トランザクションにはユーザＡの署名を復号可能な公開鍵そのものが含まれるか、送信部１１５がトランザクションを送信する際に、データベース制御部１１６があわせて公開鍵を送信することが好ましい。

（８）処理フロー
図６を参照して、ノード１０Ａが鍵に対して操作を行う際の処理の流れを説明する。図６はノード１０Ａの処理フローの一例を示すフローチャートである。

まず、鍵取得部１１１は、操作対象となる鍵を取得する（Ｓ１１）。鍵取得部１１１は、操作内容に応じて、鍵を生成したり、データベース３０から検索することで、操作対象となる鍵を取得する。

次に、鍵検証部１１２が、取得された鍵が正常に機能するか否かの検証を行う（Ｓ１２）。鍵が正常に機能しない場合（Ｓ１３：ＮＯ）には、ノード１０Ａは処理を終了する。なお、このときノード１０Ａはアクセス管理システム１の管理者に通報を行う構成でもよい。

鍵が正常に機能した場合（Ｓ１３：ＹＥＳ）、トランザクション生成部１１３がトランザクションを生成する。生成されたトランザクションに署名実行部１１４が署名を行う（Ｓ１５）と、送信部１１５は、承認依頼先を設定して、トランザクションを送信する（Ｓ１６）。一方、鍵が正常に機能した場合（Ｓ１３：ＹＥＳ）、データベース制御部１１６は、検証された鍵をデータベース３０に登録する（Ｓ１７）。なお、Ｓ１７の処理と、Ｓ１４乃至Ｓ１６の処理との前後関係は任意である。

なお、Ｓ１７の処理がＳ１６の処理に前に行われた場合には、データベース制御部１１６は、送信部１１５が送信したトランザクションが承認されなかった場合に、データベース３０をロールバックし、鍵の登録を取り消すことができる。

＜３−２．承認ノード（ノード１０Ｂ、１０Ｃ）＞
次に、図７を用いて承認ノードであるノード１０Ｂ、１０Ｃの機能構成について説明する。図７は、本実施形態に係るノード１０Ｂの機能ブロック図である。なお、ノード１０Ｃの機能構成はノード１０Ｂと同様であるため説明を割愛する。図７に示すように、ノード１０Ｂは、記憶部１３１と、トランザクション取得部１２１と、トランザクション検証部１２２と、署名実行部１２３と、送信部１２４とを有している。記憶部１３１には、ユーザＢの秘密鍵の他、上述した分散型台帳１３１が記録されている。ただし、すべての承認ノードが分散型台帳１３１を有している必要はなく、一部の承認ノードが有している構成でもよい。

（１）トランザクション取得部１２１
トランザクション取得部１２１は、ネットワークＮに送信されたトランザクションを取得する。例えばトランザクション取得部１２１は、受信したトランザクションから、自ノード宛に署名依頼がされているトランザクションを抽出することが可能である。

（２）トランザクション検証部１２２
トランザクション検証部１２２は、取得したトランザクションの正当性の検証を行う。
例えば、トランザクション検証部１２２は、取得したトランザクションから署名を行う領域を除いたデータからハッシュ値を算出し、復号したダイジェストと突合することでユーザＡの署名を検証する。これによって、操作者がユーザＡであること、及びトランザクションが改ざんされていないことを検証することができる。

さらにトランザクション検証部１２２は、トランザクションに含まれるユーザＡの署名の検証を行ってもよい。具体的には、トランザクション検証部１２２は、データベース３０を参照し、取得したトランザクションのＩＤに対応するレコードを抽出する。次に抽出したレコードからユーザＡの公開鍵を取得して、ユーザＡの署名からダイジェストを復号する。なお、トランザクションに公開鍵そのものが含まれている場合や、トランザクションに公開鍵が添付されて送信されている場合等には、トランザクション検証部１２２は、必ずしもデータベース３０から公開鍵を検索する必要はない。

なお、トランザクション検証部１２２は、鍵更新トランザクションの場合には、更新前後の秘密鍵によって行われたそれぞれの署名を検証する。ただし、鍵更新トランザクションにおいて更新される鍵がユーザＡの署名用の鍵とは異なる鍵ペアや共通鍵の場合には、鍵更新トランザクションにはユーザＡの既存の署名用の鍵による署名が含まれることになる。この場合には、トランザクション検証部１２２は、署名用の鍵によって生成されたユーザＡの署名を検証する。また、鍵失効トランザクションであって、失効操作者がユーザＡでない場合には、失効操作者の署名を検証する。

さらに、トランザクション検証部１２２は、上記の他、トランザクションに含まれるその他のデータが適切か否かを検証してもよい。例えば、鍵更新トランザクションや鍵失効トランザクションの場合、トランザクションに含まれる１つ前のトランザクションのハッシュ値が正しい値であるか否かを、１つ前のトランザクションのハッシュ値を算出して検証してもよい。また、例えば、トランザクションに含まれる鍵のデータが正しいか否かを、データベース３０に登録されているデータと突合して検証してもよい。具体的には、トランザクションに公開鍵のハッシュ値が含まれる場合には、トランザクション検証部１２２は、署名を復号して得た公開鍵のハッシュ値と、データベース３０に登録されている公開鍵からハッシュ値を算出し、突合することができる。

（３）署名実行部１２３
署名実行部１２３は、トランザクション検証部１２２が正当性を検証したトランザクションについて、ユーザＢが承認依頼先として指定されているトランザクションである場合には、ユーザＢの署名用の鍵を用いてトランザクションに署名を行う。他方、ユーザＢが署名を求められていないトランザクションである場合には、処理を行わない。

（４）送信部１２４
送信部１２４は、署名実行部１２３が署名したトランザクションを送信する。このとき、送信部１２４は、ノード１０ＡのユーザＡから、署名を依頼した承認者のうち、未署名のユーザがいる場合には、当該未署名のユーザ宛にトランザクションを転送する構成でもよいし、未署名のユーザの有無にかかわらず、ユーザＡにトランザクションを返送する構成でもよい。

さらに送信部１２４は、トランザクション取得部１２１が取得したトランザクションにおいて、未署名のユーザがいなかった場合には、ネットワークＮ全体にトランザクションを送信することで、ネットワークＮに接続するノード１０の分散型台帳１３１にトランザクションを登録することも可能である。

（５）処理フロー
図８を参照して、ノード１０Ｂがトランザクションを承認する際の処理の流れを説明する。図８はノード１０Ｂの処理フローの一例を示すフローチャートである。

まず、トランザクション取得部１２１は、ネットワークＮからトランザクションを取得する（Ｓ２１）。次に、トランザクション検証部１２２が、取得したトランザクションの検証を行う（Ｓ２２）

検証の結果、トランザクションが否認されるべきと判断された場合（Ｓ２３：ＮＯ）には、ノード１０Ｂは処理を終了する。なお、このときノード１０Ｂはアクセス管理システム１の管理者に通報を行う構成でもよい。

他方、検証の結果、トランザクションが承認されるべきと判断された場合（Ｓ２３：ＹＥＳ）、であって、承認依頼先にノードＢが指定されている場合（Ｓ２４：ＹＥＳ）には、署名実行部１２３がユーザＢの秘密鍵を用いて署名を行う（Ｓ２５）。

最後に、送信部１２４が、トランザクションを送信する（Ｓ２６）。このとき送信部１２４は、承認依頼先に設定されているユーザに、未承認のユーザがいる場合には、当該未承認のユーザ又はユーザＡにトランザクションを送信する。他方、未承認のユーザがいない場合には、各ノード１０にネットワークＮ全体に送信する。

＜４．利用例＞
図９を参照して、アクセス管理システム１において管理される鍵の利用方法の一例について説明する。図９は、当該鍵を使ったアクセス制御の仕組みを説明するための模式図である。図９の例では、ノード１０Ａがノード１０Ｂの管理するデータ等にアクセスを行う際に、ノード１０Ａを利用するユーザＡを、ノード１０Ｂが認証（本人確認）する場合を示している。

まずノード１０Ｂは、ランダムに生成したメッセージ（平文）をノード１０Ａに送信する。なお、メッセージは、一時的に生成した本人確認用の任意のデータを意味する。ノード１０Ａは、受信したメッセージ本文（平文）に対して、ハッシュ関数を使ってハッシュ値（メッセージダイジェスト）を求める（矢印（１））。次に、そのメッセージダイジェストを、記憶部１３０に記憶しているユーザＡの秘密鍵で暗号化する(矢印（２））。ノード１０Ａは、メッセージに、署名に利用した秘密鍵に対応する公開鍵を識別する情報（例えば公開鍵のハッシュ値や識別子（ＩＤ）である。以下では、公開鍵を識別する情報を「公開鍵ＩＤ」ともいう。）を添付し（矢印（３））、ノード１０Ｂに送信する（矢印（４））。なお、公開鍵ＩＤの代わりに、当該の公開鍵を登録したトランザクションＩＤや公開鍵そのものあるいはトランザクションのデータそのものをメッセージに添付する方法も考えられる。

一方、メッセージを受信したノード１０Ｂは、分散型台帳１３１を参照して、メッセージに添付された公開鍵ＩＤに基づいて、当該公開鍵ＩＤに対応する公開鍵への操作を承認したトランザクションを検索し、抽出する。さらにノード１０Ｂは、抽出したトランザクションを検証する。ここでの検証処理は、上述したトランザクション検証部１２２の検証処理と同様である。

なお、このとき、ノード１０Ｂは、抽出したトランザクションのあとに、メッセージに添付された公開鍵ＩＤに対応する鍵をさらに更新又は失効させるトランザクションが、分散型台帳１３１に含まれるか否かを判定することが好ましい。具体的には、ノード１０Ｂは、抽出したトランザクション（すなわちメッセージに添付された公開鍵ＩＤに対応する鍵への操作を承認したトランザクション）のハッシュ値を含むトランザクションが分散型台帳１３１に登録されているか否かを判定する。抽出したトランザクションのハッシュ値を含むトランザクションが分散型台帳１３１に登録されている場合には、メッセージに添付された公開鍵ＩＤに対応する公開鍵はすでに失効していることになる。この場合には、ノード１０Ｂは、ユーザＡの署名が不正なものであると判断し、ユーザＡを認証しないことが好ましい。

なお、ノード１０Ｂが、抽出したトランザクションのハッシュ値を含むトランザクションについて、さらにそのハッシュ値を含むトランザクションが分散型台帳１３１に存在するか否かを繰り返し検証することにより、ユーザＡの最新の鍵の情報を確認することができる。

ノード１０Ｂは、抽出したトランザクションにおける承認者を特定し、データベース３０を参照して特定した承認者の公開鍵を取得する。取得した承認者の公開鍵を用いて、特定したトランザクションに含まれる承認者の署名を検証し、承認者の正当性を確認する（矢印（５））。つまり、この例では、ユーザＡの公開鍵が承認されたトランザクションがデジタル証明書の代わりとしてユーザＡの公開鍵の正当性（信頼性）を証明しているといえる。

なお、ノード１０Ｂが、さらに、特定したトランザクションに含まれるユーザＡの公開鍵のハッシュ値（公開鍵ＩＤ）と、データベース３０から取得したユーザＡの公開鍵にハッシュ関数を用いて求めたハッシュ値とを比較して、トランザクションＩＤが今回用いられている秘密鍵を承認するためのものであったかを確認する構成も可能である。

さらにノード１０Ｂは、ユーザＡの公開鍵を用いてユーザＡの署名を復号する（矢印（６））とともに、メッセージ本文（平文）からノード１０Ａと同じハッシュ関数を使ってハッシュ値（メッセージダイジェスト）を求め（矢印（７））、両者を突合してチェックする（矢印（８））ことでユーザＡを認証する。なお、トランザクションが公開鍵そのものを含む構成の場合には、ノード１０Ｂは特定したトランザクションからユーザＡの公開鍵を取得することが可能である。

このように、本実施形態に係るアクセス管理システム１によると、ユーザは使用する鍵が１以上のユーザから承認されたトランザクションによって、ユーザの鍵の正当性（信頼性）を証明することができる。すなわち、ユーザの鍵の信頼性をユーザ相互に担保することが可能となるため、仮に、あるユーザの信頼性が損なわれた場合でも承認者の信頼性に基づいてシステム全体の信頼性を継続することができる。さらに、鍵の失効についてもユーザ相互で承認することで、従来のＣＲＬ（Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）による一元管理が不要になる。

＜ハードウェア構成＞
以下、図１０を参照しながら、第１の実施形態及び第２の実施形態において上述してきたノード１０、及びデータベース３０をコンピュータ８００により実現する場合のハードウェア構成の一例を説明する。なお、それぞれの装置の機能は、複数台の装置に分けて実現することもできる。

図１０に示すように、コンピュータ８００は、プロセッサ８０１、メモリ８０３、記憶装置８０５、入力Ｉ／Ｆ部８０７、データＩ／Ｆ部８０９、通信Ｉ／Ｆ部８１１、及び表示装置８１３を含む。

プロセッサ８０１は、メモリ８０３に記憶されているプログラムを実行することによりコンピュータ８００における様々な処理を制御する。例えば、ノード１０Ａ、１０Ｂの鍵取得部１１１や、鍵検証部１１２、データベース制御部１１６、トランザクション生成部１１４、署名実行部１１５、トランザクション取得部１２１、トランザクション検証部１２２、署名実行部１２３、送信部１２４、などは、メモリ８０３に一時記憶された上で、主にプロセッサ８０１上で動作するプログラムとして実現可能である。

メモリ８０３は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の記憶媒体である。メモリ８０３は、プロセッサ８０１によって実行されるプログラムのプログラムコードや、プログラムの実行時に必要となるデータを一時的に記憶する。

記憶装置８０５は、例えばハードディスクドライブ（ＨＤＤ）やフラッシュメモリ等の不揮発性の記憶媒体である。記憶装置８０５は、オペレーティングシステムや、上記各構成を実現するための各種プログラムを記憶する。この他、記憶装置８０５は、分散型台帳１３１を記憶することも可能である。このようなプログラムやデータは、必要に応じてメモリ８０３にロードされることにより、プロセッサ８０１から参照される。

入力Ｉ／Ｆ部８０７は、ユーザからの入力を受け付けるためのデバイスである。入力Ｉ／Ｆ部８０７の具体例としては、キーボードやマウス、タッチパネル、各種センサ、ウェアラブル・デバイス等が挙げられる。入力Ｉ／Ｆ部８０７は、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）等のインタフェースを介してコンピュータ８００に接続されても良い。

データＩ／Ｆ部８０９は、コンピュータ８００の外部からデータを入力するためのデバイスである。データＩ／Ｆ部８０９の具体例としては、各種記憶媒体に記憶されているデータを読み取るためのドライブ装置等がある。データＩ／Ｆ部８０９は、コンピュータ８００の外部に設けられることも考えられる。その場合、データＩ／Ｆ部８０９は、例えばＵＳＢ等のインタフェースを介してコンピュータ８００へと接続される。

通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部の装置と有線又は無線により、インターネットＮを介したデータ通信を行うためのデバイスである。通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部に設けられることも考えられる。その場合、通信Ｉ／Ｆ部８１１は、例えばＵＳＢ等のインタフェースを介してコンピュータ８００に接続される。

表示装置８１３は、各種情報を表示するためのデバイスである。表示装置８１３の具体例としては、例えば液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、ウェアラブル・デバイスのディスプレイ等が挙げられる。表示装置８１３は、コンピュータ８００の外部に設けられても良い。その場合、表示装置８１３は、例えばディスプレイケーブル等を介してコンピュータ８００に接続される。

[その他の実施形態]
以上説明した各実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更／改良され得るととともに、本発明にはその等価物も含まれる。また、各実施形態は例示であり、異なる実施形態で示した構成の部分的な置換または組み合わせが可能であることは言うまでもなく、これらも本発明の特徴を含む限り本発明の範囲に包含される。

例えば、既述の実施形態において、トランザクションに対してマイニングは行われない例を説明したが、これに限定されず、ＰｏＷの技術を用いてマイニングを行ったうえで、トランザクションを分散型台帳１３１に登録する構成でもよい。

また、既述の実施形態において、トランザクションにおいて操作が承認されるユーザＡの鍵と、当該トランザクションに署名を生成するユーザＡの鍵とは対となる構成について説明した。しかしこれに限定されず、トランザクションでは、ユーザＡが署名を生成する鍵（例えば署名用の秘密鍵である。）とは異なる鍵ペアに対する操作が承認されてもよい。この場合、トランザクションには、当該トランザクションによって操作が承認される公開鍵とは異なる、既存の公開鍵と対になる秘密鍵による署名や、既存の公開鍵で暗号化された秘密鍵が含まれてもよい。トランザクション生成部１１３は、このようなトランザクションを生成するにあたり、操作対象となる公開鍵を識別する情報（ハッシュ値やＩＤ）や、操作対象となる公開鍵とは異なる既存の公開鍵で暗号化された秘密鍵を用いることができる。また、このとき署名実行部１１４は、トランザクションによって操作が承認される公開鍵とは異なる、既存の公開鍵と対になる秘密鍵によってトランザクションにユーザＡの署名を生成する。さらに、この場合には、トランザクション検証部１２２は、トランザクション検証部１２２は、生成されたユーザＡの署名を、署名を行った秘密鍵と対となるユーザＡの既存の公開鍵を用いて検証する。

さらに、既述の実施形態では、アクセス管理システム１は、公開鍵暗号方式に基づく鍵ペアを管理する例について説明したが、これに限定されず、共通鍵暗号方式に基づく共通鍵を管理する構成でもよい。この場合、トランザクションには、共通鍵のハッシュ値、または既存の公開鍵で暗号化された共通鍵そのものや、ユーザＡの署名用の鍵による署名が含まれる。なお、ここでいう署名用の鍵は、公開鍵暗号方式の秘密鍵だけでなく、メッセージ認証符号（ＭＡＣ値）の生成・復号を行う認証用の共通鍵も含む。共通鍵の場合、署名はメッセージ認証符号（ＭＡＣ値）を指す。トランザクション生成部１１３は、このようなトランザクションを生成するにあたり、操作対象となる共通鍵を識別する情報（ハッシュ値やＩＤ）を用いることができる。また、このとき署名実行部１１４は、トランザクションによって操作が承認される共通鍵、当該共通鍵とは異なる認証用の共通鍵、または既存の署名用の公開鍵と対になる秘密鍵によってトランザクションにユーザＡの署名またはＭＡＣ値を生成する。さらに、この場合には、トランザクション検証部１２２は、トランザクション検証部１２２は、生成されたユーザＡの署名を、今回操作対象となる共通鍵や、ユーザＡの認証用の共通鍵、署名用の公開鍵を用いて検証する。

１ アクセス管理システム
１０Ａ、１０Ｂ、１０Ｃ ノード
３０ データベース
１１１ 鍵取得部
１１２ 鍵検証部
１１３ トランザクション生成部
１１３ データベース制御部
１１４ 署名実行部
１１５ 送信部
１１６ データベース制御部
１２１ トランザクション取得部
１２２ トランザクション検証部
１２３ 署名実行部
１２４ 送信部
１３０ 記憶部
１３１ 分散型台帳

Claims (6)

1. トランザクションが管理される分散型データベースにアクセス可能なコンピュータを、
   第１ユーザのアクセス権限を示すための第１鍵であって、前記分散型データベースにおいて前記第１ユーザに関連づけられていない第１鍵を取得する取得手段、
   前記第１鍵の検証を行う検証手段、
   前記第１鍵に関する情報を、前記分散型データベースにアクセス可能な１以上の第２ユーザのコンピュータと共有する共有手段、
   前記第１鍵の情報と、前記第１ユーザのデジタル署名とを含み、前記第１鍵の使用の承認を依頼する第１トランザクションを生成する生成手段、及び
   前記第１トランザクションが、前記１以上の第２ユーザにデジタル署名され、前記分散型データベースに登録されるために、前記第１トランザクションを前記１以上の第２ユーザのコンピュータに送信する送信手段、
   として機能させるプログラム。
2. 前記取得手段は、さらに、
   前記第１鍵に代えて第１ユーザのアクセス権限を示す第２鍵であって、前記分散型データベースにおいて前記第１ユーザに関連付けられていない第２鍵を取得し、
   前記検証手段は、さらに、
   前記第２鍵の検証を行い、
   前記共有手段は、さらに、
   前記第２鍵に関する情報を、前記１以上の第２ユーザのコンピュータと共有し、
   前記生成手段は、さらに、
   前記第１鍵を用いて生成されたデジタル署名と、前記第２鍵を用いて生成されたデジタル署名と、前記第１トランザクションのハッシュ値とを含み、前記第２鍵の使用の承認を依頼する第２トランザクションを生成し、
   前記送信手段は、さらに、
   前記第２トランザクションが、前記１以上の第２ユーザにデジタル署名され、前記分散型データベースに登録されるために、前記第２トランザクションを前記１以上の第２ユーザのコンピュータに送信する送信手段、
   請求項１に記載のプログラム。
3. 前記生成手段は、さらに、
   前記第１鍵が失効することを示す情報と、前記第１トランザクションのハッシュ値と、前記第１ユーザのデジタル署名とを含み、前記第１鍵の失効の承認を依頼する第３トランザクションを生成し、
   前記送信手段は、さらに、
   前記第３トランザクションが、前記１以上の第２ユーザにデジタル署名され、前記分散型データベースに登録されるために、前記第３トランザクションを前記１以上の第２ユーザのコンピュータに送信する
   請求項１または２に記載のプログラム。
4. ユーザのアクセス権限を示す鍵への操作を承認するためのトランザクションが管理される分散型データベースと、
   前記分散型データベースにアクセス可能な第１ノード及び１以上の第２ノードと、
   を備え、
   前記第１ノードは、
   第１ユーザのアクセス権限を示すための第１鍵であって、前記分散型データベースにおいて前記第１ユーザに関連付けられていない第１鍵を取得する取得部と、
   前記第１鍵の検証を行う検証部と、
   前記第１鍵に関する情報を、前記第２ノードと共有する共有部と、
   前記第１鍵の情報と、前記第１ユーザのデジタル署名とを含み、前記第２ノードに前記第１鍵の使用の承認を依頼する第１トランザクションを生成する生成部と、
   前記第１トランザクションを、前記第２ノードに送信する送信部と、
   を有し、
   前記第２ノードは、
   共有された前記第１鍵に関する情報と前記第１ユーザのデジタル署名に基づいて、前記第１トランザクションの正当性を検証する検証部と、
   正当性が検証された前記第１トランザクションに対して、第２ユーザのデジタル署名を生成する署名部と、
   前記第１トランザクションを前記分散型データベースに送信する送信部と、
   を有する
   アクセス管理システム。
5. メッセージ本体と、
   前記メッセージ本体から所定のハッシュ関数に基づいて算出したダイジェストを、第１暗号化鍵を用いて暗号化した第１デジタル署名と、
   前記第１暗号化鍵によって暗号化されたデータを復号する第１復号鍵を識別する第１情報を含む証明書データと、
   を含むメッセージのデータ構造であって、
   前記メッセージを受信したノードが、
   前記ノードがアクセス可能な分散型台帳において、前記証明書データに含まれる前記第１情報に基づいて前記第１復号鍵の使用が承認されたトランザクションを特定し、
   当該トランザクションにおいて前記第１復号鍵の使用を承認した、複数のユーザそれぞれの第２暗号化鍵による複数の第２デジタル署名を、前記複数のユーザそれぞれの第２暗号化鍵によって暗号化されたデータを復号する第２復号鍵によって検証し、
   前記第１復号鍵によって前記第１デジタル署名から前記ダイジェストを復号し、前記メッセージ本体から前記所定のハッシュ関数に基づいてダイジェストを算出し、復号した前記ダイジェストと突合して前記第１暗号化鍵の所有者を認証する処理に用いられる
   データ構造。
6. 前記ノードは、さらに、
   前記分散型台帳において、特定した前記トランザクションのハッシュ値を含む他のトランザクションが登録されている場合には、前記第１暗号化鍵の所有者を認証しない、
   請求項５に記載のデータ構造。

Images