特開 2024-65849 データ保持システム

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024065849

(43)【公開日】2024-05-15

(54)【発明の名称】データ保持システム

(51)【国際特許分類】

   G09C 1/00 20060101AFI20240508BHJP

   H04L 9/08 20060101ALI20240508BHJP

【ＦＩ】

G09C1/00 650Z

H04L9/08 A

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2022174915

(22)【出願日】2022-10-31

(71)【出願人】

【識別番号】000155469

【氏名又は名称】株式会社野村総合研究所

(74)【代理人】

【識別番号】100216677

【弁理士】

【氏名又は名称】坂次 哲也

(72)【発明者】

【氏名】川口 将司

(57)【要約】

【課題】秘密鍵などの元データから秘密分散により得られたシェアをより安全に保持する。
【解決手段】（ｍ，ｎ）秘密分散ベースのマルチパーティ計算（ＭＰＣ）に利用されるｎ個のシェア３２をｎ個のシェア保持サーバ４に分散して保持し、各シェア保持サーバ４において連携して、乱数に基づいて、元データ３１の復元時に乱数の影響が相殺されるように各シェア３２を更新して新たなリビジョンとするデータ保持システム１であって、（ｍ－１）個のシェア保持サーバ４において同一のリビジョンのシェア３２に対するアクセスが発生し、もしくは発生する可能性があるというアクセス状態である場合に、他の（ｎ－（ｍ－１））個のシェア保持サーバ４において、保持するシェア３２に対するアクセスをロックする。
【選択図】図１

【特許請求の範囲】

【請求項1】

（ｍ，ｎ）秘密分散ベースのマルチパーティ計算（ＭＰＣ）に利用されるｎ個のシェアをｎ個のシェア保持サーバに分散して保持し、前記各シェア保持サーバにおいて連携して、乱数に基づいて、元データの復元時に前記乱数の影響が相殺されるように各シェアを更新して新たなリビジョンとするデータ保持システムであって、
（ｍ－１）個の前記シェア保持サーバにおいて同一のリビジョンのシェアに対するアクセスが発生し、もしくは発生する可能性があるというアクセス状態である場合に、他の（ｎ－（ｍ－１））個の前記シェア保持サーバにおいて、保持するシェアに対するアクセスをロックする、データ保持システム。

【請求項2】

請求項１に記載のデータ保持システムにおいて、
第１のシェア保持サーバは、自身が保持するシェアに対するアクセス要求が発生した場合、当該アクセスを許可する前に、他の（ｎ－１）個の第２のシェア保持サーバに対して、アクセス要求が発生した旨のメッセージを送信し、
前記各第２のシェア保持サーバは、前記メッセージを受信した場合に、自身が保持するシェアについてアクセス状態にあるか否かを示す情報と、当該シェアのリビジョンの情報と、を含む応答を前記第１のシェア保持サーバに送信し、
前記第１のシェア保持サーバは、前記各第２のシェア保持サーバから受信した前記応答に基づいて、自身が保持するシェアのリビジョンと同一のリビジョンのシェアについてアクセス状態にある前記シェア保持サーバの数を集計する、データ保持システム。

【請求項3】

請求項２に記載のデータ保持システムにおいて、
前記第１のシェア保持サーバは、前記メッセージを送信した後、所定の時間の間、前記各第２のシェア保持サーバからの前記応答を受信し、前記所定の時間の経過後、前記応答を受信した前記各第２のシェア保持サーバの数ｎ’と、受信した前記応答に基づいて集計した、アクセス状態にある前記シェア保持サーバの数ｍ’と、に基づいて、（ｍ－ｍ’）が（ｎ－ｎ’）以下である場合に、保持するシェアに対するアクセスをロックする、データ保持システム。

【請求項4】

