JP7264440B2 - 分散データ管理システムおよびそのプログラム - Google Patents

Description

本発明は、分散データ管理システムおよびそのプログラムに関する。

IoT等のスマート社会の実現においては、電子化された医療・健康・介護等の情報の有効利用は重要な課題である。各個人の医療・健康・介護等に関する情報は、単一の医療機関からだけでなく、複数の病院、クリニック、薬局、さらには普段の生活における生理計測データも統合して蓄積して有効に活用することが望まれる。

そこで、個々の医療機関における診療に関する履歴は、従来の紙やフィルムといった物理媒体での蓄積から、電子カルテ等の形で電子化された蓄積への移行が進んでいる。電子化することで、保存のためのコストが下がり、検索の機能等により利用の効率も向上している。さらに、蓄積された医療情報をコンピュータで解析することによる医療改善等に向けた二次利用も始まっている。

しかし、医療・健康・介護等に関する情報はプライバシーに関わる情報を多く含むことから、蓄積や活用する上でセキュリティを保つことが重要である。さらに、情報の消失や改ざん耐性が高い管理の実現が望まれる。

そのため、その具体的な管理手段は未だ明確になっていない。

特開2018-166000号公報（図1～図3、段落0021～0027等） 特開2018-147016号公報（図2、段落0017～0032等） 特表2008-509634号公報（図1(a)～(d)、段落0010～0015等）

ところで、昨今、ブロックチェーンの技術が医療・健康・介護等に関する情報の蓄積に適合しているのではと注目されつつある。
ブロックチェーン技術は、元々は仮想通貨の実現のために提案された技術である。取引（トランザクション）を記録した台帳を、一台のホストコンピュータで管理して保持するのではなく、複数のコンピュータに重複した形で分散して保持する。

そして、分散した重複データの間の矛盾がないことを確認することで、一部のコンピュータへの攻撃によるデータの消失や改ざんを防いでいる。複数のトランザクションをブロックとしてまとめ、その内容を数値（ハッシュ値）にマッピングする。そして、時系列でブロックをチェーンとしてつなげて、前のブロックのハッシュ値を木構造化した情報（Merkle Tree）として次のブロックが持つ。これにより、分散したMerkle Tree間の矛盾の発生から、トランザクションの消失や改ざんを検出可能としている。

仮想通貨のブロックチェーンでは、この無矛盾性を確認してブロックをチェーンにつなげる処理（PoW: Proof of Work）に工夫をして報酬をつけ、多数の作業者（マイナー）の中で早い者勝ちとすることで、多数が行う時間制約の中で不正なチェーンができないようにしている。つまり、ビットコインのブロックチェーンでは、不正防止のために「誰がどんな取引をしたのか」といったトランザクションの内容を多数の作業者が見ることが前提となっている。このため、情報開示範囲の考慮が必要な処理にはそのまま適用できない。

イーサリアム、ネム、リップル等の仮想通貨では、PoW の代わりに、無矛盾性確認のやり方を変えたPoS (Proof of Stake)、PoI (Proof of Importance)、PoC (Proof of Consensus) といった手法も使われているが、いずれもトランザクションの内容は秘匿化されてはいない。これらの仮想通貨のブロックチェーンは、不特定多数の利用者を想定するためパブリックチェーンと呼ばれるが、利用者を限定したプライベートチェーンも提案、実現されている。

しかし、多人数の生理計測データや多数の機関からの医療情報収集を想定すると、利用者限定のプライベートチェーンは向かない。一方、パブリックチェーンで秘匿性を確保するために、ゼロ知識証明を使ったzk-SNARKが提案されている。しかし、zk-SNARKでは、全ての情報が秘匿化されてしまい、蓄積された情報の解析等を考えた場合には、やはりそのまま適用することはできない。

上述のブロックチェーンに係る技術として、特許文献1～3がある。
特許文献１には、上位ネットワークと下位ネットワークとをブロックチェーンで管理し、ネットワークそのものを階層化することが記載されている。

特許文献2には、ハッシュ値の扱いと管理方法について記載されている。詳細には、階層化された管理単位に対応する複数のブロックチェーンとし、階層毎にブロックチェーンをもつこととしている
特許文献3には、暗号のやりとり方法が記載されている。暗号化されたメディアストリームを復号する際にインデックスを利用するというもので、特定の人だけがブロックを繋げることが記載されている。

しかし、特許文献１～3は、ブロックチェーンに置かれた情報を指定する範囲で共有できない。

本発明は上記実状に鑑み創案されたものであり、高い消失・改ざん耐性を保持しつつ指定する範囲でデータの共有を可能とする管理を実現する分散データ管理システムおよびそのプログラムの提供を目的とする。

前記課題を解決するため、第１の本発明の分散データ管理システムは、複数のブロックがつながれるブロックチェーンが格納されるコンピュータのノードと、プロキシサーバあるいは前記プロキシサーバの機能を持つ前記ノードとを備え、前記ブロックに格納される情報は、複数のアクセスレベルに分割され、かつアクセスレベルに応じた異なる第１の鍵によって暗号化されており、前記ノードがもつ第２の鍵で暗号化された情報を前記第１の鍵で暗号化された情報にする再暗号化鍵が前記プロキシサーバに格納されており、前記プロキシサーバは、前記ノードから送られる前記第２の鍵で暗号化された前記ノードの登録情報および前記登録情報のアクセスレベルおよび新しいハッシュ値の情報から、前記アクセスレベルの前記再暗号化鍵で前記ノードの前記登録情報を暗号化するとともに、前記新しいハッシュ値の情報を対応する前記再暗号化鍵で暗号化している。

第２の本発明の分散データ管理システムは、複数のアクセスレベルに分割され、かつアクセスレベルに応じた異なる第１の鍵によって暗号化されている情報が格納される複数のブロックがつながれるブロックチェーンと、前記ブロックチェーンに情報を登録する複数のノードと、前記ノードが前記ブロックに情報を登録する際に前記ノードに第２の鍵および第４の鍵を与える認証局と、前記第１の鍵と前記第２の鍵との間の再暗号化鍵の情報が格納され前記ブロックへの情報の登録の認証を行うプロキシサーバの機能とを備え、前記複数のノードと、前記プロキシサーバあるいは前記プロキシサーバの機能を持つ前記ノードと、前記認証局と、前記認証局とはネットワークを介して接続されている。

第３の本発明の分散データ管理システムは、第２の鍵および第４の鍵が与えられるノードとプロキシサーバあるいは前記プロキシサーバの機能を持つ前記ノードとを備え、複数のアクセスレベルに分割され、かつアクセスレベルに応じた異なる第１の鍵によって暗号化されている情報が格納される複数のブロックがつながれるブロックチェーンが格納されるとともに、前記第１の鍵と第２の鍵との間の再暗号化鍵の情報が格納される分散データ管理システムのプログラムであって、ノードが前記第４の鍵で暗号化したデータを前記プロキシサーバに送って認証要求が行われる第１のステップと、前記データを受けて前記第２の鍵で復号化して、前記プロキシサーバによって前記ノードの認証が行われる第２のステップと、前記ノードは、暗号化したハッシュ値の情報を前記プロキシサーバに送る第３ステップと、前記暗号化したハッシュ値の情報を受けて、前記プロキシサーバによって前記再暗号化鍵の情報を用いて情報の正当性の認証が行われる第４のステップと、前記ノードは、前記情報の正当性の認証許可情報を受け、暗号化した新しいハッシュ値とともに情報を前記ブロックチェーンに登録する第５のステップとを実行させている。

本発明によれば、高い消失・改ざん耐性を保持しつつ指定する範囲でデータの共有を可能とする管理を実現する分散データ管理システムおよびそのプログラムを実現できる。

本発明に係る実施形態の分散データ管理システムの構成の模式図。 実施形態の分散データ管理システムの機能の模式ブロック図。 登録・利用ノードの利用者の各公開鍵と 、ブロックが分割されたレベル1～レベルmの各公開鍵との間の再暗号化鍵のマトリクスを示す図。 ブロックが分割されたレベル1～レベルmの各公開鍵と 、登録・利用ノードの利用者の各公開鍵との間の再暗号化鍵のマトリクスを示す図。 ブロックが分割されたレベル1～レベルmの各公開鍵と 、データ解析ノードの解析者の各公開鍵との間の解析者用の再暗号化鍵のマトリクスを示す図。 分散データ管理システムの登録処理における認証処理のシーケンス図。 分散データ管理システムの登録処理における血圧と体重とを登録するための処理のシーケンス図。 分散データ管理システムの登録処理におけるハッシュ値から新しいハッシュ値の計算と暗号化処理のシーケンス図。 データ解析者がデータ解析ノードを用いてブロックチェーンのブロックのデータを参照する参照処理のシーケンス図。 利用者が登録・利用ノードを用いてブロックチェーンのブロックのデータを参照する参照処理のシーケンス図。 変形例の分散データ管理システムの機能を示す模式ブロック図。 本発明の実施例1の分散データ管理システムの構成の模式図。 本発明の実施例1の分散データ管理システムの機能の模式ブロック図。 実施形態2の分散データ管理システムの構成の一例を示す模式図。 実施形態2の他例の分散データ管理システムの構成を示す模式図。 分散データ管理システムのデータ構造を示す図。 分散データ管理システムの機能の概要を示す図。 ユーザ登録処理のフロー図。 ユーザ削除処理のフロー図。 情報登録処理のフロー図。 復号化処理のフロー図。

