JP6830635B1 - データ管理方法 - Google Patents

Abstract

【課題】秘密性の高いデータを安全に管理することができるようにする。【解決手段】データ管理方法であって、分散台帳により管理しようとするデータの内容を、トラステッド実行環境を備えるトラステッドサーバに記録し、分散台帳には、データを暗号化した暗号データを記録し、トラステッドサーバでデータの内容が更新された場合には、更新された内容を暗号化した暗号データを分散台帳に追加し、分散台帳に暗号データが追加された場合には、トラステッドサーバは、追加された暗号データを復号化してデータの内容を更新すること、を特徴とする。【選択図】図４

Description

本発明は、データ管理方法に関する。

特許文献１では、ブロックチェーンに暗号化したデータを記録し、暗号化したまま演算可能な秘密計算方式を採用している。

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

しかしながら、特許文献１に記載の技術では特殊な計算方式しか用いることができず、一般的な処理を行うことができない。

本発明はこのような背景を鑑みてなされたものであり、秘密性の高いデータを安全に管理することのできる技術を提供することを目的とする。

上記課題を解決するための本発明の主たる発明は、データ管理方法であって、分散台帳により管理しようとするデータの内容を、トラステッド実行環境を備えるトラステッドサーバに記録し、前記分散台帳には、前記データを暗号化した暗号データを記録し、前記トラステッドサーバで前記データの内容が更新された場合には、前記更新された内容を暗号化した前記暗号データを前記分散台帳に追加し、前記分散台帳に前記暗号データが追加された場合には、前記トラステッドサーバは、追加された前記暗号データを復号化して前記データの内容を更新すること、を特徴とする。

その他本願が開示する課題やその解決方法については、発明の実施形態の欄及び図面により明らかにされる。

本発明によれば、秘密性の高いデータを安全に管理することができる。

一般的なコンピュータの構成を説明する図である。 トラステッド実行環境（ＴＥＥ；Trusted Execution Environment）を説明する図である。 ＴＥＥにより対策可能な脅威を説明する図である。 本発明の一実施形態に係るデータ管理システムの全体構成例を示す図である。 ユーザ端末１、ＴＥＥサーバ２及びＢＣノード３を実現するコンピュータのハードウェア構成例を示す図である。 本実施形態のデータ管理システムにおけるデータ管理の概要を説明する図である。 ユーザからのデータアクセスを説明する図である。 本実施形態のデータ管理システムにおけるデータ管理に係るサブプロトコルを説明する図である。 アテステーションサービスについて説明する図である。 アテステーションサービスから応答されるＲＥＰＯＲＴ構造体の主要項目を示す図である。 ＲＥＰＯＲＴの検証処理を説明する図である。 ＴＥＥサーバ２を追加するときの動作を説明する図である。 ＴＥＥサーバ２を追加する処理の流れを示す図である。 ＴｒｅｅＫＥＭ形式のグループステートを説明する図である。 グループステートに含まれるアプリケーションキーチェーンの構成例を示す図である。 図１２の動作におけるハンドシェイクの詳細を説明する図である。 書き込みの衝突を説明する図である。 書き込み競合時のブロックチェーンネットワーク３０におけるブロック高を説明する図である。 書き込み衝突判定について説明する図である。 衝突検証を行う場合の秘密情報の状態遷移について説明する図である。 エンクレーブ２１における状態遷移の改ざん検出のための仕組みを説明する図である。

＜発明の概要＞
本発明の実施形態の内容を列記して説明する。本発明は、たとえば、以下のような構成を備える。
［項目１］
分散台帳により管理しようとするデータの内容を、トラステッド実行環境を備えるトラステッドサーバに記録し、
前記分散台帳には、前記データを暗号化した暗号データを記録し、
前記トラステッドサーバで前記データの内容が更新された場合には、前記更新された内容を暗号化した前記暗号データを前記分散台帳に追加し、
前記分散台帳に前記暗号データが追加された場合には、前記トラステッドサーバは、追加された前記暗号データを復号化して前記データの内容を更新すること、
を特徴とするデータ管理方法。
［項目２］
項目１に記載のデータ管理方法であって、
ユーザ端末は、前記トラステッドサーバに対して前記データの更新リクエストを送信し、
前記トラステッドサーバは、前記更新された内容を暗号化した前記暗号データを、対応する前記分散台帳を構成するノードに送信し、
前記ノードは、前記暗号データを前記分散台帳に追加して、他の前記ノードに伝搬させ、
前記ノードのそれぞれは、追加された前記暗号データを、対応する前記トラステッドサーバに送信し、
前記トラステッドサーバは、追加された前記暗号データを復号化して、自身が記録している前記データの内容を更新すること、
を特徴とするデータ管理方法。
［項目３］
項目１に記載のデータ管理方法であって、
前記トラステッドサーバが作成した秘密鍵による署名を含むデータをアテステーションサービスに送信して正当性を検証させ、前記アテステーションサービスは検証結果に署名し、前記トラステッドサーバは、前記検証結果に、前記トラステッドサーバが作成した公開鍵を含めて前記分散台帳に登録し、前記ノードが、前記検証結果の署名を検証し、
前記トラステッドサーバは、前記分散台帳におけるトランザクションの発生時には、登録されている前記公開鍵を用いて前記トランザクションに含まれる署名の検証を行うこと、
を特徴とするデータ管理方法。
［項目４］
項目３に記載のデータ管理方法であって、
前記検証結果には、前記トラステッドサーバが実行しているプログラムを特定する情報が含まれ、
前記トラステッドサーバは、前記検証結果の署名検証時に、自身が実行している前記プログラムが、前記検証結果に含まれている情報が示す前記プログラムと一致することを検証すること、
を特徴とするデータ管理方法。
［項目５］
項目４に記載のデータ管理方法であって、
前記ノードにおいてもさらに、前記検証結果に含まれている情報が示す前記プログラムと前記分散台帳に登録されている前記検証結果に含まれている情報が示す前記プログラムとが一致していることを検証すること、
を特徴とするデータ管理方法。
［項目６］
項目３に記載のデータ管理方法であって、
前記トラステッドサーバでは、前記秘密鍵及び前記公開鍵のペアを生成し、前記公開鍵を前記検証結果に含めて前記分散台帳に登録すること、
を特徴とするデータ管理方法。
［項目７］
項目３に記載のデータ管理方法であって、
前記トラステッドサーバを追加する場合に、
追加される前記トラステッドサーバは、
前記アテステーションサービスに自身の前記トラステッド実行環境の正当性を検証させ、
前記アテステーションサービスによる検証結果を、既存の前記トラステッドサーバに送信し、
前記既存のトラステッドサーバは、
前記アテステーションサービスに自身の前記トラステッド実行環境の正当性を検証させ、
前記アテステーションサービスによる検証結果と、前記追加されるトラステッドサーバから受信した前記検証結果とを照合して、前記追加されるトラステッドサーバの参加可否を決定し、
前記追加されるトラステッドサーバの参加が可能と判断した場合には、前記追加されるトラステッドサーバから受信した前記検証結果とを照合して、前記追加されるトラステッドサーバの参加を決定すること、
を特徴とするデータ管理方法。
［項目８］
項目１に記載のデータ管理方法であって、
前記暗号化は共通のグループ鍵を用いて行われ、
前記トラステッドサーバはそれぞれ自身の秘密鍵を有しており、全ての前記トラステッドサーバの公開鍵が前記分散台帳に記録されており、
前記トラステッドサーバは、同一の前記グループ鍵を算出するように、全ての前記公開鍵と、自身の前記秘密鍵とを用いてシードを計算し、前記シードに基づいてグループ鍵を計算すること、
を特徴とするデータ管理方法。
［項目９］
項目１に記載のデータ管理方法であって、
前記トラステッドサーバは、前記分散台帳で管理されるブロックごとの全てのデータの第１のハッシュ値を計算して、前記第１のハッシュ値を前記分散台帳に記録し、前記データの内容が更新された場合には、更新前の前記ハッシュ値と更新後の全前記ブロックの内容との第２のハッシュ値を計算して、前記第２のハッシュ値を前記分散台帳に記録すること、
を特徴とするデータ管理方法。