請求項３に記載のデータ保持システムにおいて、
前記第１のシェア保持サーバは、（ｍ－ｍ’）が（ｎ－ｎ’）以下である場合に、保持するシェアに対するアクセスをロックするのに代えて、当該シェアのリビジョンが更新されるのを待ち、当該シェアのリビジョンが更新された後に、他の（ｎ－１）個の前記各第２のシェア保持サーバに対して改めて前記メッセージを送信する、データ保持システム。

【請求項5】

請求項２に記載のデータ保持システムにおいて、
前記第２のシェア保持サーバは、自身が保持するシェアに対するアクセス要求が発生した場合に、アクセスを許可するか否かを判定する前であっても、前記第１のシェア保持サーバから送信された前記メッセージを受信した場合に、自身が保持するシェアについてアクセス状態にある旨の前記応答を送信する、データ保持システム。

【請求項6】

請求項２に記載のデータ保持システムにおいて、
前記第２のシェア保持サーバは、前記第１のシェア保持サーバから受信した前記メッセージに対して、自身が保持するシェアについてアクセス状態にない旨の前記応答を送信した場合、その後第１の期間の間、第２の期間毎に継続的に、自身が保持するシェアについてアクセス状態にあるか否かの情報を含む前記応答を送信する、データ保持システム。

【請求項7】

請求項２に記載のデータ保持システムにおいて、
前記第２のシェア保持サーバは、前記第１のシェア保持サーバからの前記メッセージの受信の有無に関わらず、他の（ｎ－１）個の前記シェア保持サーバに対して、第２の期間毎に継続的に、自身が保持するシェアについてアクセス状態にあるか否かの情報を含む前記応答を送信する、データ保持システム。

【請求項8】

請求項６に記載のデータ保持システムにおいて、
前記第１のシェア保持サーバは、自身が保持するシェアに対するアクセス要求が発生した場合、当該アクセスを許可する前に、前記第１の期間の間、前記各第２のシェア保持サーバからの前記応答を受信し、前記第１の期間の経過後、前記各第２のシェア保持サーバから受信した前記応答のうち最新のリビジョンのものに基づいて、自身が保持するシェアのリビジョンと同一のリビジョンのシェアについてアクセス状態にある前記シェア保持サーバの数を集計する、データ保持システム。

【請求項9】

請求項８に記載のデータ保持システムにおいて、
前記第１のシェア保持サーバは、自身が保持するシェアに対するアクセス要求が発生してから前記第１の期間の経過時点が、当該シェアのリビジョンの更新時点から第３の期間が経過するまでの間にある場合、前記第１の期間の後さらに前記第３の期間が経過するまでの間、前記各第２のシェア保持サーバからの前記応答を受信し、前記第１の期間の後さらに前記第３の期間が経過した後に、前記各第２のシェア保持サーバから受信した前記応答のうち最新のリビジョンのものに基づいて、自身が保持するシェアのリビジョンと同一のリビジョンのシェアについてアクセス状態にある前記シェア保持サーバの数を集計する、データ保持システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データを保持する技術に関し、特に、秘密分散法により分割されたデータを保持するデータ保持システムに適用して有効な技術に関するものである。

【背景技術】

【0002】

ブロックチェーン技術を利用した暗号資産（仮想通貨）の普及が進んでいる。暗号資産の送金等の際には利用者のアカウントの秘密鍵によって署名がされることから、秘密鍵は秘匿して管理し、利用者以外の他人に知られないように管理しなければならない。

【0003】

秘密鍵の秘匿管理においては、例えば、パスワードと暗号化による秘匿の場合はパスワードの漏洩によって容易に復号されてしまうリスクがある。そこで、いわゆる秘密分散の技術を利用して、秘密鍵のデータを複数のシェア（所定の数以上集めなければ元の秘密鍵を復元できないようなデータ）に分割し、分割したシェアをそれぞれ異なるサーバや異なるパーティによる管理下に分散して保持するという手法もとられている。

【0004】