以下、本発明の実施形態について、適宜図面を参照しながら詳細に説明する。
本発明の分散データ管理システムは、データ蓄積システムのセキュリティ管理に用いるブロックチェーンの認証にレベル付けを加えることにより、アプリケーションに適した形で消失・改ざん耐性を保持しつつ指定された範囲でデータの共有を可能とする管理を実現している。

具体的には、本発明はデータ蓄積システムのパブリックブロックチェーンの技術に下記1)～5)の仕組みを取り入れることによって、消失や改竄への耐性を持ちつつ、開示可能な範囲に応じて情報を提供する分散データ管理を実現する。
なお、ブロックチェーンとは、ハッシュポインタを使用し改竄検出が容易なデータ構造を持ち，且つ，当該データをネットワーク上に分散する多数のノードに保持させることで，高可用性及びデータ同一性等を実現する技術と定義されている。（日本ブロックチェーン協会. http://jba-web.jp/.）

1) データが蓄積されるブロックの中身をアクセスレベル（プライバシーレベル）で分割して鍵を変えて暗号化
2) 二次利用データ解析者が復号できるアクセスレベルを設定
3) 再暗号化鍵をプロキシサーバで２つのマトリクスの形で持つ
4) ブロックへの接続認証を最高アクセスレベル（例．本人または医療関係者）のみで持つ
5) ブロックの認証に必要なMerkle Treeの情報を最高アクセスレベルで暗号化
上記のような構成にすることにより、メディカルデータ、センサデータなどをレベルによって指定された範囲の人（ここでは、本人と医療関係者）によってブロックチェーンを繋げること、レベルによって指定された範囲の人とデータの解析が可能となる。

その結果、セキュリティレベル（アクセスレベル）やデータ改ざん耐性を確保しつつ、データ解析結果の報告、アラート情報を出す等の充実したヘルスケアサポートが実現できる。
図1に、本発明に係る実施形態の分散データ管理システムSの構成を模式図に示す。
実施形態の分散データ管理システムSは、Internet10 に接続されたノード（1a、1b、1c）、プロキシサーバ2、および認証局3を備えて構成されている。なお、ネットワークはInternet10 以外のネットワークでもよい。また、プロキシサーバ2 の機能は、ノード内に実現されていてもよい。

ノード（1a、1b、1c）、プロキシサーバ2、および認証局3は全て、プロセス処理能力を持つコンピュータで構成される。
すなわち、ノード（1a、1b、1c）、プロキシサーバ2、および認証局3は、それぞれCPU、記憶装置、入・出力装置を有している。ノード（1a、1b、1c）、プロキシサーバ2、および認証局3は、それぞれのCPUでプログラムを実行することで、それぞれの機能が実現される。

ノード（1a、1b、1c）は、それぞれ同じブロックチェーン4に複数のデータを蓄積する。
ノード（1a、1b、1c）は、データを登録・利用する登録・利用ノード1a、データを蓄積するデータ蓄積ノード1b、およびデータを解析するデータ解析ノード1cの3種類を想定する。登録・利用ノード1a、データ蓄積ノード1b、およびデータ解析ノード1cには、分散データ管理システムSのプログラム（ソフトウェア）が格納されている。

図2に、実施形態の分散データ管理システムSの機能を模式ブロック図に示す。
登録・利用ノード1aは、ブロックチェーン4を構築し、蓄積し、利用する。登録・利用ノード1aは、例えば、患者のパソコン、携帯端末、高機能ヘルスメータ、高機能血圧測定装置等、医者、看護師、医療従事者等のパソコンである。

蓄積ノード1bは、ブロックチェーン4を蓄積する。蓄積ノード1bは、例えば、当該分散データ管理システムSの管理者が管理するデータサーバである。
データ解析ノード1cは、登録・利用ノード1aで構築されたブロックチェーンを蓄積し、解析するノードである。データ解析ノード1cは、例えば、医療情報の解析、クリニカルパスの抽出等を行うデータ二次利用者のパソコンである。

ブロックチェーン4は、登録・利用ノード1a内で複製される。複製されたブロックチェーン4は、登録・利用ノード1a、蓄積ノード1b、データ解析ノード1cに蓄積される。
登録・利用ノード1aでブロックチェーン4を蓄積する際、プライバシー保護のプライバシーレベルによってブロック4bの内部を分割している。ここで、プライバシーレベル1を最高とする。

図2では、ブロック4bをプライバシーレベル1～プライバシーレベルmまでに分割した場合を示している。
そして、それぞれのブロック4bの分割した部分に対してプロキシ再暗号化可能な暗号（例えばBBS暗号）の公開鍵を切り替えて暗号化を行い、ブロック4bをブロックチェーン4につないで蓄積する。

＜分散データ管理システムSの手続き＞
以下、分散データ管理システムSの手続きを述べる。
なお、文Tの暗号鍵k_xによる暗号化はenc(T, k_x)と表し、この暗号化により生成される暗号文はc(T, k_x)と表す。また、暗号文c(T, k_x)の暗号鍵k_yによる復号化はdec(c(T, k_x), k_y)と表す。公開鍵はpk_xと表し、秘密鍵はsk_xと表す。

公開鍵pk_xで暗号化された暗号文c(T, pk_x)から再暗号化鍵rk_xyでの再暗号化はreenc(c(T, k_x), rk_xy)で表す。

図２において、登録・利用ノード1aのユーザuxは公開鍵pk_uxをもち、秘密鍵sk_uxをもつ。ブロックチェーン４のブロック４ｂに蓄積された情報は、プライバシーレベル1～mに分割され、プライバシーレベル別の公開鍵pk_l1～pk_lmで暗号化されている。
データ解析ノード1cのユーザazは公開鍵pk_azをもち、秘密鍵sk_azをもつ。

認証局3は、予め、プライバシーレベルl₁～l_mそれぞれに対する公開鍵と秘密鍵のペア (pk_l1, sk_l1), …, (pk_lm, sk_lm) と、登録・利用ノード1aの各利用者 u₁ ～u_nに対する公開鍵と秘密鍵のペア (pk_u1, sk_u1), …, (pk_un, sk_un)を作成する。

図３に、登録・利用ノード1aの利用者u1～unの各公開鍵pk_u1-nと 、ブロック４ｂが分割されたプライバシーレベル1～mの各公開鍵pk_l1-m との間の再暗号化鍵のマトリクスRK_ulを示す。
また、認証局3は、図３に示す登録・利用ノード1aの利用者u1～unの各公開鍵pk_u1-nと 、ブロック４ｂが分割されたレベル1～レベルmの各公開鍵pk_l1-m の間の再暗号化鍵のマトリクスRK_ulを作成する。

ここで、再暗号化鍵のマトリクスRK_ulのx列目、y行目の要素RK_ul[x,y]は、利用者uｘの公開鍵pk_uxからプライバシーレベルｙの公開鍵pk_lyへの再暗号化鍵rk_ux1yに対応する。

図４に、ブロック４ｂが分割されたプライバシーレベル1～レベルmの各公開鍵pk_l1-m と 、登録・利用ノード1aの利用者u1～unの各公開鍵pk_u1-nとの間の再暗号化鍵のマトリクスRK_luを示す。
認証局3は、図４に示すブロック４ｂが分割されたプライバシーレベル1～レベルmの各公開鍵pk_l1-m と 、登録・利用ノード1aの利用者u1～nの各公開鍵pk_u1-nとの間の再暗号化鍵のマトリクスRK_luを作成する。

ここで、再暗号化鍵のマトリクスRK_luのx列目、y行目の要素RK_lu[x,y]は、プライバシーレベルｘの公開鍵pk_lxから利用者ｙの公開鍵pk_uyへの再暗号化鍵rk_lxuyに対応している。

図５に、ブロック４ｂが分割されたプライバシーレベル1～mの各公開鍵pk_l1-m と 、データ解析ノード1cの解析者1～qの各公開鍵pk_a1-qとの間の解析者用の再暗号化鍵のマトリクスRK_laを示す。
認証局3は、図５に示すブロック４ｂが分割されたプライバシーレベル1～mの各公開鍵pk_l1-m と 、データ解析ノード1cのデータ解析者1～qの各公開鍵pk_a1-qとの間のデータ解析者用の再暗号化鍵のマトリクスRK_laを作成する。

ここで、再暗号化鍵のマトリクスRK_laのx列目、y行目の要素RK_l [x,y]は、プライバシーレベルｘの公開鍵pk_lxから解析者ｙの公開鍵pk_uyへの再暗号化鍵rk_lxayに対応している。
解析者用のマトリクスRK_laはRK_luと同様であるが、プライバシーレベル1～mのうちの許可されるレベル以下の行だけを持ち、それより上のプライバシーレベルの行は持たない。図５に示す解析者用のマトリクスRK_laの例ではl₁の行を持たない例を示している。