＜本実施形態の概要＞
以下、図面を用いて本発明の一実施形態に係るデータ管理システムについて説明する。本実施形態のデータ管理システムは、秘密性の高いデータ（例えば個人情報など）を管理する場合に、より安全にデータを管理可能とするものである。本実施形態のデータ管理システムでは、ブロックチェーンにデータを管理することでデータの改ざんを防止し、ブロックチェーンには暗号化したデータを管理することでデータの秘匿性あるいは匿名性を担保し、暗号化されたデータを復号化して処理する環境として、トラステッド実行環境（ＴＥＥ；Trusted Execution Environment）を採用することで、秘匿性及び安全性を向上させている。

図１は、一般的なコンピュータの構成を説明する図である。一般的なコンピュータでは、オペレーティングのカーネルがプログラムのコードやデータを、プロセス生成時や生成後動的にメモリに割り当て、ユーザアプリケーションはメモリの断片化や別用途メモリへのアクセスを防ぐために仮想アドレス空間を利用している。オペレーティングシステムは、カーネルメモリのページテーブルでマッピングメモリを元にＣＰＵで演算し、メモリから命令を読み出し、命令をもとにメモリからレジスタにデータを読みだし、レジスタ上のデータを元に演算を行い、演算結果をメモリに書き戻している。なお、キャッシュメモリなどがその中間に存在することもある。

図２は、トラステッド実行環境（ＴＥＥ；Trusted Execution Environment）を説明する図である。ＴＥＥとは、セキュアハードウェアの一種である。ＴＥＥは、例えば、メモリ上にエンクレーブ（Enclave）と呼ばれる暗号的に厳重に保護された領域を生成することで、秘密性の高いデータを保護しつつプログラムを実行する為のＣＰＵの拡張機能である。図２（ａ）に示されるように、ＴＥＥにおいて、エンクレーブを実現するプログラム及びデータは、ＤＲＡＭのサブセットであるＰＲＭ（Processor Reserved Memory）に保管される。ＰＲＭは、他のソフトウェアから直接アクセスできない領域となっている。さらに、エンクレーブの内容は、ＰＲＭのサブセットであるＥＰＣ（Enclave Page Cache）に記録される。すなわち、ＤＲＡＭ上のＥＰＣが実際の保護領域である。ＣＰＵがエンクレーブ外からのソフトウェア（オペレーティングシステムなどのシステムソフトウェアを含む全てのソフトウェア）からのアクセスを制限する。ＥＰＣ内のメモリは暗号化されており、ＣＰＵが復号化して演算することができる。ＥＰＣへのダイレクトメモリアクセスについてもＣＰＵが制御する。

図２（ｂ）に示されるように、それぞれのエンクレーブには、ＥＬＲＡＮＧＥ（Enclave Linear Address Range）と呼ばれる仮想アドレス空間が指定される。ＥＬＲＡＮＧＥはＥＰＣ領域にマッピングされる。一方で、仮想アドレスの割り当ては（ＴＥＥでは信頼していない）カーネルの役割である。エンクレーブの初期化フェーズ前に全てのＥＰＣは静的に割り当てられる。エンクレーブには、ページテーブルが含められる。

図３は、ＴＥＥにより対策可能な脅威を説明する図である。ＴＥＥは、マルウェアなどを用いた機密情報（秘密鍵、パスワードなどを含む。）の流出を防ぐことができるものである。また、ＴＥＥでは、オペレーティングシステムも信頼されておらず、ＣＰＵ及びエンクレーブ内のコードのみが信頼されている。攻撃として、メモリ破壊（不正なメモリ書き換え、操作など）、システムソフトウェアからの攻撃（信頼されていないオペレーティングシステム）、コールブート攻撃（強制的な揮発遅延によるメモリの読み取りなど）への対策がなされている。なお、当該図の説明は、 「Graphene-SGX: A Practical Library OS for Unmodified Applications on SGX」, Chia-Che Tsai, Donald E. Porter, Mona Vij. USENIX: https://www.usenix.org/system/files/conference/atc17/atc17-tsai.pdf にて説明されている。

本実施形態では、秘密性の高い管理対象のデータ（以下、秘密情報という。）をＴＥＥのエンクレーブに格納し、ユーザはＴＥＥサーバに対して秘密情報の読み書きを行う。その一方で、秘密情報を暗号化したデータ（以下、暗号化情報という。）はブロックチェーンに登録し、秘密情報への読み書き等のオペレーションを、ブロックチェーン上でのトランザクションとして発生させるようにして、秘密情報と暗号化情報との同期をとっている。これにより、ブロックチェーンによる改ざん困難性と、ＴＥＥによる秘密性とを組み合わせることが可能となる。