このとき、署名等の処理を行うために、シェアの形で秘密分散されている状態から元の秘密鍵のデータを都度復元するものとすると、復元されて秘密鍵として存在している間に漏洩等が生じてしまうリスクがある。そこで、シェアの形で秘密分散された状態のまま演算を行って結果を得るという秘密分散ベースのマルチパーティ計算（Multi-Party Computation、ＭＰＣ）の技術を用いて、シェアの形で秘密分散された秘密鍵を復元せずに署名等の処理を行う技術も用いられている。

【0005】

このような技術により、秘密鍵のセキュリティは大きく強化されているが、秘密分散技術によってもセキュリティを完全に維持することはできない。例えば、シェアを保持している各パーティにおいてシェアにアクセスできる権限を持った管理者等が、結託して必要な数以上のシェアを取得する（管理者等の能力不足によりシェアが流出することも含む）ことで秘密鍵を復元することができてしまう。

【0006】

このようにＭＰＣの参加者が結託することによる秘密の漏洩への対策に係る技術として、例えば、特開２０２１－１２８２６１号公報（特許文献１）には、ＭＰＣに参加する各装置が有するシェアの値を、各環境において定期的に乱数によって更新するものとし、当該乱数によってそれぞれ更新された各装置のシェアを合わせると、当該乱数による影響が相殺されて元のデータが復元されるように設計されており、さらに、定期的に更新されるシェアのリビジョンと、当該リビジョンのシェアに対するアクセスの履歴情報とを対応付けて記録することが記載されている。

【先行技術文献】

【特許文献】

【0007】

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

【発明の概要】

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

【0008】

特許文献１に記載されたような従来技術によれば、同じリビジョンのシェアが所定の数以上流出しない限り元の秘密鍵が流出することはないことから、各パーティの管理者等が結託するにしても時間的に制限を設けることができ、安全性を高めることができるとともに、仮に同じリビジョンのシェアが所定の数以上流出したとしても、アクセスの履歴情報が対応付けられていることから、結託した管理者等を絞り込むことができ、トレーサビリティを高めるとともに結託に対する抑止力とすることもできる。

【0009】

一方で、このような対策を施したとしても、管理者等が結託して同じリビジョンのシェアを流出させて秘密鍵を得ることが困難とはなるものの、全くできなくなるわけではない。また、シェアを流出させた管理者等を後から絞り込むことが可能ではあるとはいえ、流出自体がなかったことになるわけではない。しかし、秘密鍵の流出は暗号資産の流出につながることから厳に回避することが要求される。

【0010】

そこで本発明の目的は、秘密鍵などの元データから秘密分散により得られたシェアをより安全に保持するデータ保持システムを提供することにある。

【0011】

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記載および添付図面から明らかになるであろう。

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

【0012】

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

【0013】

本発明の代表的な実施の形態であるデータ保持システムは、（ｍ，ｎ）秘密分散ベースのマルチパーティ計算（ＭＰＣ）に利用されるｎ個のシェアをｎ個のシェア保持サーバに分散して保持し、前記各シェア保持サーバにおいて連携して、乱数に基づいて、元データの復元時に前記乱数の影響が相殺されるように各シェアを更新して新たなリビジョンとするデータ保持システムであって、（ｍ－１）個の前記シェア保持サーバにおいて同一のリビジョンのシェアに対するアクセスが発生し、もしくは発生する可能性があるというアクセス状態である場合に、他の（ｎ－（ｍ－１））個の前記シェア保持サーバにおいて、保持するシェアに対するアクセスをロックするものである。

【発明の効果】

【0014】

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば、以下のとおりである。

【0015】

すなわち、本発明の代表的な実施の形態によれば、秘密鍵などの元データから秘密分散により得られたシェアをより安全に保持することが可能となる。

【図面の簡単な説明】

【0016】

【図1】本発明の一実施の形態であるデータ保持システムの構成例について概要を示した図である。