図２に示すように、プロキシサーバ2は、認証局3から登録・利用ノード1aの利用者u1～unの各公開鍵pk_u1-n（pk_u1～pk_un）、ブロック４ｂが分割されたレベル1～レベルmの各公開鍵pk_l1-m（pk_l1 ～pk_lm）、 データ解析ノード1cの解析者1～qの各公開鍵pk_a1-q（pk_a1～pk_aq）を受け取り、保持する。また、プロキシサーバ2は、認証局3から、再暗号化鍵の２つのマトリクスRK_ul、RK_luと、マトリクスRK_laを受け取り、保持する。また、プロキシサーバ2は、利用者の役割情報を持つ。利用者の役割情報とは、利用者が患者、医者、データ解析者等の属性情報を意味する。

なお、プロキシサーバ2は信頼できると仮定するが、プロキシサーバ2から公開鍵pk_u1-n、pk_l1-m、pk_a1-qや再暗号化鍵のマトリクスRK_ul、RK_lu、RK_laが流出しても、プライバシーレベル１～mの秘密鍵sk_l1-m（sk_l1～sk_lm）、利用者u1～利用者unの秘密鍵sk_u1-n（sk_u1～sk_un）を持たない者には復号化することはできない。

＜分散データ管理システムSの登録処理＞
次に、分散データ管理システムSの登録処理について説明する。
図6～図8に、分散データ管理システムSの登録処理における認証処理のシーケンス図を示す。

図6、下記の図7、図8に示す分散データ管理システムSの登録処理は、登録・利用ノード1a、プロキシサーバ2、および認証局3のそれぞれに格納されるソフトウェア（プログラム）によって行われる。
利用者 u_x が登録・利用ノード1a（図1参照）で分散データ管理システムSにログインして鍵を要求すると（図６のステップS100）、利用者 u_x が操作する登録・利用ノード1aは、認証局3のサーバから公開鍵と秘密鍵(pk_ux, sk_ux)を受け取る（ステップS101）。

登録・利用ノード1aは、以下のようにして、まず予めプロキシサーバ2の認証を受ける。

＜登録・利用ノード1aに対する認証＞
認証のための一つの方法としては、登録・利用ノード1aがプロキシサーバ2に認証要求を利用者 u_x の公開鍵pk_uxとともに送る（ステップS102）。すると、プロキシサーバ2側で乱数Aを生成し保持する（ステップS103）。乱数Aを送られた公開鍵pk_uxで暗号化してc(A, pk_ux)を生成し（ステップS104）、利用者 u_xの登録・利用ノード1aに返す（ステップS105）。

利用者u_xの登録・利用ノード1aでは、自分の持つ秘密鍵sk_uxでc(A, pk_ux)を復号化して、Aを得る（ステップS106）。
そして、例えばA+1を計算して、秘密鍵sk_uxでA+1を暗号化してc(A+1, sk_ux) を生成する（ステップS107）。そして、登録・利用ノード1aは、c(A+1, sk_ux) をプロキシサーバ2に送る（ステップS108）。

プロキシサーバ2では、c(A+1, sk_ux)を公開鍵pk_uxで復号化してA+1を得て、保持していたAとの間で整合性を確認することで、登録・利用ノード1aの認証を行うことができる（ステップS109）。
なお、上述以外の方法で認証を行うことも可能である。

＜血圧値Bと体重値Wの登録＞
図7に、分散データ管理システムSの登録処理における血圧値Bと体重値Wとを登録するための処理のシーケンス図を示す。
次に、利用者 u_x が血圧値B（タイプT₁）のデータを登録・利用ノード1aでブロックチェーン4に格納したい場合、利用者 u_x は、登録・利用ノード1aに血圧 (T₁)に 血圧値Bを入力する（図7のステップS110）。

登録・利用ノード1aはBを公開鍵pk_uxで暗号化してc(B, pk_ux)を生成する（ステップS111）。
そして、登録・利用ノード1aは設定したいプライバシーレベルL₂とA+2の情報とともに、秘密鍵sk_uxで暗号化してc((c(B, pk_ux), L₂, A+2), sk_ux)を生成する（ステップS112）。そして、登録・利用ノード1aはc((c(B, pk_ux), L₂, A+2), sk_ux)をプロキシサーバ2に送る（ステップS113）。

プロキシサーバ2では、利用者 u_x の公開鍵pk_uxを使ってc((c(B, pk_ux), L₂, A+2), sk_ux)を復号化して(c(B, pk_ux), L₂, A+2)を得、A+2の整合性を確認する（ステップS114）。
プロキシサーバ2は、L₂(プライバシーレベル2)という指定に従ってRK_ul[x,2]（利用者 u_x のプライバシーレベル2）の再暗号化鍵を用いて再暗号化を行い、c(B, pk_l2)を生成する（ステップS115）。

そして、プロキシサーバ2は、c(B, pk_l2)を利用者 u_xの登録・利用ノード1aに送り返す（ステップS116）。
利用者 u_xの登録・利用ノード1aは受け取ったc(B, pk_l2)を記憶媒体に保持する（ステップS117）。

引き続き、利用者 u_x が体重値WのデータをプライバシーレベルL₃でブロックチェーン4に格納したい場合、利用者 u_x は登録・利用ノード1aに体重(T₂)に体重値Wを入力する（ステップS118）。
そして、登録・利用ノード1aは公開鍵pk_uxで体重値Wを暗号化してc(W, pk_ux)を生成する（ステップS119）。

登録・利用ノード1aは、プライバシーレベルL₃とA+3の情報とともに秘密鍵sk_uxで暗号化してc((c(W, pk_ux), L₃, A+3), sk_ux)を生成する（ステップS120）。
そして、登録・利用ノード1aは、c((c(W, pk_ux), L₃, A+3), sk_ux)をプロキシサーバ2に送る（ステップS121）。プロキシサーバ2では、利用者 u_x の公開鍵pk_uxを使って復号化して(c(W, pk_ux), L₃, A+3)を得る。プロキシサーバ2は、(c(W, pk_ux), L₃, A+3)で保持していたA+2と、A+3の整合性を確認する（ステップS122）。

その後、プロキシサーバ2は、プライバシーレベルL₃の指定に従ってRK_ul[x,3]の再暗号化鍵を用いて再暗号化を行い、c(W, pk_l3)を生成する（ステップS123）。
そして、プロキシサーバ2は、c(W, pk_l3)を利用者 u_xの登録・利用ノード1aに送り返す（ステップS124）。

利用者 u_xの登録・利用ノード1aは受け取ったc(W, pk_l3)を記憶媒体に保持する。

＜新しいハッシュ値の計算と暗号化処理＞
図8に、分散データ管理システムSの登録処理におけるハッシュ値から新しいハッシュ値の計算と暗号化処理のシーケンス図を示す。ハッシュ値の処理は、これとは別に、ブロックチェーンのツール等で提供されているものを利用することも可能である。
登録・利用ノード1aで保持するc(B, pk_l2)、c(W, pk_l3)等をブロックチェーン4に登録するためには、ブロックチェーン4の最新のブロック4b1（図２参照）に格納されたハッシュ情報が必要となる。

このため、利用者 u_x の登録・利用ノード1aは、ブロックチェーン4の最新のブロック4b1のトップのプライバシーレベルL₁の公開鍵pk_l1で暗号化されたハッシュ情報c(H_j, pk_l1)を取り出す（ステップS126）。
登録・利用ノード1aは、ハッシュ情報c(H_j, pk_l1)と、L₁とA+4を自身の秘密鍵sk_uxで暗号化し、c((c(H_j, pk_l1), L₁, A+4), sk_ux)を生成する（ステップS127）。

そして、登録・利用ノード1aは、c((c(H_j, pk_l1), L₁, A+4), sk_ux)をプロキシサーバ2に送る（ステップS128）。
プロキシサーバ2では、利用者 u_x の公開鍵pk_uxによってc((c(H_j, pk_l1), L₁, A+4), sk_ux)を復号化し、(c(H_j, pk_l1), L₁, A+4)を得て、保持していたA+3と、A+4の整合性を確認する（ステップS129）。

プロキシサーバ2は、A+4の整合性を確認後、プライバシーレベルL₁の指定に従ってRK_lu[1,x]の再暗号化鍵を用いてc(H_j, pk_l1)から、c(H_j, pk_ux)に再暗号化する（ステップS130）。そして、プロキシサーバ2は、利用者 u_xの登録・利用ノード1aにc(H_j, pk_ux)を返す（ステップS131）。

利用者 u_x の登録・利用ノード1aは、利用者 u_xの秘密鍵sk_uxを用いてc(H_j, pk_ux)を復号化して現在のハッシュ値H_jを取り出す（ステップS132）。そして、登録・利用ノード1aは、現在のハッシュ値H_jを用いて新しいハッシュ値H_j+1を計算して生成する（ステップS133）。

次に、登録・利用ノード1aは、利用者 u_xの公開鍵pk_uxを用いて新しいハッシュ値H_j+1を暗号化してc(H_j+1, pk_ux)を生成する（ステップS134）。そして、登録・利用ノード1aは、c(H_j+1, pk_ux)と、新しいハッシュ値H_j+1が格納されるプライバシーレベルL₁とA+5を利用者 u_xの秘密鍵sk_uxで暗号化して、c((c(H_j+1, pk_ux), L₁, A+5), sk_ux)を生成する（ステップS135）。登録・利用ノード1aは、c((c(H_j+1, pk_ux), L₁, A+5), sk_ux)をプロキシサーバ2に送る（ステップS136）。