＜システム概要＞
図４は、本発明の一実施形態に係るデータ管理システムの全体構成例を示す図である。本実施形態のデータ管理システムは、ＴＥＥサーバ２及びブロックチェーンネットワーク３を含んで構成される。ブロックチェーンネットワーク３０は、複数のブロックチェーンノード（ＢＣノード３）により構成される。本実施形態では、ＢＣノード３には対応するＴＥＥサーバ２がそれぞれ設けられる。なお、ＢＣノード３とＴＥＥサーバ２とは１対１のペアとして構成してもよいし、１つのＢＣノード３に複数のＴＥＥサーバ２が対応し、及び／又は、複数のＢＣノード３に１つ若しくは複数のＴＥＥサーバ２が対応していてもよい。また、本実施形態では、ＴＥＥサーバ２は１つのツリーを構成するものとする。

ＴＥＥサーバ２は、ＴＥＥを備えるコンピュータである。ＴＥＥサーバ２は、ユーザ端末１からのリクエストに応じて秘密情報を管理する。ＢＣノード３は、上述したようにブロックチェーンネットワーク３０を構成する。ＢＣノード３には、暗号化情報が分散台帳に登録される。

図５は、ユーザ端末１、ＴＥＥサーバ２及びＢＣノード３を実現するコンピュータのハードウェア構成例を示す図である。ユーザ端末１、ＴＥＥサーバ２及びＢＣノード３は、例えばワークステーションやパーソナルコンピュータのような汎用コンピュータとしてもよいし、あるいはクラウド・コンピューティングによって論理的に実現されてもよい。コンピュータは、ＣＰＵ０１、メモリ１０２、記憶装置１０３、通信インタフェース１０４、入力装置１０５、出力装置１０６を備える。記憶装置１０３は、各種のデータやプログラムを記憶する、例えばハードディスクドライブやソリッドステートドライブ、フラッシュメモリなどである。通信インタフェース１０４は、通信ネットワークに接続するためのインタフェースであり、例えばイーサネット（登録商標）に接続するためのアダプタ、公衆電話回線網に接続するためのモデム、無線通信を行うための無線通信機、シリアル通信のためのＵＳＢ（Universal Serial Bus）コネクタやＲＳ２３２Ｃコネクタなどである。入力装置１０５は、データを入力する、例えばキーボードやマウス、タッチパネル、ボタン、マイクロフォンなどである。出力装置１０６は、データを出力する、例えばディスプレイやプリンタ、スピーカなどである。

＜データ管理の概要＞
図６は、本実施形態のデータ管理システムにおけるデータ管理の概要を説明する図である。本実施形態のデータ管理システムでは、ＴＥＥサーバ２は秘密情報を平文で記録するとともに、ブロックチェーンネットワーク３０により共有される場合に、そのデータの秘匿性を保護するために秘密情報の暗号化を行う。すなわち、ＴＥＥ保護領域内部でのみ機密性の高いデータを扱うようにし、ブロックチェーンネットワーク３０上には暗号化したデータ（暗号文）のみを記録するようにする。ＴＥＥサーバ２は、外部からデータを見ることができない保護領域を持つコンピュータである。ＴＥＥは、保護領域内部のデータが外部から勝手に見れないことを保証しているため、秘密情報の秘匿性を担保することができる。また、ＴＥＥでは、後述するアテステーションサービスにより正しいプログラムが動作していることが保証されるようにすることができるので、計算完全性を担保することができる。

図７は、ユーザからのデータアクセスを説明する図である。本実施形態のデータ管理システムでは、秘匿性あるいは匿名性を保証するためにブロックチェーンネットワーク３０上にはそれぞれの状態の暗号文をアカウントに紐づかない形式で保持する。オンチェーン（ブロックチェーンネットワーク３０で管理される分散台帳）には匿名性が保証されるように非構造化データ（暗号文）が管理され、オフチェーン（ブロックチェーンで管理されない場所、すなわち、ＴＥＥサーバ２）では、状態遷移できるように構造化データ（平文の秘密情報）が管理される。復号化された秘密情報は、オフチェーンのエンクレーブ２１内のみに一時的に存在することになる。したがって、ユーザから自由にアクセスできない保護領域に復号化された秘密情報を管理することができる。また、本実施形態のデータ管理システムでは、ユーザ端末１からのリクエストに応じて、ＴＥＥサーバ２がエンクレーブ２１内で秘密情報の状態を遷移させ、その結果を暗号化してブロックチェーンネットワーク３０にブロードキャストすることができる。そして、他のＴＥＥサーバ２は暗号文をブロックチェーンネットワーク３０から読み取り、エンクレーブ２１内で復号化することで、エンクレーブ２１内の秘密情報を更新することができる。暗号化情報は、ブロックチェーンネットワーク３０内では復号化することができず、エンクレーブ２１内でのみ復号化することができる。後述するオンチェーンでのＲＥＰＯＲＴ検証によりＴＥＥサーバ２の計算完全性を検証することができる。ＲＥＰＯＲＴ検証は、ＴＥＥサーバ２が意図されたプログラムを動かしているか否かを検証する。ユーザ端末１が秘密情報の状態を取得したい場合はＴＥＥサーバ２から得ることができる。

本実施形態のデータ管理システムが有する性質には次の５つがある。
（１）データ有用性：ブロックチェーンネットワーク３０に管理されているデータから全ての秘密情報を復元可能である。
（２）ブロックチェーン対応性：既存の様々なブロックチェーン上で動作する。
（３）非同期：それぞれのＴＥＥサーバ２は非同期に動作する。
（４）機密性：ブロックチェーンには暗号化データが管理される。
（５）正しい実行：コンフリクトなく実行される。

図８は、本実施形態のデータ管理システムにおけるデータ管理に係るサブプロトコルを説明する図である。

ユーザ端末１とＴＥＥサーバ２との間ではチャレンジレスポンス認証が行われる（Ｓ８０１）。これは、ユーザ鍵ペアでアクセス可能なデータ管理である。次に、エンクレーブ２１内では、ＣＧＫＡ安全なグループ暗号化が行われる（Ｓ８０２）。すなわち、特定の暗号文解読（秘密鍵漏洩）が他の暗号文に影響を与えないことを意味する。ＴＥＥサーバ２のシミュレーション攻撃を防ぐトランザクション署名方式を採用する（Ｓ８０３）。これは、ＴＥＥサーバ２が正しい処理をしていることを署名だけで検証することを意味する。書き込み競合のロック方式を採用する（Ｓ８０４）。すなわち、データ競合対策である。ブロック高ごとのエンクレーブ２１内の状態ハッシュ値の一致検証を行う（Ｓ８０５）。これにより全てのＴＥＥサーバ２が同じ内部状態を持っていることを保証することができる。