【図2】本発明の一実施の形態におけるシェアの更新の例について概要を示した図である。

【図3】本発明の一実施の形態におけるシェアの更新の例について概要を示した図である。

【図4】本発明の一実施の形態における結託防止の仕組みの例について概要を示した図である。

【図5】本発明の一実施の形態におけるデータ所有者端末の構成例について概要を示した図である。

【図6】本発明の一実施の形態におけるデータ検証者端末の構成例について概要を示した図である。

【図7】本発明の一実施の形態におけるシェア保持サーバの構成例について概要を示した図である。

【図8】（ａ）、（ｂ）は、本発明の一実施の形態におけるシェアをシェア保持サーバに分散保持する構成の例について概要を示した図である。

【図9】本発明の一実施の形態におけるアクセスのロックに係る処理の流れの例について概要を示した図である。

【図10】本発明の一実施の形態におけるアクセスのロックに係る処理の流れの他の例について概要を示した図である。

【図11】（ａ）～（ｃ）は、本発明の一実施の形態におけるアクセス要求が発生した際のアクセス可否の判定タイミングの例について概要を示した図である。

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

【0017】

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。

【0018】

＜概要＞
本発明の一実施の形態であるデータ保持システムは、上述の特許文献１に記載されたような、ｍ－ｏｕｔ－ｏｆ－ｎの秘密分散（元データをｎ個のシェアに分散し、元データを復元するにはそのうちｍ個以上のシェアを必要とするもの。以下では「（ｍ，ｎ）秘密分散」と記載する場合がある）ベースのＭＰＣに利用されるシェアを保持する仕組みである。

【0019】

特許文献１に記載された技術では、ＭＰＣに参加する各装置が有するシェアの値を、各環境において定期的に乱数によって更新するものとし、当該乱数によってそれぞれ更新された各装置のシェアを合わせると、当該乱数による影響が相殺されて元のデータが復元されるように設計されており、さらに、定期的に更新されるシェアのリビジョンと、当該リビジョンのシェアに対するアクセスの履歴情報とを対応付けて記録する。本実施の形態では、上記の仕組みにおいて、さらに、管理者等が結託して同じリビジョンのシェアを流出させて元のデータを得ることを防止することを可能とするものである。

【0020】

（ｍ，ｎ）秘密分散では、ｎ個のシェアのうちｍ個以上を集めると元データを復元することができる一方、集めたシェアが（ｍ－１）個までの場合は、元データを復元できないばかりでなく、元データについての何らのヒントも得ることができない（元データが取り得る範囲を絞り込むこともできない）。例えば、（２，２）秘密分散の例として、元データをＳ、２つのシェアをＳ_１、Ｓ_２とすると、
Ｓ＝（Ｓ_１＋Ｓ_２）ｍｏｄ Ｐ （式１）
もしくは
Ｓ＝Ｓ_１ XOR Ｓ_２ （式２）
の式を満たすものとしてシェアを得ることができる。なお、上記の式１において「＋」の演算子は加算であり、Ｐは素数もしくはガロア拡大体（２^ｋ（ｋはＳのビット長以上の任意の整数））である。また、式２において「XOR」の演算子は排他的論理和である。以下に説明する本実施の形態では、上記の式１を用いてシェアを生成するものとするが、式２を用いる場合でも同様に適用することができる。

【0021】

図２、図３は、本発明の一実施の形態におけるシェアの更新の例について概要を示した図である。例えば、左端に示すように、元データが「７」である場合、上記の式１において法Ｐ＝１６、すなわち１６で巡回する環境を考えると、図示するようにシェアＡ（Ｓ_１）＝１５、シェアＢ（Ｓ_２）＝８とすれば、式１により、
（１５＋８）ｍｏｄ１６＝７
となり、元データの７を復元することができる。

【0022】