プロキシサーバ2では、利用者 u_xの公開鍵pk_uxによって、c((c(H_j+1, pk_ux), L₁, A+5), sk_ux)を復号化し、(c(H_j+1, pk_ux), L₁, A+5)を得、保持していたA+4と、A+5の整合性を確認する（ステップS137）。
その後、プロキシサーバ2は、登録・利用ノード1aからのプライバシーレベルL₁の指定に従ってRK_ul[x,1]の再暗号化鍵を用いてc(H_j+1, pk_ux)から再暗号化して、c(H_j+1, pk_l1)を生成する（ステップS138）。そして、プロキシサーバ2は、c(H_j+1, pk_l1)を利用者 u_xの登録・利用ノード1aに返す（ステップS139）。

利用者 u_xの登録・利用ノード1aは、受け取ったc(H_j+1, pk_l1)を、タイプT₁、T₂に相当する保持したc(B, pk_l2)およびc(W, pk_l3)からの[T₁, c(B, pk_l2)]、[T₂, c(W, pk_l3)] とともに、ブロック4bを構成し、ブロック4bのIDの ID_k と一緒にブロックチェーン4に接続する（ステップS140）。

＜データ解析者a₁～ a_qのデータ参照の処理＞
次に、データ解析者a₁～ a_qのブロックチェーン4のブロック4bのデータを参照する処理について説明する。

図2に示すように、データ解析者a～a_qのデータ解析ノード1cにも暗号化されたブロックチェーン4が保持（格納）される。
しかし、データ解析者a～a_qの各データ解析ノード1cは、データ解析者用の再暗号化鍵のマトリクスRK_la（図５参照）の構成から、指定されたプライバシーレベルLより上位に対応する 再暗号化鍵RK_la[L,x] を持たないため、指定されたプライバシーレベルのLRK_2a[L,x]以下のプライバシーレベルしか再暗号化できない。つまりデータ解析者a～a_qは、指定されたプライバシーレベルL以下のブロック4bのデータしか秘密鍵で平文に復号できず、参照できない。

加えて、データ解析者a～a_qのデータ解析ノード1cは、トップレベルのプライバシーレベルで暗号化されたハッシュ情報は再暗号できないため、データ解析者a～a_qは整合性を持った新たなブロック4bをブロックチェーン4につなげることができない。

以下、データ解析者a_zがブロックチェーン4のブロック4bのデータを参照する処理を説明する。
ここで、データ解析者a_zは、プライバシーレベルL₃以下は許可されているものの、プライバシーレベルL₂以上は許可されていないものとする。

図9に、データ解析者a_zがデータ解析ノード1cを用いてブロックチェーン4のブロック4bのデータを参照する参照処理のシーケンス図を示す。
分散データ管理システムSの参照処理は、データ解析ノード1c、プロキシサーバ2、および認証局3のそれぞれに格納されるソフトウェア（プログラム）によって行われる。

データ解析者ａ_z がデータ解析ノード1cで分散データ管理システムSにログインして鍵を要求すると（図9のステップS200）、データ解析者ａ_zが操作するデータ解析ノード1cは、認証局3のサーバから公開鍵と秘密鍵(pk_az, sk_az)を受け取る（ステップS201）。

データ解析ノード1cは、以下のようにして、まず予めプロキシサーバ2の認証を受ける。
認証のための一つの方法としては、データ解析ノード1cがプロキシサーバ2に認証要求をデータ解析者ａ_zの公開鍵pk_azとともに送る（ステップS202）。すると、プロキシサーバ2側で乱数Aを生成し保持する（ステップS203）。乱数Aを送られた公開鍵pk_azで暗号化してc(A, pk_az)を生成し（ステップS204）、 データ解析者ａ_zのデータ解析ノード1cに返す（ステップS205）。

データ解析ノード1cでは、データ解析者ａ_zが持つ秘密鍵sk_azでc(A, pk_az)を復号化して（ステップS206）、Aを得る。そして、例えばA+1を計算して、秘密鍵sk_azでA+1を暗号化してc(A+1, sk_az) を生成する（ステップS207）。そして、データ解析ノード1cは、c(A+1, sk_az) をプロキシサーバ2に送る（ステップS208）。

プロキシサーバ2では、c(A+1, sk_az)を公開鍵pk_azで復号化してA+1を得て、保持していたAとの間で整合性を確認することで認証を行うことができる（ステップS209）。
なお、上述以外の方法で利用者であるデータ解析ノード1cの認証を行うことも可能である。

続いて、データ解析者ａ_zがブロック4b（ID_k ）の体重値W(T₂)を参照する処理を説明する。

データ解析者ａ_zがブロック4b（ID_k ）の体重(T₂)をデータ解析ノード1cに入力して要求する（図９のステップS210）。データ解析ノード1cは、ID_kとT₂を用いて、ブロックチェーン4から[T₂, L₃, c(W, pk_l3)] を取り出す（ステップS211）。そして、データ解析ノード1cは、(c(W, pk_l3), L₃, A+2)を秘密鍵 sk_azで暗号化してc((c(W, pk_l3), L₃, A+2), sk_az) をプロキシサーバ2に送る（ステップS212）。プロキシサーバ2は、c((c(W, pk_l3), L₃, A+2), sk_az)を公開鍵pk_azで復号化して(c(W, pk_l3), L₃, A+2)を得、保持していたAと、A+2の正当性を確認して認証を行う（ステップS213）。

プロキシサーバ2はRK_la [z,3]を用いて(c(W, pk_l3)を再暗号化reenc(c(W, pk_l3), RK_la [z,3]) して、c(W, pk_az)を得る（ステップS214）。そして、プロキシサーバ2は、c(W, pk_az)をデータ解析ノード1cに送る（ステップS215）。

データ解析ノード1cは、データ解析者ａ_zの秘密鍵 sk_azでc(W, pk_az)を複合化してW（体重）を得る（ステップS216）。
続いて、データ解析者ａ_zがブロック4b（ID_k ）の血圧値B (T₁)を参照する処理を説明する。

データ解析者ａ_zがブロック4b（ID_k ）の血圧値B (T₁)をデータ解析ノード1cに入力して要求する（図9のステップS217）。データ解析ノード1cは、ID_kとT₁を用いて、ブロックチェーン4から[T₁, L₂, c(B, pk_l2)] を取り出す（ステップS218）。そして、データ解析ノード1cは、(c(B, pk_l2), L₂, A+3)を、データ解析者ａ_zの秘密鍵 sk_azで暗号化してc(c(B, pk_l2), L₂, A+3), sk_az) をプロキシサーバ2に送る（ステップS219）。プロキシサーバ2は、c(c(B, pk_l2), L₂, A+3), sk_az)を、データ解析者ａ_zの公開鍵pk_azで復号化して(c(B, pk_l2), L₂, A+3)を得、保持していたA+2と、A+3の正当性を確認して認証を行う（ステップS220）。

プロキシサーバ2は再暗号化を試みるが、データ解析者ａ_zは、プライバシーレベルL₂以上は許可されていないのでRK_la [z,2]が無いため、再暗号化できない（ステップS221）。そのため、データ解析者ａ_zのデータ解析ノード1cには、プロキシサーバ2からNG情報が送られ（ステップS222）、データ解析者ａ_zのデータ解析ノード1cは、アクセス不可能なプライバシーレベルL₂以上の 情報(血圧値B)は取得不可となる（ステップS223）。

＜利用者 u_yのデータ参照の処理＞
次に、利用者 u_yがブロックチェーン4のブロック4bのデータを参照する際の参照処理について説明する。
図10に、利用者 u_xが登録・利用ノード1aを用いてブロックチェーン4のブロック4bのデータを参照する参照処理のシーケンス図を示す。

分散データ管理システムSの参照処理は、登録・利用ノード1a、プロキシサーバ2、および認証局3のそれぞれに格納されるソフトウェア（プログラム）によって行われる。
利用者 u_xが登録・利用ノード1aで分散データ管理システムSにログインして鍵を要求すると（図9のステップS300）、登録・利用ノード1aは、認証局3のサーバから公開鍵と秘密鍵(pk_uy, sk_uy)を受け取る（ステップS301）。

登録・利用ノード1aは、以下のようにして、まず予めプロキシサーバ2の認証を受ける。
認証のための一つの方法としては、登録・利用ノード1aがプロキシサーバ2に認証要求を利用者 u_xの公開鍵pk_uyとともに送る（ステップS302）。すると、プロキシサーバ2側で乱数Aを生成し保持する（ステップS303）。そして、乱数Aを送られた公開鍵pk_uyで暗号化してc(A, pk_uyz)を生成し（ステップS304）、利用者 u_x の登録・利用ノード1aに返す（ステップS305）。