＜アテステーションサービス＞
図９は、アテステーションサービスについて説明する図である。サービスプロバイダー（ＳＰ；Service Provider）はエンクレーブ２１を備えていないコンピュータであり、独立ソフトウェアベンダー（ＩＳＶ；Independent Software Vendor）は、エンクレーブ２１を備えているコンピュータである。ＳＰが正当なエンクレーブ２１であることをアテステーションサービス４が認証する。特定のメーカーが製造したＣＰＵであるかどうか、脆弱性はないか、ＭＲＥＮＣＬＡＶＥの比較（実行プログラムの比較）などを認証する。アテステーションサービス４は、例えば、オープンソースのＤＣＡＰなどにより実装される。エンクレーブ２１が生成するＱＵＯＴＥをアテステーションサービス４に送信し、アテステーションサービス４の秘密鍵で署名されたＲＥＰＯＲＴが応答される。ＱＵＯＴＥには、ＭＲＥＮＣＬＡＶＥ（エンクレーブ計測値、ハッシュ値）が含まれる。ＩＳＶは、ＣＰＵ内の秘密鍵でＱＵＯＴＥを署名する。当該秘密鍵は、ＣＰＵのチップ製造時に設定される固有の鍵であり、いわゆるＲｏｏｔ ｏｆ Ｔｒｕｓｔとして機能する。アテステーションサービス４は、対応する公開鍵で署名検証する。これにより、正当なトラステッド実行環境から送られてきたＱＵＯＴＥであることを保証することができる。アテステーションサービス４は、秘密鍵で署名されたＲＥＰＯＲＴを応答する。ＲＥＰＯＲＴには、ＭＲＥＮＣＬＡＶＥが含まれる。アテステーションサービス４は、Ｘ．５０９証明書で認証することができる。

図１０は、アテステーションサービスから応答されるＲＥＰＯＲＴ構造体の主要項目を示す図である。ｉｄは、ユニークな識別子であり、ｔｉｍｅｓｔａｍｐは、ＲＥＰＯＲＴ生成時のタイムスタンプである。ｖｅｒｓｉｏｎは、ＡＰＩバージョンであり、ｉｓｖＥｎｃｌａｖｅＱｕｏｔｅＳｔａｔｕｓは、ＥＰＩＤ署名に対するステータスである。ＣＰＵＣＶＮは、ＣＰＵのセキュリティバージョンであり、ＭＩＳＣＳＥＫＥＣＴは、Ｅｎｃｌａｖｅ内での例外発生時のプロセッサ状態であり、ＡＴＴＲＩＢＵＴＥＳは、エンクレーブ２１の属性フラグである。ＭＲＥＮＣＬＡＶＥは、エンクレーブ計測値である。ＭＲＳＩＧＮＥＲは、エンクレーブ署名鍵のＲＳＡ公開鍵ｍｏｄｕｌｕｓのハッシュ値である。ＩＳＶＰＲＯＤＩＤは、エンクレーブのプロダクトＩＤであり、ＩＳＶＳＶＮは、エンクレーブのセキュリティバージョンである。ＲＥＰＯＲＴＤＡＴＡは、レポートデータである。

＜ＲＥＰＯＲＴ検証＞
図１１は、ＲＥＰＯＲＴの検証処理を説明する図である。ＲＥＰＯＲＴの検証処理は、ＴＥＥサーバ２が全て同じプログラムを実行していることをオンチェーンで合意しようとするものである。各ＴＥＥサーバ２は、アテステーションサービス４にＱＵＯＴＥを送信して、正当なトラステッド実行環境であるか否かの検証を受ける。アテステーションサービス４からは、ＲＥＰＯＲＴが応答される。アテステーションサービス４では、上述したように、ＣＰＵの固有秘密鍵による署名の検証、セキュリティバージョンのチェックなどが行われる。ＲＥＰＯＲＴはＭＲＥＮＣＬＡＶＥを含み、Ｘ．５０９証明書で認証される。

ＴＥＥサーバ２は、スマートコントラクトを用いて、デプロイ時にオンチェーンで、ＲＥＰＯＲＴの署名検証、ＭＲＥＮＣＬＡＶＥの登録、ならびに、公開鍵及びエンドポイントなどのパラメタ登録を行う。ＴＥＥサーバ２は、ＲＥＰＯＲＴ内のＲＥＰＯＲＴＤＡＴＡ項目にエンクレーブ２１内で生成した公開鍵（ＲＡＫ）とノンスとを設定する。ＴＥＥサーバ２は、公開鍵はオンチェーンに登録する。ブロックチェーンネットワーク３０において、通常のトランザクションでは、著名公開鍵が登録されているか否かを検証し、その公開鍵による署名検証を行うことができる。したがって、エンクレーブ２１のプログラムコードを変更すると、メモリ上の署名秘密鍵も失われ、署名検証を行うことができなくなる。したがって、ＲＥＰＯＲＴを検証することで、エンクレーブ２１で実行しているプログラムの真正性（他のＴＥＥサーバ２のエンクレーブ２１と同じプログラムを実行していること）を保証することができる。ノンスは、ＲＥＰＯＲＴのリプレイ攻撃を防ぐために設定することが出来る。

ＴＥＥサーバ２は、最初の参加時と定期的なリフレッシュ時にのみＲＥＰＯＲＴ検証を行うものとする。これにより、トランザクションごとにアテンションサービス４との通信を行う必要がなくなる。

＜ネットワークへの参加＞
図１２は、ＴＥＥサーバ２を追加するときの動作を説明する図である。図１２の例では、ＴＥＥサーバ２（２）が新規に追加され、ＴＥＥサーバ２（１）が既存である。

新規のＴＥＥサーバ２（２）からアテステーションサービス４に署名済みＱＵＯＴＥ構造体データを送信する（Ｓ１２１）。アテステーションサービス４からは、ＲＥＰＯＲＴ構造体データが応答される（Ｓ１２２）。新規のＴＥＥサーバ２（２）から既存のＴＥＥサーバ２（１）に対してｉｎｉｔｋｅｙを送信する（Ｓ１２３）。ｉｎｉｔｋｅｙの公開鍵がグループステートとして登録されることになる。ＴＥＥサーバ２（１）及びＴＥＥサーバ２（２）は互いにＲＥＰＯＲＴの検証を行う。すなわち、新規のＴＥＥサーバ２（２）と既存のＴＥＥサーバ２（１）との間でＲＥＰＯＲＴ構造体データを共有し、ＲＥＰＯＲＴの署名、タイムスタンプ、ステータスなどを検証するとともに、お互いのＭＲＥＮＣＬＡＶＥが一致するか否かを検証する。