上述したように、本実施の形態では、特許文献１の仕組みと同様に、各環境において定期的に乱数によってシェアを更新するものとし、当該乱数によってそれぞれ更新された各装置のシェアを合わせると、当該乱数による影響が相殺されて元のデータが復元されるようにする。例えば、シェア更新用の乱数を生成し、シェアＡには当該乱数を加算する一方で、シェアＢから当該乱数を減算することでシェアＡとシェアＢを上記の式１により加算したときの影響を相殺することができる。

【0023】

乱数による更新の影響を相殺する他の例として、シェアＡには更新用の乱数を加算する一方で、シェアＢには、法１６の元でゼロとなる値を加算することも可能である。図２の例では、左端の状態に対して、シェア更新用の乱数として「３」が生成された場合、シェアＡには「３」を加算する一方、シェアＢには、３との組み合わせで法１６の元でゼロとなる値である「１３」を加算する。この場合、シェアＡとシェアＢにそれぞれ加算した値を法１６の元で合計するとゼロとなることから、上記に式１において元データに与える影響はゼロとなる。次も同様に、シェア更新用の乱数として「６」が生成された場合、シェアＡには「６」を加算する一方、シェアＢには６との組み合わせで法１６の元でゼロとなる値である「１０」を加算することで、元データに与える影響をゼロとしつつシェアを更新することができる。以降の例も同様である。

【0024】

図２の例において各シェアに更新用の値を順次加算してシェアの値を計算していったときの例を図３に示している。左端のシェアＡの値「１５」を更新する際、図２の例に示すように法１６の元で「３」を加算すると、
（１５＋３）ｍｏｄ１６＝２
となって、シェアＡの値は「２」となる。同様に、シェアＢの値「８」を更新する際、図２の例に示すように法１６の元で「１３」を加算すると、
（８＋１３）ｍｏｄ１６＝５
となって、シェアＢの値は「５」となる。ここで更新後のシェアＡとシェアＢから、式１により、
（２＋５）ｍｏｄ１６＝７
として元データの「７」を復元することができる。図３に示す以降の例も同様である。このようにそれぞれ同じ更新用の乱数に基づいて順次更新された、すなわち同じリビジョンのシェアＡとシェアＢからは元データを正しく復元することができる一方、対応するシェアＡとシェアＢではないずれた関係、すなわち異なるリビジョンのシェアＡとシェアＢとでは、正しく元データを復元することができないことが分かる。

【0025】

図４は、本発明の一実施の形態における結託防止の仕組みの例について概要を示した図である。図４の例では、上述したような手法により元データから生成したシェアＡとシェアＢを異なる環境（サーバ）上に分散保管し、各環境において乱数により各シェアを順次更新していく状況を示している。なお、各環境においてリビジョンの情報は管理されており、リビジョンを更新するタイミングも共有されているものとする。例えば、１日１回２４時のタイミングで更新するとか、１０分に１回更新するなど、定期的な更新タイミングを取り決めておいて各環境がそれに従うようにしてもよいし、更新タイミングは不定期だが、各環境が通信により相互に合意形成してリビジョン更新のタイミングの同期をとるようにしてもよい。

【0026】

上述したように、同じリビジョンのシェア同士でなければ正しく元データを復元することができないため、例えば、図中の「シェアＡ１」や「シェアＡ４」、「シェアＢ５」のように、各環境の管理者等がシェアにアクセスしてこれを入手したとしても、同一リビジョンの対応するシェアが合計でｍ個以上（図４の例では２個）アクセスされていない限り、元データが漏洩することはない。

【0027】

一方で、「シェアＡ２」および「シェアＢ２」のように、各環境の管理者等により同一リビジョンのシェアが結託してアクセスされた場合には元データが復元されてしまう。しかし、同一リビジョンのシェアにアクセスするには同一時間帯にアクセスする必要があることから、各環境でのアクセス履歴を記録しておくことで事後的にデータ漏洩をもたらした管理者等を絞り込むことができ、トレーサビリティを向上させるとともに抑止力とすることもできる。