利用者 u_xの登録・利用ノード1aでは、自分の持つ秘密鍵sk_uyでc(A, pk_uy)を復号化して（ステップS306）、Aを得る。そして、例えばA+1を計算して、秘密鍵sk_uyでA+1を暗号化してc(A+1, sk_uy) を生成する（ステップS307）。そして、登録・利用ノード1aは、c(A+1, sk_uy) をプロキシサーバ2に送る（ステップS308）。

プロキシサーバ2では、c(A+1, sk_uy)を公開鍵pk_uyで復号化してA+1を得て、保持していたAとの間で整合性を確認することで認証を行うことができる（ステップS309）。
なお、上述以外の方法で認証を行うことも可能である。

続いて、利用者 u_xがブロック4bのID_k の体重(T₂)を参照する処理を説明する。
次に、利用者 u_xがブロック4bのID_k の体重(T₂)を登録・利用ノード1aに入力して要求する（図９のステップS310）。データ解析ノード1cは、ID_kとT₂を用いて、ブロックチェーン4から[T₂, L₃, c(W, pk_l3)] を取り出す（ステップS311）。そして、登録・利用ノード1aは、(c(W, pk_l3), L₃, A+2)を秘密鍵 sk_uyで暗号化してc((c(W, pk_l3), L₃, A+2), sk_uy) をプロキシサーバ2に送る（ステップS312）。プロキシサーバ2は、c((c(W, pk_l3), L₃, A+2), sk_uy)を、利用者 u_xの公開鍵pk_uyで復号化して(c(W, pk_l3), L₃, A+2)を得、保持していたA+1との間でA+2の正当性を確認して認証を行う（ステップS313）。

プロキシサーバ2はRK_lu [ｙ,3]を用いて(c(W, pk_l3))を再暗号化reenc(c(W, pk_l3), RK_lu [y,3]) して、c(W, pk_uy)を得る（ステップS314）。そして、プロキシサーバ2は、c(W, pk_uy)を登録・利用ノード1aに送る（ステップS315）。

登録・利用ノード1aは、利用者 u_xの秘密鍵 sk_uyでc(W, pk_uy)を復号化して体重値W(T₂)を得る（ステップS316）。
続いて、利用者 u_xがブロック4b（ID_k ）の血圧値B (T₁)を参照する処理を説明する。

次に、利用者 u_xがブロック4bのID_k の血圧値B (T₁)を登録・利用ノード1aに入力して要求する（図10のステップS317）。登録・利用ノード1aは、ID_kとT₁を用いて、ブロックチェーン4から[T₁, L₂, c(B, pk_l2)] を取り出す（ステップS318）。そして、登録・利用ノード1aは、(c(B, pk_l2), L₂, A+3)を秘密鍵 sk_uyで暗号化してc(c(B, pk_l2), L₂, A+3), sk_uy) をプロキシサーバ2に送る（ステップS319）。プロキシサーバ2は、c(c(B, pk_l2), L₂, A+3), sk_uy)を公開鍵pk_uyで復号化して(c(B, pk_l2), L₂, A+3)を得、保持していたA+2との間でA+3の正当性を確認して認証を行う（ステップS320）。

プロキシサーバ2はRK_lu [y,2]で再暗号化を試み、reenc(c(B, pk_l2), RK_lu [y,2])から c(B, pk_uy)を得る（ステップS321）。そして、 プロキシサーバ2は、c(B, pk_uy)を登録・利用ノード1aに送る（ステップS322）。登録・利用ノード1aは、c(B, pk_uy)を秘密鍵sk_uyを使って復号化し、血圧値B (T₁)を得る（ステップS323）。

＜分散データ管理システムSによる効果＞
従来、ブロックチェーン技術を用いて医療情報を蓄積するアプローチは、消失・改竄を防ぐことが可能なために既に注目を集めている。しかしながら、これまでのところ二次利用を考慮しつつもプライバシーを適切に保護する手法は提案されていない。つまり、本人（患者）、医療従事者、医療情報の二次利用データ解析者、運用管理者という異なる役割に対して、情報の消失、改竄、漏洩を防いで開示範囲を調整する手法は、必要性が高いにも関わらずまだ実現されていない。

そこで、本分散データ管理システムSは、複数のプライバシーレベルl₁～l_mに分割され、かつプライバシーレベルl₁～l_mに応じた異なる公開鍵pk_l1～pk_lm（第１の鍵）によって暗号化されている情報が格納される複数のブロック4bがつながれるブロックチェーン4と、ブロックチェーン4に情報を登録する複数のノード（1a）と、ノード（1a）がブロック4bに情報を登録する際にノード（1a）に公開鍵pk_u1-n第２の鍵（公開鍵pk_u1-n）を与える認証局3と、第１の鍵公開鍵pk_l1～pk_lmと第２の鍵（公開鍵pk_u1-n）との間の再暗号化鍵rk_lxay、rk_ux1yの情報が格納されブロック4bへの情報の登録の認証を行うプロキシサーバ2とを備えている。ここで、複数のノード（1a、）と、プロキシサーバ2と、認証局3とはInternet（ネットワーク）10を介して接続されている。

そのため、分散データ管理システムSでは、例えば、複数の機関の医療履歴や個人の生理計測データをブロックチェーン4に安全に蓄積し、プライバシーに応じたプライバシーレベルに従って、二次利用等に利用することができる。

つまり、ブロック4ｂに格納される情報は、複数のプライバシーLに分割され、かつプライバシーレベル Lに応じた異なる第１の鍵（pk_l1～pk_lm）によって暗号化されている。
また、本分散データ管理システムSにより、医療情報の消失や改竄、漏洩を防いで医療履歴や個人の生理計測データを分散して蓄積できる。

具体的には、ブロック4ｂへの情報の登録に際して用いられる再暗号化鍵rk_lxay、rk_ux1yは、第１の鍵（pk_l1～pk_lm）と登録を行う登録・利用ノード1aがもつ第２の鍵pk_u1-nのとの間で決められている。加えて、情報の改竄、漏洩を防ぐため、ブロック4ｂへの情報の登録に用いるハッシュ値H_j、H_j+1の情報は、最高のアクセスレベルの第１の鍵（pk_l）によって暗号化されている。

また、第１の鍵（pk_l1～pk_lm）と前記第２の鍵pk_u1-nとがマトリクスの形で格納されるので、処理が容易である。
加えて、二次データ解析者に、プライバシーレベルに従って適切なレベルのデータを提供することが可能になる。

具体的には、ブロック4bの情報は、利用者または二次データ解析者がもつアクセスレベルの第４の鍵 （秘密鍵sk_az）で復号化される。
そのため、データ解析による医療の発展に寄与できる。

＜変形例＞
図１１に、変形例の分散データ管理システムSAの機能の模式ブロック図を示す。
変形例の分散データ管理システムSAは、実施形態1（図2参照）のブロックチェーン4のブロック4bに格納されるデータを、図11に示すデータサーバ11に格納する構成としたものである。
データサーバ11は、格納するデータの改ざん防止、消失防止の機能を具備しているものが望ましい。
その他の構成は、実施形態1の分散データ管理システムSと同様であるから、同様な構成要素には同一の符号を付して示し、詳細な説明は省略する。

変形例の分散データ管理システムSAは、Internet10 に接続されたノード（1a、1b、1c）、プロキシサーバ2、認証局3、およびデーダサーバ11を備えて構成されている。なお、ネットワークはInternet10 以外のネットワークでもよい。
ノード（1a、1b、1c）に格納されるブロックチェーン24のブロック24bは、プライバシーレベル1～mに分割されている。そして、ブロック24bには、データの所在を示すポインタｐ₁～ｐ_mがプライバシーレベル1～m別の公開鍵pk_l1～pk_lmで暗号化されて格納されている。

デーダサーバ11には、プライバシーレベル1～m別のデータd₁～d_mがそれぞれポインタp₁～p_mが示すプライバシーレベル1～m別に分割されて格納されている。データd₁～d_mは、それぞれプライバシーレベル1～m別の公開鍵pk_l1～pk_lmで暗号化されている。

上記構成により、データd₁～d_mが登録される際には、データd₁～d_mがそれぞれデーダサーバ11にプライバシーレベル1～m別の公開鍵pk_l1～pk_lmで暗号化され格納される。そして、登録されるデータd₁～d_mのそれぞれの所在を示すポインタp₁～p_mが暗号化されてブロックチェーン24のブロック24bにプライバシーレベル1～m別に分割され格納される。

一方、登録されたデータd₁～d_mを参照する際には、ブロックチェーン24のブロック24bのポインタｐ₁～ｐ_mを介在して、デーダサーバ11のデータd₁～d_mにアクセスされる。
変形例によれば、分散データ管理システムSAの製作の多様化に寄与できる。

＜実施例＞
本発明の実施例として考えられるものの一つとしては、医療における電子カルテの分散蓄積とその二次利用、健康に関する生理計測データの分散蓄積とその二次利用、あるいは電子カルテと生理計測データを組み合わせた分散蓄積とその二次利用等が考えられる。

電子カルテの利用は、様々な医療機関で進んでおり、異なる病院やクリニック、薬局等の医療情報を統合することで、重複した検査の削減や、副作用のある薬剤の同時投薬の回避が容易になる。
さらに、IoT技術の進歩と健康に関する関心の高まりから、各個人の日々の生活の中で計測される体重、血圧、体温等々の生理計測データを、ネットワークを介して収集することが可能になっている。さらに、異なる医療機関、薬局等の医療情報と、日々の生理計測データとを組み合わせることで、健康管理や高齢者の介護に適用することが考えられている。