次に、既存のＴＥＥサーバ２（１）から新規のＴＥＥサーバ２（２）に対してグループステートを送信する（Ｓ１２４）。グループステートは、後述するＴｒｅｅＫＥＭ形式である。新規のＴＥＥサーバ２（２）は、秘密鍵（ｄｈｓｅｃｒｅｔ）を追加して、グループステートから暗号化に用いるグループ鍵を抽出する。また、新規のＴＥＥサーバ２（２）は、グループステートから追加（Add）のハンドシェイクを作成し、ハンドシェイクと、署名マッピングとをブロックチェーンネットワーク３０に送信する（Ｓ１２５）。また、新規のＴＥＥサーバ２（２）は、スマートコントラクトにより、ＲＥＰＯＲＴと、指定のパラメータ（ＴＥＥ名称、ＵＲＬ、タイムスタンプなど）をブロックチェーンネットワーク３０に送信することができる。ブロックチェーンネットワーク３０では、ＲＥＰＯＲＴの検証、ＭＲＥＮＣＬＡＶＥの一致検証、ＲＥＰＯＲＴＤＡＴＡ内のノンス検証、ＲＥＰＯＲＴＤＡＴＡ内の公開鍵登録、タイムスタンプ登録などを行うことができる。

図１３は、ＴＥＥサーバ２を追加する処理の流れを示す図である。

ユーザ端末１からシグネチャが新規のＴＥＥサーバ２に送信され（Ｓ１３０１）、ＴＥＥサーバ２ではシグネチャの検証が行われる（Ｓ１３０２）。新規のＴＥＥサーバ２は、ＱＵＯＴＥをアテステーションサービス４に送信し（Ｓ１３０３）、アテステーションサービス４からＲＥＰＯＲＴが応答される（Ｓ１３０４）。新規のＴＥＥサーバ２から既存のＴＥＥサーバ２にｉｎｉｔｋｅｙが送信され（Ｓ１３０５）、既存のＴＥＥサーバ２からｗｅｌｃｏｍが応答される（Ｓ１３０６）。

新規のＴＥＥサーバ２は、ＲＥＰＯＲＴ、公開鍵、ノンス、追加のハンドシェイクをブロックチェーンネットワーク３０にブロードキャストする（Ｓ１３０７）。ブロックチェーンネットワーク３０では、ＭＲＥＮＣＬＡＶＥの検証（Ｓ１３０８）、ＲＥＰＯＲＴの署名の検証（Ｓ１３０９）、ノンスの検証（Ｓ１３１０）、公開鍵の検証（Ｓ１３１１）、ＲＥＰＯＲＴの日時の検証（Ｓ１３１２）が行われ、追加のハンドシェイクが実行される（Ｓ１３１３）。

ブロックチェーンネットワーク３０から既存のＴＥＥサーバ２にハンドシェイクが応答され（Ｓ１３１４）、既存のＴＥＥサーバ２はグループステートを更新する（Ｓ１３１５）。ブロックチェーンネットワーク３０からは新規のＴＥＥサーバ２にもハンドシェイクが応答され（Ｓ１３１６）、新規のＴＥＥサーバ２もグループステートを更新する（Ｓ１３１７）。

以上のようにして、新規のＴＥＥサーバ２がネットワークに登録される。

＜ＴｒｅｅＫＥＭ形式＞
図１４は、ＴｒｅｅＫＥＭ形式のグループステートを説明する図である。ＴｒｅｅＫＥＭ（木構造の鍵カプセル化手法；Key Encapsulation Method）の詳細については、ＭＬＳ（Messaging Layer Security）プロトコルのＲＦＣ標準のドラフト（https://tools.ietf.org/html/draft-ietf-mls-protocol-08）を参照する。ここで、配送サーバ（Delivering Server）のＯｒｄｅｒｉｎｇをブロックチェーンネットワーク３０が行うものとする。また、ハンドシェイク及びアプリケーションメッセージの順序はグローバルに共通であるものとする。ＴＥＥサーバ２のネットワーク全体で共有されるマスターシードの存在を消去する。ＴＥＥサーバ２ごとに自由に鍵の変更が可能であるため、情報漏洩後の対応（ＰＣＳ；Post-Compromise Security）が可能である。また、マスターを削除することもできる。

木構造のリーフは、各メンバーのｉｎｉｔｋｅｙから生成されるノード（公開鍵ＤＨＰｕｂＫｅｙ）である。該当するメンバーのみがリーフとその直接パスで接続されたメンバーの秘密鍵ＤＨＳｅｃｒｅｔを知っている。

図１４の例において、ルートＫは、全てのメンバーが知っている。ＫＤＦ（Key Derivation Function）チェーンのグループキーとして利用することができる。生成（Create）、追加（Add)、更新（Update）、削除（Remove）のハンドシェイク操作でＴｒｅｅＫＥＭは変化する。エポック（Epoch）が変化して、情報漏洩後の対策（ＰＣＳ）となる。オンチェーンでは、エポック、署名者のインデックスに対応付けた公開鍵（ｓｉｇｎｅｒ＿ｉｎｄｅｘ＝＞ｉｄｅｎｔｉｔｙＰｕｂｋｅｙ）を保持する。これにより、操作が更新である場合、ｓｉｇｎｅｒ＿ｉｎｄｅｘが存在するかどうかを判定し、操作が追加及び削除である場合には、ｓｉｇｎｅｒ＿ｉｎｄｅｘが存在しないかどうかを判定することができる。ｉｄｅｎｔｉｔｙＰｕｂｋｅｙによりハンドシェイクの署名を検証することができる。ハンドシェイク時には前回のインデックス（ｐｒｉｏｒ＿ｉｎｄｅｘ）が一致するかどうかを検証することができる。また、ハンドシェイクごとにエポックはインクリメントされる。ＴＥＥサーバ２は、受信したハンドシェイクの中のＨＭＡＣを検証することができる。