【0028】

特許文献１に記載された技術は、シェアの値を更新することで機密性を高めるProactive Secret Sharing（ＰＳＳ）という手法を定期的に実施した上で、各環境においてシェアに対するアクセス履歴を残すことで、不正に元のデータを復元しようとした者を特定しようとする技術であった。これに対し、本発明の一実施の形態であるデータ保持システムは、（ｍ－１）個の環境（パーティ、サーバ）においてシェアへのアクセスが発生したとき、まだアクセスが発生していない残りの（ｎ－（ｍ－１））個の環境上でシェアへのアクセスをロックすることで、ｍ個以上のシェアが取得されて元のデータが復元されることを防止するものである。

【0029】

この仕組みによる場合、基本的には元のデータを一切復元することができなくなる。一方で、例えば、暗号資産（仮想通貨）を保持するためのウォレットプログラムにおいて管理されている秘密鍵のようなデータについては、シェアの状態でＭＰＣによる署名等の限られた計算処理を行うことができればよく、元のデータを復元する必要は全く生じない（もしくはほぼない）。このような用途においては、元のデータを復元することができなくても特段の問題はなく、むしろ秘密鍵などの元のデータの漏洩を高いレベルで防止することができる。

【0030】

なお、上述したように、本実施の形態ではＰＳＳの手法によりシェアの値を更新しているが、ＰＳＳの手法は上記で例示したものに限られるものではない。加法的秘密分散法に基づくＰＳＳであれば任意の手法を採用することができる。

【0031】

＜システム構成＞
図１は、本発明の一実施の形態であるデータ保持システムの構成例について概要を示した図である。データ保持システム１は、例えば、ｎ個以上のシェア保持サーバ４から構成される。図１の例では、元データ３１を所有するデータ所有者２が使用するデータ所有者端末３において（２，２）秘密分散により生成された２つのシェアを保持するものとして、シェア保持サーバＡ（４ａ）とシェア保持サーバＢ（４ｂ）の２つを有する構成を示している。図中では、各シェア保持サーバ４によるＭＰＣの計算結果である結果データ６１を検証するデータ検証者５が使用するデータ検証者端末６についても示している。データ保持システム１として、データ所有者端末３やデータ検証者端末６まで含む構成であってもよい。 なお、各シェア保持サーバ４とデータ所有者端末３の間、および各シェア保持サーバ４とデータ検証者端末６の間はそれぞれ、図示しないインターネット等のネットワークにより通信可能に構成される。

【0032】

各シェア保持サーバ４は、それぞれサーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバ、ＰＣ等により構成され、図示しないＣＰＵ（Central Processing Unit）により、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の記録装置からメモリ上に展開したＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラム等のミドルウェアや、その上で稼働するソフトウェアを実行することで、シェア３２の保持とＭＰＣに係る各種機能を実現する。なお、各シェア保持サーバ４は、それぞれが独立した別の環境（パーティ）によって管理され、上記機能を実現できる限り具体的な構成は異なっていてもよい。

【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】

１…データ保持システム、２…データ所有者、３…データ所有者端末、４…シェア保持サーバ、４ａ…シェア保持サーバＡ、４ｂ…シェア保持サーバＢ、５…データ検証者、６…データ検証者端末、７…仲介サーバ、
３１…元データ、３２…シェア、３２ａ…シェアＡ、３２ｂ…シェアＢ、３３…シェア生成部、３４…分散処理部、
４１…シェア管理部、４２…ＭＰＣ計算部、４３…シェア更新用乱数取得部、４４…シェア更新部、４５…アクセス管理部、４６…シェアロック部、４７…シェア管理ＤＢ、４８…アクセス履歴ＤＢ、
６１…結果データ、６２…結果シェア、６２ａ…結果シェアＡ、６２ｂ…結果シェアＢ
６３…シェア収集部、６４…データ検証部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】