その際に、それらの電子カルテや生理計測データの二次利用として、それらのデータを統合して解析することが重要となる。本発明は、そのような状況に適しており、活用できる。

図12に、本発明の実施例1の分散データ管理システムS1の構成を模式図に示す。
例えば、実施例1の分散データ管理システムS1は、インターネット10を介して、高機能ヘルスメータ5、高機能血圧計6、携帯端末7、パソコン8、クラウドストレージサーバ9、データ解析ノード11c、プロキシサーバ12、および認証局13が接続されている。

分散データ管理システムS1では、インターネット10に接続したデータ収集が可能な高機能ヘルスメータ5や、高機能血圧計6の情報、あるいはスマートフォンのような携帯端末7による歩数情報等を、個人のパソコン8にインターネット10 等を介して集積する。そして、パソコン8から本実施形態のブロックチェーン4に集積した情報を、任意のタイミング（例えば、情報を取得した都度や１日に1回等）で、実施形態で説明したブロックチェーン4に登録する。

こうして、高機能ヘルスメータ5、高機能血圧計6、携帯端末7の各情報をブロックチェーン4の形で自分のパソコン8やクラウドストレージ9、あるいは病院、データ解析者のコンピュータのデータ解析ノード11c等に格納（保持）する。
その際、上述の実施形態により、本人である患者あるいは医療従事者、医療情報の二次利用データ解析者、分散データ管理システムS1の運用管理者等が適切な範囲の登録されたデータを見ることができる。例えば、患者の氏名、連絡先等は最上位のプライバシーレベルとし、患者本人と医療従事者しか見ることができない。

一方、例えば、プライバシーレベルの設定により、患者を匿名化したIDや処置履歴、生理計測データは、患者本人、医療従事者、二次利用のためのデータ解析者には見ることができるが、他の患者、運用管理者、第三者からは見ることができないようにする。

また、運用管理者はブロック４ｂのリンク情報だけは見ることができる、といった公開範囲の調整をプライバシーレベルの設定により行うことができる。

図１３に、本発明の実施例1の分散データ管理システムS1の機能を模式ブロック図に示す。
プロキシサーバ12は、患者、医療従事者等の利用者u１～uｎ（u₁, …, u_n）、二次利用データ解析者a１～a１ｑ（a₁, …, a_q）、運用管理者等の各人の役割の情報と、利用者u１～uｎの公開鍵pk_u1-n（pk_u1～pk_un）、プライバシーレベルの 公開鍵pk_l1-m（ pk_l1～pk_lm）、 二次利用データ解析者a１～aｑの公開鍵pk_a1-q（pk_a1～pk_aq）と、再暗号化鍵の２つのマトリクスRK_ul、RK_luと、データ参照用の再暗号化鍵のマトリクスRK_laを認証局13から受け取り、記憶媒体に保持する。

例えば、患者である利用者u_xのネットワーク（インターネット10）に接続された高機能血圧計6で測定した血圧値B1や高機能ヘルスメータ5で測定した体重値W1をブロック14bとしてブロックチェーン14に繋げて蓄積する。

そのために、利用者u_xのパソコン8は予めプロキシサーバ12で認証を行った後、利用者u_xである患者の公開鍵pk_uで血圧値B1や体重値W1を暗号化して、プロキシサーバ12に送る。プロキシサーバ12では、再暗号化鍵のマトリクスRK_ulの再暗号化鍵を用いて、それぞれの対応するプライバシーレベル（例えば、血圧値B1はプライバシーレベルL₂、体重値W1はプライバシーレベルL₃など）の各公開鍵（pk_l2, pk_l3）に再暗号化して利用者u_xのパソコン8に戻す。

利用者u_xのパソコン8は、対応するブロックチェーン14の先頭のブロック14bのトップのプライバシーレベルL₁の公開鍵pk_l1で暗号化されたハッシュ情報（H_j）を取り出し、プロキシサーバ12に送る。プロキシサーバ12は、RK_luの再暗号化鍵を用いて利用者u_xの公開鍵k_uxに再暗号化し、利用者u_xのパソコン8に戻す。

さらに、利用者u_xのパソコン8では、利用者u_xのパソコン8が持つ秘密鍵sk_uxで平文に戻し、現在のハッシュ値H_jに基づき新しいハッシュ値H_j+1を計算する。
そして、利用者u_xのパソコン8は、新しいハッシュ値H_j+1を公開鍵pk_uxで暗号化し、プロキシサーバ12に送る。プロキシサーバ12では、マトリックスRK_ulの再暗号化鍵を用いて、トップのプライバシーレベルL₁の公開鍵pk_l1に再暗号化し、暗号化された血圧値B1や体重値W1と一緒にブロック14bとして、ブロックチェーン14に接続する。

インターネット10等のネットワークに接続された個々の高機能血圧計6や高機能ヘルスメータ5に本実施形態の手法を搭載することで、直接高機能血圧計6や高機能ヘルスメータ5からブロックチェーン14に繋げることも、個人のパソコン8で一回データをまとめて、まとめた形にして、パソコン8でブロックチェーン14に繋げることも可能である。

医者、看護師、薬剤師といった医療従事者u_yが、患者u_xの電子カルテの情報をブロックチェーン14に登録する際も、患者u_xの秘密鍵sk_uxの入ったICカード等を用いて、上記と同様の手順で登録することができる。
一方、二次利用データ解析者a_z、運用管理者は、トップのプライバシーレベルL₁に対応する再暗号化鍵を持たないため、ハッシュ情報を取り出すことができず、ブロックチェーン14に登録することはできないが、対応するプライバシーレベルの情報はマトリクスRK_laの再暗号化鍵を用いた再暗号化で得ることができる。

対応する秘密鍵の保持者のみが復号化できるため、患者u_x、医療従事者u_y、二次利用データ解析者a_z、運用管理者以外の秘密鍵を持たない者には秘匿性が保たれる。さらにブロックチェーン技術により消失、改竄からも保護される。

＜＜実施形態2＞＞
図14に、実施形態2の分散データ管理システムS2の構成の一例の模式図を示す。
分散データ管理システムS2は、パソコン等の端末21、携帯端末22、高機能血圧計23や高機能ヘルスメータ24がインターネット10で接続されている。

実施形態2では、ソフトウェアの一例として、Hyperledger Fabric（登録商標）を用いるものとして説明する。なお、Hyperledger Fabric（登録商標）とは、2015 年12 月にLinux Fundation によって開始されたオープンソースのブロックチェーンプラットフォームのHyperledgerのプロジェクトの1 つである。

分散データ管理システムS2は、インターネット10のネットワークを使用している。なお、ネットワークは、インターネット10以外でもよい。
端末21、携帯端末22には、分散データ管理システムS2のソフトウェアがインストールされている。
なお、端末21、携帯端末22がインターネット10で接続されたサーバ（図示せず）に格納される分散データ管理システムS2のソフトウェアにアクセスする構成としてもよい。

Application26は、Hyperledger Fabric（登録商標）が提供するオープンソースをカスタマイズしたものである。
分散データ管理システムS2は、Hyperledger Fabric（登録商標）におけるComposerの機能であるPlaygroundを使用する。Playgroundは、Hyperledger Fabric（登録商標）が提供する入出力インターフェースのツールである。本構成の場合、クラウド上でファイル作成や動作テストを行えるが他のノード、例えば、端末21、携帯端末22とは共有はしていない。

医師Aや解析者B、患者は、端末21、携帯端末22を操作して、Cardと称されるIDを入力することで、分散データ管理システムS2にアクセスされる。
端末21や携帯端末22には、実施形態１と同様なブロックチェーン4が格納されている。なお、前記した変形例（図11参照）に示すように、ブロックチェーン24のブロック24bにポインタp₁～p_mを格納し、デーダサーバ11にポインタp₁～p_mが示すデータd₁～d_mを格納する構成としてもよい。

端末21や携帯端末22の入出データは、Playgroundを介して、Application26とやり取りされる。Application26は、Playgroundおよび鍵生成局25と情報の入出力を行う。

鍵生成局25はブロックチェーンと別のサーバに保管されており、ユーザの共有台帳（ブロック）には記録されない。鍵生成局25は、信頼できる第三者であり、ユーザのID とともにユーザの秘密鍵，公開鍵および再暗号化鍵が保管されている。
なお、鍵生成局25は、耐改竄性、耐漏洩性等の信頼性が高い機密保護を行えれば、ソフトウェアとして分散データ管理システムS2のソフトウェアに組み込む構成としてもよい。

図15に、実施形態2の他例の分散データ管理システムS2Aの構成の模式図を示す。
実施形態2の他例の分散データ管理システムS2Aは、Localareaネットワーク上で稼動するシステムである。
分散データ管理システムS2Aは、パソコン等の端末21a、携帯端末22a、高機能血圧計23aや高機能ヘルスメータ24aがHyperledger Fabric（登録商標）のネットワーク20aで接続されている。