図１５は、グループステートに含まれるアプリケーションキーチェーンの構成例を示す図である。このアプリケーションキーチェーンは、前方秘匿性（Forward Secrecy）の要である。本実施形態のデータ管理システムでは、ＴＥＥサーバ２ごとにアプリケーションチェーンを回していく。署名された公開鍵で識別することができる。グループキーからメンバーインデックス（ｒｏｓｔｅｒ ｉｄｘ）ごとに、ＫＤＦチェーンを用いることにより、前方秘匿性を得ながらメッセージの暗号化に用いる鍵を生成することができる。受け取ったメッセージの復号化にラチェット（ratchet）を用いることができる。なお、ＭＬＳでは暗号化にもラチェットが用いられている。各ユーザごとの生成（generation）をエンクレーブ２１内に保持する。ブロックチェーンネットワーク３０がこの生成とエポックの変化とをグローバルに順序づけするために、全てのＴＥＥサーバ２で共通の暗号化情報に対して共通の鍵を利用することができる。

図１６は、図１２の動作におけるハンドシェイクの詳細を説明する図である。新規のＴＥＥサーバ２（２）がステップＳ１２４で受け取ったｗｅｌｃｏｍから生成するグループステートには自身のノードにのみ秘密鍵ＤＨＳｅｃｒｅｔＫｅｙが含まれる。そして、自身のノードから直接パスで接続されているノードの鍵が分かる。秘密鍵は自身しか知らない。新規ＴＥＥサーバ２（２）のリーフインデックスは、既存のメンバーであるＴＥＥサーバ２（１）が決定する。ステップＳ１２５で、新規ＴＥＥサーバ２（２）のｉｎｉｔｋｅｙがブロックチェーンネットワーク３０に記録されるが、秘密鍵ＤＨＳｅｃｒｅｔＫｅｙは含まれない。ブロックチェーンネットワーク３０が、新規ＴＥＥサーバ２（２）のメンバーインデックス（ｒｏｓｔｅｒ ｉｎｄｅｘ）を決定し、ハンドシェイクの応答ステップＳ１２６で、ＴｒｅｅＫＥＭのメンバーインデックス（ｒｏｓｔｅｒ ｉｎｄｅｘ）に公開鍵ＤＨＰｕｂＫｅｙを追加し、新しいグループルートを決定する。

ｉｎｉｔｋｅｙには、ｕｓｅｒ＿ｉｎｉｔ＿ｋｅｙ＿ｉｄ、ｓｕｐｐｏｒｔｅｄ＿ｖｅｒｓｉｏｎ、ｃｉｐｈｅｒ＿ｓｕｉｔｅｓ、ｄｈｐｕｂｋｅｙ、ｃｒｅｄｅｎｔｉａｌ、ｓｉｇｎａｔｕｒｅが含まれる。

ｗｅｌｃｏｍｅ（グループステート）には、ｕｓｅｒ＿ｉｎｉｔ＿ｋｅｙ＿ｉｄ、ｃｉｐｅｈｒ＿ｓｕｉｔｅ、ｅｎｃｒｙｐｔｅｄ＿ｇｒｏｕｐ＿ｓｔａｔｅが含まれる。

追加（Add）のハンドシェイクには、ｐｒｉｏｒ＿ｅｐｏｃｈ、ＧｒｏｕｐＡｄｄ、ｓｉｇｎｅｒ＿ｉｎｄｅｘ、ｓｉｇｎａｔｕｒｅ、ｃｏｎｆ＿ｍａｃが含まれる。ここで、ＧｒｏｕｐＡｄｄには、ｒｏｓｔｅｒ＿ｉｎｄｅｘ、ｉｎｉｔ＿ｋｅｙ、ｗｅｌｃｏｍｅ＿ｈａｓｈが含まれる。

このようにＴｒｅｅＫＥＭ形式のグループステートをブロックチェーンネットワークで共有することにより、ＴＥＥサーバ２の各ペア間で秘密鍵を共有するよりも、効率的に鍵を共有することが可能となる。また、仮に暗号化に使う秘密鍵（ＴｒｅｅＫＥＭのルートノードの秘密鍵）が漏洩した場合であっても、それぞれ別の秘密鍵で暗号化しているため、他の暗号文は解読できない。また、それぞれのＴＥＥサーバ２がそれぞれ管理する秘密鍵で暗号化することができるので、秘密鍵漏洩の責務を主体ごとに分けることができる。

＜更新ハンドシェイク＞
図１４に示したＴｒｅｅＫＥＭにおいて、ノードＦを更新する場合の例を説明する。全てのメンバーＴＥＥサーバ２は更新されたグループルート（Ｋ）を得る。Ｆが更新されると、そのＨＫＤＦが親ノードであるＩの鍵となる。更新されたＩ及びＫは、それぞれのサブグループにだけ伝えられる。すなわち、ＩはＥの鍵で暗号化を行い、ＫはＪの鍵で暗号化を行う。更新（Update）のハンドシェイクには、ｐｒｉｏｒ＿ｅｐｏｃｈ、Ｕｐｄａｔｅ Ｏｐｅｒａｔｉｏｎ、ｓｉｇｎｅｒ＿ｉｎｄｅｘ、ｓｉｇｎａｔｕｒｅ、ｃｏｎｆ＿ｍａｃが含まれる。

＜削除ハンドシェイク＞
図１４に示したＴｒｅｅＫＥＭにおいて、Ｄを削除（Remove）するハンドシェイクを行う場合、当該ハンドシェイクはブロックチェーンネットワーク３０によりブロードキャストされ、Ｄが知っているノードの鍵を全て消去することになる。すなわち、ＤからルートＫまでの、Ｄ、Ｈ、Ｊ、Ｋの鍵が削除される。

＜書き込み処理＞
図１７は、書き込みの衝突を説明する図である。例えば、あるＴＥＥサーバ２においてアリスがボブに２０送金する状態遷移が生じ、他のＴＥＥサーバ２においてチャーリーがボブに３０送金する状態遷移が生じるという競合の可能性がある。ＴＥＥサーバ２は独立に動作しているため、オンチェーン上では匿名性が失われないように衝突検出（及びロック制御）が必要である。

図１８は、書き込み競合時のブロックチェーンネットワーク３０におけるブロック高を説明する図である。あるＴＥＥサーバ２（Ａ）において２つのブロックが追加され、他のＴＥＥサーバ２（Ｂ）において１つのブロックが追加される場合に、ＴＥＥサーバ２（Ａ）においてブロック高が５、ＴＥＥサーバ２（Ｂ）においてブロック高が６であった場合、ＴＥＥサーバ２（Ａ）及びＴＥＥサーバ２（Ｂ）の両方でブロック高７になるところ、競合排他制御を行った場合には、いずれもブロック高８になるべきである。