分散データ管理システムS2Aは、Hyperledger Fabric（登録商標）のネットワーク20aを使用し、ファイルをネットワーク20aに展開する。
パソコン等の端末21a、携帯端末22aには、分散データ管理システムS2Aのソフトウェアがインストールされている。なお、端末21a、携帯端末22aがネットワーク20aで接続されたサーバ（図示せず）に格納される分散データ管理システムS2Aのソフトウェアにアクセスする構成としてもよい。
Application26は、Hyperledger Fabric（登録商標）が提供するオープンソースをカスタマイズしたものである。

分散データ管理システムS2Aは、Hyperledger Fabric（登録商標）におけるComposerの機能であるREST-serverを使用する。REST-serverは、Hyperledger Fabric（登録商標）が提供する入出力インターフェースツールである。本構成の場合、Cardと称されるIDを用いて他のノードの端末21a、携帯端末22aからもアクセスやデータの共有が可能である。
なお、他例の分散データ管理システムS2Aでは、Hyperledger Fabric（登録商標）のPlaygroundやCLIといったコンポーネントも使用できる。

医師Aや解析者B、患者は、Cardと称されるIDを端末21a、携帯端末22aに入力することで、分散データ管理システムS2Aにアクセスできる。
端末21aや携帯端末22aには、実施形態１と同様なブロックチェーン4（図2参照）が格納されている。なお、前記した変形例（図11参照）に示すように、ブロックチェーン24のブロック24bにポインタp₁～p_mを格納し、デーダサーバ11にポインタp₁～p_mが示すデータd₁～d_mを格納する構成としてもよい。

端末21aや携帯端末22aの入出力データは、REST-serverを介して、Application26とやり取りされる。Application26は、鍵生成局25と情報の入出力を行う。

＜データ構造＞
図16に、分散データ管理システムS2、S2Aのデータ構造を示す。
実施形態2のモデルファイルに記述するデータは大きくParticipants とAssets の2 種類に分かれる。Participants にはユーザといったAssets を操作する主体の定義がなされている。Assetsには、例えば医療情報のようなモノの定義がなされている。

分散データ管理システムS2、S2Aのデータとして、下記がある。
クライアント側のデータとして、分散データ管理システムS2、S2Aにログインするユーザに、ID(25ａ)が付与される。各ID(25ａ)には、秘密鍵25b、公開鍵25c、再暗号化鍵25dが紐つけられている。

Participantsのデータとして、大きく分けて、人と役割がある。
人のデータとして、上記のID(25ａ)があり、名前25eと役割25fとが紐つけられている。なお、図16の(*) 印が書かれている要素はそのデータにおける識別子である。
役割のデータとして、医師25g、解析者25h、患者25iがある。

Assetsとして下記のデータが定義される。
暗号化するデータとして、日付け25j、プライバシーレベル25k、タイプ25l、説明25mがある。タイプ25lは、例えば血圧、体重等が挙げられる。説明25mには何が入力されて暗号化されたか記載される。

再暗号化鍵のデータとして、人のID(25ａ)とID(25ａ)の公開鍵からプライバシーレベル25kのl2の公開鍵への再暗号化鍵25nがある。また、プライバシーレベル25kのl2の公開鍵からID(25ａ)の公開鍵への再暗号化鍵25oがあり、ID(25ａ)からプライバシーレベル25kのl3への再暗号化鍵25pがある。また、プライバシーレベル25kのl3からID(25ａ)への再暗号化鍵25qがある。

プライバシーレベルのデータとして、プライバシーレベル1のl1(25r)、プライバシーレベル2のl2(25s)、プライバシーレベル3のl3(25t)がある。
図17に、実施形態2の分散データ管理システムS2、S2Aの機能の概要を示す。
分散データ管理システムS2、S2Aの機能は、上述の分散データ管理システムS2、S2Aのソフトウェアにより具現化される。

＜医師Aの情報d1の登録＞
医師A(25g1)が端末21等で情報d1を入力すると、情報d1は、Application26により数値情報d2に数値化される（図17のステップS401）。続いて、Application26は鍵生成局25から医師A(25g1)の公開鍵pk_Aを受け取る（ステップS402）。Application26は公開鍵pk_Aで数値情報d2を暗号化する（ステップS403）。

続いて、仮想的なサーバであるチェーンコード27が鍵生成局25から医師A(25g1)の公開鍵をプライバシーレベルl2の公開鍵に再暗号化する再暗号化鍵rk_A→_l2を受け取る（ステップS404）。チェーンコード27は、再暗号化鍵rk_A→_l2を用いて数値情報d2を再暗号化して再暗号化情報d3を生成する（ステップS405）。
次に、チェーンコード27によりブロックチェーン4のブロック4bが生成され、再暗号化情報d3は、当該ブロック4bにおけるプライバシーレベルl2に登録される（ステップS406）。

＜医師Bの再暗号化情報d3の参照＞
続いて、医師B(25g2)がブロック4bに格納される再暗号化情報d3を参照する処理を説明する。
まず、医師B(25g2)の端末21等での指示入力に従って、チェーンコード27がブロック4bに格納される再暗号化情報d3をリードする（図17のステップS501）。

続いて、チェーンコード27は鍵生成局25から、プライバシーレベルl2の公開鍵から医師B(25g2)の公開鍵に再暗号化する再暗号化鍵rk_l2→_Bを要求して受け取り（ステップS502）、再暗号化情報d3を再暗号化鍵rk_l2→_Bで再暗号化して再暗号化情報d4を生成する（ステップS503）。

続いて、Application26は、鍵生成局25から医師B(25g1)の秘密鍵sk_Bを受け取る（ステップS504）。Application26は、医師B(25g1)の秘密鍵sk_Bで再暗号化情報d4を復号化して復号化情報d5を生成し（ステップS505）、医師B(25g2)に出力する（ステップS506）。

＜解析者Cの再暗号化情報d3の参照＞
続いて、解析者C (25h)がブロック4bに格納される再暗号化情報d3を参照する処理を説明する。
解析者C (25h)の端末21等での指示入力に従って、チェーンコード27がブロック4bに格納される再暗号化情報d3をリードする（図17のステップS601）。