図１９は、書き込み衝突判定について説明する図である。書き込み操作が並行して行われないように、事前発生関係を補足する。すなわち、ＴＥＥサーバ２は、ブロックチェーンネットワーク３０に送信する暗号化情報には、固定バイト長の乱数ｒを追加するようにする。すなわち、公開鍵ｐｕｂｋｅｙ、状態情報ｓｔａｔｅ、現在の乱数（本実施形態ではハッシュ値とする。）ｒ＿ｉを含めて、暗号化関数Ｅｎｃに与えたＥｎｃ（ｐｕｂｋｅｙ｜｜ｓｔａｔｅ｜｜ｒ＿ｉ）を送信する。エンクレーブ２１内では、公開鍵ｐｕｂｋｅｙに対応付けて状態情報ｓｔａｔｅと、ハッシュ値ｒ＿ｉとを記録（ｐｕｂｋｅｙ＝＞（ｓｔａｔｅ，ｒ＿ｉ））する。

ＴＥＥサーバ２は、ロック制御用にｒのノンスセットをオンチェーンのストレージに追加する。また、トランザクションには、直前のハッシュｒ＿｛ｉ−１｝を含めるようにする。ブロックチェーンネットワーク３０では、ノンスセットにｒ＿｛ｉ−１｝が存在していないことを確認したうえで、ノンスセットにｒ＿ｉを加える。ブロックチェーンネットワーク３０におけるトランザクション処理は、グローバルに順序付けされる。したがって、ブロックに取り込まれるトランザクションがｒ＿｛ｉ−１｝を使うと、次のトランザクションではノンス検証ではじかれることになる。

図１９の例では、ＴＥＥサーバ２（Ａ）がボブの残高を７０に登録してブロック高が７になった後、ＴＥＥサーバ２（Ｂ）は、この状態を読み取り、ＴＥＥサーバ２（Ｂ）のｒ＿ｉはノンス検証ではじかれるため、新たにリトライ処理をすることで、ブロック高８にトランザクション処理が行われることになる。

なお、同一ユーザ（ＴＥＥサーバ２）による状態遷移は、１ブロックについて１回に制限するものとする。

図２０は、衝突検証を行う場合の秘密情報の状態遷移について説明する図である。ＴＥＥサーバ２とブロックチェーンネットワーク３０との間のデータ同期は、ベストエフォートにて各ＴＥＥサーバ２が独立して行う。同期が遅延しているＴＥＥサーバ２（Ａ）がボブの状態を書き換えるトランザクションをブロックチェーンネットワーク３０にブロードキャストする場合、乱数部分はｒ＿２でなくてはいけない。
ここで、ｒ＿０＝０であり、ｒ＿１は、ｒ＿０を含めたハッシュ値であり、例えば、遷移対象ａｃｃｏｕｎｔ、遷移させる状態をｓｔａｔｅ＿０として、ｒ＿１＝Ｈａｓｈ（ａｃｃｏｕｎｔ，ｓｔａｔｅ＿０，ｒ＿０）として求めることができる。同様に、ｒ＿２＝Ｈａｓｈ（ａｃｃｏｕｎｔ，ｓｔａｔｅ＿１，ｒ＿１）であり、一般化してｒ＿｛ｉ｝＝Ｈａｓｈ（ａｃｃｏｕｎｔ，ｓｔａｔｅ＿｛ｉ−１｝，ｒ＿｛ｉ−１｝）となる。図２０の例では、ｒ＿２＝Ｈａｓｈ（Ｂｏｂ，３０，ｒ＿１）となる。このように、直前の状態遷移時のハッシュ値を含めて暗号化を行うことにより、衝突検出を行うことが可能となる。

なお、衝突の検証を行わない遷移対象（アカウント）に対する状態遷移は、ロックを行わずに暗号化データをブロードキャストするようにしてもよい。例えば、送金における受け手の状態遷移が該当する。送り手は残高の検証を行う必要があるところ、「送金」のユースケースでは送り手が複数のＴＥＥサーバ２に跨がらないと考えられるため、実質的にはロックを行うことなく状態遷移をさせることができる。また、フラグを用いてロックを行うようにすることもできる。

図２１は、エンクレーブ２１における状態遷移の改ざん検出のための仕組みを説明する図である。全てのエンクレーブ２１は、少なくともユーザ（アカウント）の状態をマッピングしている部分については、同じ状態をブロック高ごとに持たなければならないため、そのハッシュ値をオンチェーンで一致することを検証することが好ましい。そこで、本実施形態のデータ管理システムでは、ブロックチェーンネットワーク３０における全てのトランザクションにブロック高とその時の状態ハッシュ値を含めるようにしている。すなわち、ＲＰＣハンドラ２２は、エンクレーブ２１に送るトランザクションインデックス（ｔｘ＿ｉｎｄｅｘ）がシーケンシャルになるようにキャッシュする。そして、状態変化を効率的にハッシュ計算し、かつその順序に対しての検証も行うことができるように、エンクレーブ２１が管理している状態（ｅｎｃｌａｖｅ＿ｓｔａｔｅ）のハッシュチェーンを作成する。すなわち、ハッシュ関数Ｈを用いて、ｉ番目のハッシュ値をＨＡＳＨ＿ｉ、ｉ番目の状態をｓｔａｔｅ＿ｉとして、ＨＡＳＨ＿ｉ＝Ｈ（ｓｔａｔｅ＿ｉ,Ｈ（ｓｔａｔｅ＿｛ｉ−１｝））によりハッシュ値を計算する。これにより、あるエンクレーブ２１において状態が改ざんされた場合であっても、その改ざんをブロックチェーンネットワーク３０又は他のＴＥＥサーバ２において検出することができる。また、本実施形態では、暗号化情報を管理するブロックチェーンネットワーク３０における全てのＢＣノード３において、暗号化情報の検証を行うことができる。したがって、従来技術のようにトランザクションデータの正当性を単一の認証サーバでのみ検証を行うような方式に加えて、安全性を向上することができる。

以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。

例えば、本実施形態では、ＴＥＥ（Trusted Execution Environment；トラステッド実行環境）を想定していたが、ＴＥＥに限らず、機密性の高いコンピューティング環境であればよい。例えば、ＡＷＳ Ｎｉｔｒｏ Ｅｎｃｌａｖｅｓなどのサービスを利用することも可能である。