次に、チェーンコード27は、鍵生成局25に、プライバシーレベルl2の公開鍵から解析者C (25h)の公開鍵に再暗号化する再暗号化鍵rk_l2→_Cを要求するが、再暗号化鍵rk_l2→_Cはないため、再暗号化情報d3を再暗号化できない(ステップS602）。そのため、Application26は、鍵生成局25から受け取った解析者C (25h)の秘密鍵sk_Cで再暗号化情報d3は復号化できない(ステップS603）。従って、解析者C (25h)はプライバシーレベル2の再暗号化情報d3を参照できない。

＜トランザクション＞
次に、分散データ管理システムS2、S2Aのソフトウェアで行われるトランザクションを説明する。

＜ユーザ登録処理＞
ユーザ登録処理は以下のように行われる。
図18に、ユーザ登録処理のフロー図を示す。
Application26は、登録するユーザの鍵の作成を鍵生成局25に要求する(図18のステップS11)。

続いて、Application26は、登録するユーザをParticipantのPerson(図16参照)としてブロックチェーン上にユーザ登録を行う(ステップS12)。
続いて、Application26は、鍵生成局25から再暗号化鍵を取得しブロックチェーン上にAssetのReencKeyn(図16参照)として保存する(ステップS13)。なお、ユーザは、ユーザ登録時に鍵生成局25から予め秘密鍵、公開鍵を受け取る。

＜ユーザ削除処理＞
図19に、ユーザ削除処理のフロー図を示す。
ユーザ削除処理は、分散データ管理システムS2、S2Aの管理者のみが実行可能である。
ユーザ削除処理は以下のように行われる。

Application26は、図16に示すParticipantのPersonからユーザ情報を削除する(図19のステップS21)。
続いて、鍵生成局25が削除するユーザの鍵の情報を、削除する(ステップS22)。

＜情報登録処理＞
図20に、情報登録処理のフロー図を示す。
例えば、医療情報の登録処理は以下のように行われる。
ユーザが例えば端末21（図14参照）で情報登録を行うと入力すると、端末21の画面は医療情報の登録フォームに移動する(図20のステップS31)。
続いて、Application26は、図17に示すように、鍵生成局25から公開鍵を取得し登録情報を暗号化する (ステップS32)。

続いて、チェーンコード27は、暗号化した登録情報を取得し、ユーザの公開鍵からプライバシーレベルの公開鍵に再暗号化する再暗号化鍵で再暗号化する (ステップS33)。
続いて、チェーンコード27は、再暗号化した登録情報をブロックチェーン4に記録する。

＜復号化処理＞
図21に、復号化処理のフロー図を示す。
ブロックチェーン4のブロック4bに格納される登録情報の復号化処理は以下のように行われる。

図17に示すように、チェーンコード27は、ブロック4bに格納される登録情報を取得し、プライバシーレベル25kの公開鍵からユーザの公開鍵への再暗号化鍵で再暗号化を施す(図21のステップS41)。
そして、チェーンコード27は、再暗号化したデータをApplication26に送信する(ステップS42)。

Application26は、鍵生成局25からユーザの秘密鍵を取得し、再暗号化したデータを当該秘密鍵で復号化する(ステップS43)。
以上が、復号化処理である。

ここで、実施形態2においては、プライバシーレベル１の情報は、登録者が本人の公開鍵で暗号化してブロック4bに登録し、自身の秘密鍵でしか復号化できない構成とすることもできる。なお、実施形態1においても、プライバシーレベル１の情報は、登録者が本人の公開鍵で暗号化してブロック4bに登録し、自身の秘密鍵でしか復号化できない構成としてもよい。

なお、ハッシュ値の情報は、ユーザのIDで取得できるように制限をかけてもよい。例えば、図16に示す医師25g、患者25iのIDに対してのみ、ハッシュ値を取得できるように構成してもよい。

上記構成によれば、プロキシサーバをプロキシサーバ機能に代替し、分散データ管理システムS2、S2Aを構築できる。

＜＜その他の実施例＞＞
1．前記実施例では、分散データ管理システムSを医療情報の蓄積、参照に用いる場合を例示したが、他の分野に用いてもよい。

2．前記実施形態1、2、変形例、実施例は、本発明の一例を示したものであり、特許請求の範囲に記載した本発明の範囲内で様々な具体的形態、変形形態が可能である。

1a 登録・利用ノード（コンピュータ、ノード）
1b 蓄積ノード（コンピュータ、ノード）
1c、11c データ解析ノード（コンピュータ、参照ノード、ノード）
2、12 プロキシサーバ
3、13 認証局
4、14 ブロックチェーン
4b ブロック
10 Internet（ネットワーク）
H_j 現在のハッシュ値（ハッシュ値）
H_j+1 新しいハッシュ値（ハッシュ値）
l₁～l_m プライバシーレベル（アクセスレベル）
pk_l1 レベル1の公開鍵（最高のアクセスレベルの第１の鍵）
pk_l1～pk_lm プライバシーレベルの公開鍵（第１の鍵）
pk_u1-n 公開鍵（第２の鍵）
rk_lxay、rk_ux1y 再暗号化鍵
RK_ul、RK_lu マトリクス
S 分散データ管理システム
sk_az、sk_ux、sk_uy 秘密鍵（第４の鍵）

Claims (11)

1. 複数のブロックがつながれるブロックチェーンが格納されるコンピュータのノードと、プロキシサーバあるいは前記プロキシサーバの機能を持つ前記ノードとを備え、
   前記ブロックに格納される情報は、
   複数のアクセスレベルに分割され、かつアクセスレベルに応じた異なる第１の鍵によって暗号化されており、
   前記ノードがもつ第２の鍵で暗号化された情報を前記第１の鍵で暗号化された情報にする再暗号化鍵が前記プロキシサーバに格納されており、
   前記プロキシサーバは、前記ノードから送られる前記第２の鍵で暗号化された前記ノードの登録情報および前記登録情報のアクセスレベルおよび新しいハッシュ値の情報から、前記アクセスレベルの前記再暗号化鍵で前記ノードの前記登録情報を暗号化するとともに、前記新しいハッシュ値の情報を対応する前記再暗号化鍵で暗号化する
   ことを特徴とする分散データ管理システム。
2. 請求項１に記載の分散データ管理システムにおいて、
   前記再暗号化鍵は、前記第２の鍵の成分と、前記第１の鍵の成分とのマトリクスの形で前記プロキシサーバに格納され、
   前記暗号化鍵の前記マトリクスのx列目、y行目の要素RKlu[x,y]は、プライバシーレベルｘの公開鍵pklxから利用者ｙの公開鍵pkuyへの再暗号化鍵rklxuyに対応している
   ことを特徴とする分散データ管理システム。
3. 請求項１または請求項２に記載の分散データ管理システムにおいて、
   前記ブロックの情報は、ノードまたは参照ノードがもつアクセスレベルの第４の鍵で復号化される
   ことを特徴とする分散データ管理システム。
4. 請求項１から請求項３のうちの何れか一項に記載の分散データ管理システムにおいて、
   前記ブロックへの情報の登録に用いるハッシュ値の情報は、最高のアクセスレベルの前記第１の鍵によって暗号化されている
   ことを特徴とする分散データ管理システム。
5. 複数のアクセスレベルに分割され、かつアクセスレベルに応じた異なる第１の鍵によって暗号化されている情報が格納される複数のブロックがつながれる情報であるブロックチェーンと、
   前記ブロックチェーンに情報を登録する複数のノードと、
   前記ノードが前記ブロックに情報を登録する際に前記ノードに第２の鍵および第４の鍵を与える認証局と、
   前記第１の鍵と前記第２の鍵との間の再暗号化鍵の情報が格納され前記ブロックへの情報の登録の認証を行うプロキシサーバの機能とを備え、
   前記複数のノードと、前記プロキシサーバあるいは前記プロキシサーバの機能を持つ前記ノードと、前記認証局とはネットワークを介して接続されている
   ことを特徴とする分散データ管理システム。
6. 請求項５に記載の分散データ管理システムにおいて、
   前記ブロックチェーンへの前記ノードによる情報の登録に際して、
   前記認証局は、前記ノードに前記第２の鍵および第４の鍵を与え、
   前記ノードは、前記第２の鍵で暗号化したデータを前記プロキシサーバに送って認証要求を行い、ハッシュ値の情報を前記ブロックチェーンから取り出して暗号化して前記プロキシサーバに送り第１の認証を受け、前記ハッシュ値から新しいハッシュ値を計算し、暗号化した前記新しいハッシュ値の情報を前記プロキシサーバに送り第２の認証を受け、暗号化した前記新しいハッシュ値とともに情報を前記ブロックチェーンに登録し、
   前記プロキシサーバは、前記ノードによる前記ブロックチェーンへの情報の登録に際して、前記ノードからの前記第４の鍵で暗号化したデータの情報を受けて前記ノードの認証を行い、前記第１の認証と前記第２の認証とを前記第２の鍵の情報を用いて行う
   ことを特徴とする分散データ管理システム。
7. 第２の鍵および第４の鍵が与えられるノードとプロキシサーバあるいは前記プロキシサーバの機能を持つ前記ノードとを備え、複数のアクセスレベルに分割され、かつアクセスレベルに応じた異なる第１の鍵によって暗号化されている情報が格納される複数のブロックがつながれるブロックチェーンが格納されるとともに、前記第１の鍵と第２の鍵との間の再暗号化鍵の情報が格納される分散データ管理システムのプログラムであって、
   ノードが前記第４の鍵で暗号化したデータを前記プロキシサーバに送って認証要求が行われる第１のステップと、
   前記データを受けて前記第２の鍵で復号化して、前記プロキシサーバによって前記ノードの認証が行われる第２のステップと、
   前記ノードは、暗号化したハッシュ値の情報を前記プロキシサーバに送る第３ステップと、
   前記暗号化したハッシュ値の情報を受けて、前記プロキシサーバによって前記再暗号化鍵の情報を用いて情報の正当性の認証が行われる第４のステップと、
   前記ノードは、前記情報の正当性の認証許可情報を受け、暗号化した新しいハッシュ値とともに情報を前記ブロックチェーンに登録する第５のステップとを
   実行させるための分散データ管理システムのプログラム。
8. 請求項７に記載の分散データ管理システムのプログラムにおいて、
   前記第３ステップと前記第４のステップは、
   前記ノードが、ハッシュ値の情報を前記ブロックチェーンから取り出して暗号化して前記プロキシサーバに送るステップと、
   暗号化した前記ハッシュ値の情報を受けて、前記プロキシサーバが前記再暗号化鍵の情報を用いて第１の認証を行うステップと、
   前記ノードは、前記ハッシュ値から新しいハッシュ値を計算し、新しいハッシュ値の情報を暗号化して前記プロキシサーバに送るステップと、
   暗号化した前記新しいハッシュ値の情報を受けて、前記プロキシサーバが前記第２の鍵の情報を用いて第２の認証を行うステップとを有している
   ことを特徴とする分散データ管理システムのプログラム。
9. 請求項７または請求項８に記載の分散データ管理システムのプログラムにおいて、
   前記再暗号化鍵は、前記第１の鍵の成分と前記第２の鍵の成分とのマトリクスの形で格納され、
   前記暗号化鍵の前記マトリクスのx列目、y行目の要素RKlu[x,y]は、プライバシーレベルｘの公開鍵pklxから利用者ｙの公開鍵pkuyへの再暗号化鍵rklxuyに対応している
   ことを特徴とする分散データ管理システムのプログラム。
10. 請求項７から請求項９のうちの何れか一項に記載の分散データ管理システムのプログラムにおいて、
    前記ハッシュ値の情報は、最高のアクセスレベルの前記第１の鍵によって暗号化されている
    ことを特徴とする分散データ管理システムのプログラム。
11. 請求項７から請求項１０のうちの何れか一項に記載の分散データ管理システムのプログラムにおいて、
    前記分散データ管理システムは、さらにデータ参照ノードを備え、
    前記ノードまたは前記データ参照ノードが、自身が有するアクセスレベルの第４の鍵を用いて前記ブロックに格納される情報を復号化するステップを
    実行させるための分散データ管理システムのプログラム。

Images