また、本実施形態では、ＴＥＥサーバ２とＢＣノード３とは別体であるものとしたが、一体として、ＢＣノード３がエンクレーブ２１を備え、ＴＥＥサーバ２の機能を実現するようにしてもよい。

また、本実施形態では、グループステートはＴｒｅｅＫＥＭ形式であるものとしたが、これに限らず、例えば、非同期ラチェットツリー（Asynchronous Ratcheting Tree；ＡＲＴ）形式であってもよい。すなわち、グループステートは、グループ参加者（本実施形態では、全てのＴＥＥサーバ２）がその公開鍵を全員と共有することが可能であり、参加者全ての公開鍵と自身の秘密鍵とを用いてツリー構造などに応じてグループシードを算出することが可能であり、グループシードからハッシュ計算などにより計算したデータを共通のグループ鍵として算出することが可能であるような構造体であればよい。このグループ鍵を用いて秘密情報を暗号化することにより、全てのＴＥＥサーバ２が共通の鍵を用いて暗号化を行うことができ、また、グループステートへの公開鍵の追加、更新、削除は、グループへのメンバーの追加、更新、削除に対応付けることができる。

また、本実施形態では、ブロックチェーンネットワーク３０が暗号化情報を管理するものとしたが、これに限らず、データの改ざん防止を担保する分散型台帳の仕組みであればブロックチェーン以外の手法により管理するようにしてもよい。分散型台帳とは、複数のノードの間で、取り扱う台帳データをセキュアに共有する分散データベースである。ブロックチェーンも分散型台帳に含まれる。

１ ユーザ端末
２ ＴＥＥサーバ
３ ブロックチェーンノード
４ アテステーションサービス
２１ エンクレーブ
３０ ブロックチェーンネットワーク

Claims (7)

1. 分散台帳により管理しようとするデータの内容を、トラステッド実行環境を備えるトラステッドサーバに記録し、
   前記分散台帳には、前記データを暗号化した暗号データを記録し、
   前記トラステッドサーバで前記データの内容が更新された場合には、前記更新された内容を暗号化した前記暗号データを前記分散台帳に追加し、
   前記分散台帳に前記暗号データが追加された場合には、前記トラステッドサーバは、追加された前記暗号データを復号化して前記データの内容を更新し、
   前記トラステッドサーバは、固有の秘密鍵による署名を含むデータをアテステーションサービスに送信して正当性を検証させ、前記アテステーションサービスは検証結果に署名し、前記トラステッドサーバは、前記検証結果に、前記トラステッドサーバが作成した公開鍵を含めて前記分散台帳に登録し、前記分散台帳を構成するノードが、前記検証結果の署名を検証し、
   前記分散台帳におけるトランザクションの発生時には、登録されている前記公開鍵を用いて前記トランザクションに含まれる署名が検証されること、
   を特徴とするデータ管理方法。
2. 請求項１に記載のデータ管理方法であって、
   前記検証結果には、前記トラステッドサーバが実行しているプログラムを特定する情報が含まれ、
   前記トラステッドサーバは、前記検証結果の署名検証時に、自身が実行している前記プログラムが、前記検証結果に含まれている情報が示す前記プログラムと一致することを検証すること、
   を特徴とするデータ管理方法。
3. 請求項２に記載のデータ管理方法であって、
   前記ノードにおいてもさらに、前記検証結果に含まれている情報が示す前記プログラムと前記分散台帳に登録されている前記検証結果に含まれている情報が示す前記プログラムとが一致していることを検証すること、
   を特徴とするデータ管理方法。
4. 請求項１に記載のデータ管理方法であって、
   前記トラステッドサーバでは、前記秘密鍵及び前記公開鍵のペアを生成し、前記公開鍵を前記検証結果に含めて前記分散台帳に登録すること、
   を特徴とするデータ管理方法。
5. 請求項１に記載のデータ管理方法であって、
   前記トラステッドサーバを追加する場合に、
   追加される前記トラステッドサーバは、
   前記アテステーションサービスに自身の前記トラステッド実行環境の正当性を検証させ、
   前記アテステーションサービスによる検証結果を、既存の前記トラステッドサーバに送信し、
   前記既存のトラステッドサーバは、
   前記アテステーションサービスに自身の前記トラステッド実行環境の正当性を検証させ、
   前記アテステーションサービスによる検証結果と、前記追加されるトラステッドサーバから受信した前記検証結果とを照合して、前記追加されるトラステッドサーバの参加可否を決定すること、
   を特徴とするデータ管理方法。
6. 分散台帳により管理しようとするデータの内容を、トラステッド実行環境を備えるトラステッドサーバに記録し、
   前記分散台帳には、前記データを暗号化した暗号データを記録し、
   前記トラステッドサーバで前記データの内容が更新された場合には、前記更新された内容を暗号化した前記暗号データを前記分散台帳に追加し、
   前記分散台帳に前記暗号データが追加された場合には、前記トラステッドサーバは、追加された前記暗号データを復号化して前記データの内容を更新し、
   前記暗号化は共通のグループ鍵を用いて行われ、
   前記トラステッドサーバはそれぞれ自身の秘密鍵を有しており、全ての前記トラステッドサーバの公開鍵が前記分散台帳に記録されており、
   前記トラステッドサーバは、同一の前記グループ鍵を算出するように、全ての前記公開鍵と、自身の前記秘密鍵とを用いてシードを計算し、前記シードに基づいてグループ鍵を計算すること、
   を特徴とするデータ管理方法。
7. 分散台帳により管理しようとするデータの内容を、トラステッド実行環境を備えるトラステッドサーバに記録し、
   前記分散台帳には、前記データを暗号化した暗号データを記録し、
   前記トラステッドサーバで前記データの内容が更新された場合には、前記更新された内容を暗号化した前記暗号データを前記分散台帳に追加し、
   前記分散台帳に前記暗号データが追加された場合には、前記トラステッドサーバは、追加された前記暗号データを復号化して前記データの内容を更新し、
   前記トラステッドサーバは、前記分散台帳で管理されるブロックごとの全てのデータの第１のハッシュ値を計算して、前記第１のハッシュ値を前記分散台帳に記録し、前記データの内容が更新された場合には、更新前の前記第１のハッシュ値と更新後の全前記ブロックの内容との第２のハッシュ値を計算して、前記第２のハッシュ値を前記分散台帳に記録すること、
   を特徴とするデータ管理方法。
   
   

Images