(57)【要約】  デジタル署名されたデータを取得する方法が開示される。当該方法は、複数の第１参加者のうちの少なくとも１人の第１参加者から少なくとも１人の第２参加者へ第１データ(e2)を送信するステップであって、前記第１データは少なくとも１人の前記第１参加者によりアクセス可能な第２データ(e)に基づき、前記第２データは、前記第２参加者の各々によりアクセス不可能である、ステップを含む。前記第１データのデジタル署名(s1)は少なくとも１人の前記第２参加者から受信され、前記第１データの前記デジタル署名は、前記第２データのデジタル署名(s)のシェアを提供するために、複数の前記第１参加者により処理され、前記第２データの前記デジタル署名は、閾数の前記シェアを用いてアクセス可能であり、前記閾数より少ないシェアでアクセス不可能である。
2021510954.tif 000002
【特許請求の範囲】
【請求項１】
デジタル署名されたデータを取得する方法であって、前記方法は、
複数の第１参加者のうちの少なくとも１人の第１参加者から少なくとも１人の第２参加者へ、第１データを送信するステップであって、前記第１データは少なくとも１人の前記第１参加者がアクセス可能な第２データに基づき、前記第２データは前記第２参加者の各々がアクセス不可能なデータである、ステップと、
少なくとも１人の前記第２参加者から、前記第１データのデジタル署名を受信するステップと、
複数の前記第１参加者により前記第１データの前記デジタル署名を処理して、前記第２データのデジタル署名のシェアを提供するステップであって、前記第２データの前記デジタル署名は閾数の前記シェアを用いてアクセス可能であり、前記閾数より少ないシェアによりアクセス不可能である、ステップと、
を含む方法。
【請求項２】
前記第２データの前記デジタル署名の前記シェアの各々は、複数の前記第１参加者の間でJRSS（joint  random  secret  sharing）を用いて共有される複数の第１シークレット値のシェアを含む、請求項１に記載の方法。
【請求項３】
前記第２データの前記デジタル署名の前記シェアの各々は、複数の前記第１参加者の間でJZSS（joint  zero  secret  sharing）を用いて共有される少なくとも１つの第１マスキングシェアを含む、請求項２に記載の方法。
【請求項４】
前記第１データは前記第１データのシェアを用いて生成され、その結果、前記第１データは閾数の前記シェアを用いてアクセス可能であり、前記閾数より少ないシェアでアクセス不可能である、請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
前記第１データの前記シェアの各々は、複数の前記第１参加者の間でJRSS（joint  random  secret  sharing）を用いて共有される複数の前記第１シークレット値のシェアを含む、請求項４に記載の方法。
【請求項６】
前記第１データの前記シェアの各々は、複数の前記第１参加者の間でJZSS（joint  zero  secret  sharing）を用いて共有される少なくとも１つの第２マスキングシェアを含む、請求項５に記載の方法。
【請求項７】
少なくとも１人の前記第２参加者から、前記第２シークレット値に基づく第３データを受信するステップ、を更に含む請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
前記第１データの前記デジタル署名は、複数の前記第２参加者の間で共有される、前記第１データの前記デジタル署名のシェアを用いて生成され、前記第１データの前記デジタル署名は閾数の前記シェアを用いてアクセス可能であり、前記閾数より少ないシェアでアクセス不可能である、請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
前記第１データの前記デジタル署名の前記シェアの各々は、複数の前記第２参加者の間でJRSS（joint  random  secret  sharing）を用いて共有される複数の第２シークレット値のシェアを含む、請求項８に記載の方法。
【請求項１０】
前記第１データの前記デジタル署名の前記シェアの各々は、複数の前記第２参加者の間でJZSS（joint  zero  secret  sharing）を用いて共有される少なくとも１つの第３マスキングシェアを含む、請求項９に記載の方法。
【請求項１１】
前記第２データはメッセージである、請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
前記第２データはメッセージのハッシュ値である、請求項１乃至１０のいずれか一項に記載の方法。
【請求項１３】
前記第１データはブロックチェーントランザクションである、請求項１乃至１２のいずれか一項に記載の方法。
【請求項１４】
少なくとも１つの前記デジタル署名は、同型の特性を有する暗号システムに基づく、請求項１乃至１３のいずれか一項に記載の方法。
【請求項１５】
少なくとも１つの前記デジタル署名は、楕円曲線暗号システムに基づく、請求項１４に記載の方法。
【請求項１６】
コンピュータにより実装されるシステムであって、
プロセッサと、
前記プロセッサによる実行の結果として、前記システムに請求項１乃至１５のいずれか一項に記載のコンピュータにより実施される方法の任意の実施形態を実行させる実行可能命令を含むメモリと、
を含むシステム。
【請求項１７】
実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、少なくとも、前記コンピュータシステムに、請求項１乃至１５のいずれか一項に記載のコンピュータにより実施される方法を実行させる、非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、データのセキュリティ及びコンピュータに基づくリソースに関する。より具体的には、本発明は、暗号通貨及び暗号法に関し、楕円曲線暗号法、楕円曲線デジタル署名アルゴリズム（Elliptic  Curve  Digital  Signature  Algorithm：ECDSA）、及び閾値暗号法にも関する。本発明は、ブロックチェーンにより実装される暗号通貨に関連して利益をもたらすために使用できるが、これに関して限定されず、より広範な適用可能性を有し得る。本発明は、一実施形態では、ブラインドディーラ不要閾値のための配信プロトコルを提供するとして記載され得る。
【背景技術】
【０００２】
本願明細書では、私たちは、全ての形式の電子的、コンピュータに基づく、分散型台帳を包含するために用語「ブロックチェーン」を使用する。これらは、総意に基づくブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳、並びにこれらの変形を含む。他のブロックチェーン実装が提案され開発されているが、ブロックチェーン技術の最も広く知られているアプリケーションは、Bitcoin台帳である。Bitcoinは、ここでは、便宜上及び説明の目的で参照されることがあるが、本発明はBitcoinブロックチェーンと共に使用することに限定されず、代替のブロックチェーン実装及びプロトコルが本発明の範囲に包含されることに留意すべきである。用語「ユーザ」は、ここでは、人間またはプロセッサに基づくリソースを表してよい。
【０００３】
ブロックチェーンは、コンピュータに基づく非集中型の分散型システムとして実装されるピアツーピアの電子台帳であり、ブロックにより構成され、ブロックはまたトランザクションにより構成される。各トランザクションは、ブロックチェーンシステムの中の参加者間でデジタルアセットの制御の移転を符号化するデータ構造であり、少なくとも１つのインプット及び少なくとも１つのアウトプットを含む。各ブロックは前のブロックのハッシュを含み、これらのブロックは一緒に繋げられて、起源以来ブロックチェーンに書き込まれている全てのトランザクションの永久的な変更不可能な記録を生成する。トランザクションは、スクリプトとして知られている小さなプログラムを含む。スクリプトは、それらのインプット及びアウトプットを埋め込まれ、トランザクションのアウトプットがどのように及び誰によりアクセス可能であるかを指定する。Bitcoinプラットフォームでは、これらのスクリプトはスタックに基づくスクリプト言語を用いて記述される。
【０００４】
トランザクションがブロックチェーンに書き込まれるためには、検証されなければならない。ネットワークノード（マイナー）は、無効なトランザクションがネットワークから拒否され、各トランザクションが有効であることを保証するために作業を実行する。ノードにインストールされたソフトウェアクライアントは、未使用トランザクション（unspent  transaction,  UTXO）のロック及びアンロックスクリプトを実行することにより、UTXOに対してこの検証作業を実行する。ロック及びアンロックスクリプトの実行が真（TRUE）と評価する場合、トランザクションは有効であり、トランザクションはブロックチェーンに書き込まれる。したがって、トランザクションがブロックチェーンに書き込まれるためには、(i)トランザクションを受信した第１ノードにより検証され、トランザクションが有効な場合には、ノードが該トランザクションをネットワーク内の他のノードに中継する、（ｉｉ）マイナーにより構築された新しいブロックに追加される、（ｉｉｉ）マイニングされる、つまり過去のトランザクションのパブリック台帳に追加される、ことが必要である。
【０００５】
ブロックチェーン技術は、暗号通貨の実装の使用のために最も広く知られているが、デジタル事業家が、Bitcoinの基づく暗号セキュリティシステム及び新しいシステムを実装するためにブロックチェーンに格納できるデータの両方の使用を開発し始めている。ブロックチェーンが、暗号通貨の分野に限定されない自動化タスク及びプロセスのために使用できれば、非常に有利になる。このようなソリューションは、ブロックチェーンの利益（例えば、永久性、イベントの記録の耐タンパ性、分散型処理、等）を利用しながら、それらの用途をより多様化し得る。
【０００６】
非集中化の概念は、Bitcoin方法にとって基本的である。非集中化システムは、分散型又は集中型システムと異なり、単一の障害点が存在しないという利点を提供する。したがって、非集中化システムは、拡張されたレベルのセキュリティ及び信頼性を提供する。このセキュリティは、楕円曲線暗号法及びECDSAのような、知られている暗号化技術の使用により更に拡張される。
【０００７】
しかしながら、Bitcoinプロトコル自体は、本願の出願時において任意の有意な攻撃に対して強靱であることが証明されているが、Bitcoinネットワークを補う又はそれに基づき構築された交換及びウォレットに対する攻撃が存在する。Bitcoinの価値が増大するにつれ、Ｍｔ  Ｇｏｘ及びＢｉｔｆｉｎｅｘに関連するような、より多くの出来事が標準的な集中型システムにおいて生じる可能性がある。
【０００８】
したがって、このようなシステムのセキュリティを更に向上するソリューションの必要がある。本発明は、特にこのような利点を提供する。
【発明の概要】
【０００９】
本発明は、添付の請求の範囲に定められた方法及びシステムを提供する。
【００１０】
本発明によると、デジタル署名されたデータを取得する方法であって、前記方法は、
複数の第１参加者のうちの少なくとも１人の第１参加者から少なくとも１人の第２参加者へ、第１データを送信するステップであって、前記第１データは少なくとも１人の前記第１参加者がアクセス可能な第２データに基づき、前記第２データは前記第２参加者の各々がアクセス不可能なデータである、ステップと、
少なくとも１人の前記第２参加者から、前記第１データのデジタル署名を受信するステップと、
複数の前記第１参加者により前記第１データの前記デジタル署名を処理して、前記第２データのデジタル署名のシェアを提供するステップであって、前記第２データの前記デジタル署名は閾数の前記シェアを用いてアクセス可能であり、前記閾数より少ないシェアによりアクセス不可能である、ステップと、
を含む方法が提供され得る。
【００１１】
複数の第１参加者により、第１データのデジタル署名を処理することにより、第２データのデジタル署名のシェアを提供する。ここで、第２データのデジタル署名は、閾数のシェアを持ち手アクセス可能であり、閾数より少ないシェアでアクセス不可能である。これは、第２参加者が第２データへのアクセスを有しないが、第１データに署名し、第２データのデジタル署名を提供可能にするので、セキュリティを向上するという利点をもたらすと同時に、閾数構成を用いてセキュリティを更に向上する。これは、第１参加者が第２参加者を、ブロックチェーントランザクションのようなメッセージに署名するための秘密鍵の保管人として指名できると同時に、第２データは第２参加者によりアクセス不可能であるので、第２参加者が鍵の未認可の使用を行うことを防ぐ、という利点をもたらす。
【００１２】
前記第２データの前記デジタル署名の前記シェアの各々は、複数の前記第１参加者の間でJRSS（joint  random  secret  sharing）を用いて共有される複数の第１シークレット値のシェアを含んでよい。
【００１３】
これは、第１シークレット値が第１参加者により共同で選択されるディーラー不要のシークレット値共有方式を提供することにより、セキュリティを向上し、それにより、単一のディーラーの形式のシステムの弱点を回避するという利点をもたらす。
【００１４】
前記第２データの前記デジタル署名の前記シェアの各々は、複数の前記第１参加者の間でJZSS（joint  zero  secret  sharing）を用いて共有される少なくとも１つの第１マスキングシェアを含んでよい。
【００１５】
前記第１データは前記第１データのシェアを用いて生成されてよく、その結果、前記第１データは閾数の前記シェアを用いてアクセス可能であり、前記閾数より少ないシェアでアクセス不可能である。
【００１６】
前記第１データの前記シェアの各々は、複数の前記第１参加者の間でJRSS（joint  random  secret  sharing）を用いて共有される複数の前記第１シークレット値のシェアを含んでよい。
【００１７】
前記第１データの前記シェアの各々は、複数の前記第１参加者の間でJZSS（joint  zero  secret  sharing）を用いて共有される少なくとも１つの第２マスキングシェアを含んでよい。
【００１８】
前記方法は、少なくとも１人の前記第２参加者から、前記第２シークレット値に基づく第３データを受信するステップ、を更に含んでよい。
【００１９】
これは、第１データのデジタル署名からの第２データのデジタル署名の生成を支援するという利点をもたらす。
【００２０】
前記第１データのデジタル署名は、複数の前記第２参加者の間で共有される、前記第１データの前記デジタル署名のシェアを用いて生成されてよく、前記第１データの前記デジタル署名は閾数の前記シェアを用いてアクセス可能であり、前記閾数より少ないシェアでアクセス不可能である。
【００２１】
前記第１データの前記デジタル署名の前記シェアの各々は、複数の前記第２参加者の間でJRSS（joint  random  secret  sharing）を用いて共有される複数の第２シークレット値のシェアを含んでよい。
【００２２】
前記第１データの前記デジタル署名の前記シェアの各々は、複数の前記第２参加者の間でJZSS（joint  zero  secret  sharing）を用いて共有される少なくとも１つの第３マスキングシェアを含んでよい。
【００２３】
第２データはメッセージであってよい。
【００２４】
第２データは、メッセージのハッシュ値であってよい。
【００２５】
第１データはブロックチェーントランザクションであってよい。
【００２６】
少なくとも１つのデジタル署名は、同型の特性（homomorphic  property）を有する暗号システムに基づいてよい。
【００２７】
少なくとも１つの前記デジタル署名は、楕円曲線暗号システムに基づいてよい。
【００２８】
本発明は、プロセッサと、プロセッサによる実行の結果として、システムに本願明細書に記載のコンピュータにより実施される方法のいずれかの実施形態を実行させる実行可能命令を含むメモリと、を含むシステムも提供する。
【００２９】
本発明は、実行可能命令を記憶した非一時的コンピュータ可読記憶媒体であって、前記実行可能命令は、コンピュータシステムのプロセッサにより実行された結果として、少なくとも、前記コンピュータシステムに、本願明細書に記載のコンピュータにより実施される方法を実行させる、非一時的コンピュータ可読記憶媒体も提供する。
【００３０】
本発明の上述の及び他の態様は、本願明細書に記載の実施形態から明らかであり、及びそれを参照して教示される。本発明の実施形態は、単なる例を用いて及び添付の図面を参照して以下に説明される。
【図面の簡単な説明】
【００３１】
【図１】本発明を実施するブラインド署名配信システム概略表現である。
【図２】種々の実施形態が実装できるコンピューティング環境を示す概略図である。
【発明を実施するための形態】
【００３２】
本願では、Bitcoinと完全に互換性のある、閾に基づくディーラー不要ブラインド署名配信システムが記載される。システムは、Bitcoinウォレット内で展開される伝統的な個々の署名システムと離れたグループ署名方式に基づき構築され、メッセージの分散型閾値ブラインド署名を可能にするよう設計される新しいシステムを追加する。展開されるとき、システムは、拡張可能且つ堅牢であり、エラー及び悪意ある敵に耐え得る。システムは、ディーラー及びディーラー不要システムの両方、及び配信の無限の柔軟性における展開をサポート可能である。
【００３３】
ブラインド署名方式は、メッセージの内容を知ること無く、メッセージの署名を可能にする。Bitcoinでは、これは、どのアドレス又は鍵により彼らが信頼されるかを知ること無く、Bitcoin秘密鍵の保管人として動作する能力を含む。
【００３４】
文書が閾数の参加者により、しかし閾数より少なくない参加者により有効にデジタル署名できる閾値署名方式と結合されると、これは、Bitcoin秘密鍵の保有者に、維持されている額を知ること無くアドレスを管理するパーティによりメッセージを署名可能な信頼システムを生成することを可能にする。したがって、第２参加者であるAlice、つまりBitcoinの額の所有者は、第１参加者であるBobを使って、AliceがBitcoinをどれくらい制御するかをBobが知ることを許可しない方法で、彼女の鍵を格納することができる。Aliceは、どれだけ多くのBitcoinをAliceが保持し制御するかを（又はBitcoinのアドレスに関することについて）Bobが発見することなく、見えない（blinded）アドレスにより多くを送信できる（又は他のパーティから受信できる）。
【００３５】
閾値システムと結合されると、以下を有しないで、Aliceは幾つかのパーティに強調して動作させることができる。
【００３６】
（１）他のブラインドパーティのアイデンティティを知ること、
（２）パーティがもはや利用可能で無かったとしても、複数のシステムに渡る彼女のBitcoinを、彼女が彼女の資金にアクセスできる方法で保証する。
【００３７】
閾値ブラインド鍵は、ブラインド署名の使用を含む署名付きメッセージをもたらすので、パーティは、共謀してAliceの資金にアクセスすることができない。たとえ、彼らも、他のパーティのアイデンティティにアクセスして、メッセージにブラインド署名することができるために十分な閾数のシェアを取得したとしても、このメッセージは、標準的なECDSA  Bitcoin署名付きトランザクションの中にブラインドされていないときにのみ有効であるからである。
【００３８】
閾値ブラインド技術は、基本システムのセキュリティに、導入可能なランダム性を追加したアドレスも追加し、欠陥のあるＲＮＧ（Random  Number  Generator）から保護するのに役立つ。ブラインド署名パーティは、鍵保管人又は供託（エスクロー、escrow）として動作できる。これは、損失の場合に又は認定及び制御の第２層を追加するために、１次鍵に対するバックアップになり得る。幾つかのシステムまたはオペレータの使用は、幾つかの独立パーティが信頼保護として使用されるとき、冗長性が追加されセキュリティが追加されたＲＡＩＤのような鍵管理システムを可能にする。
【００３９】
Bitcoinの既存の実装では、支払者のウォレットは、損失し、損傷し、又は盗まれることがあり得る。したがって、資金は、損失し又は復元できなくなる。ハードウェア暗号通貨ウォレットは、犠牲になり又は損失し得る。本願明細書に記載のシステムでは、ハードウェアシステムは、複数の部分に分けることができ、ハードウェア装置はセキュアに移動され再生成できる。本願では、以下の記号が使用される。
【表１】
2021510954.tif 000003
標準的なECDSA値は以下を適用する。
【００４０】
w=s−１  mod  n
u１=e.w  mod  n
u２=r.w  mod  n
x=u１G+u２DA
全ての標準的なECDSAルールは以下を適用する。線形変換を構成することが可能であり、したがって、s=x.e+b
この関係は、署名されるべきメッセージをブラインドする際に使用される。第２参加者（Alice）は、使用されるべきメッセージの代わりに、ブラインドメッセージに署名でき、メッセージを維持し及びブラインドメッセージハッシュを単に送信する。
【００４１】
（１）Aliceは、メッセージのブラインドハッシュを、第１参加者であるBobへ送信する。
【００４２】
（２）Bobは、「ブラインドハッシュ」に署名し、署名付き値をAliceへ返す。
【００４３】
（３）Aliceは、Bobの値を「アンブラインド処理し（un−blinds）」、署名を取得する。これは、有効なBitcoinトランザクションを再構成するために使用できる。
【００４４】
閾値ブラインドは、以下により拡張可能に達成できる。
【００４５】
（１）Aliceの鍵が分割される、
（２）Bobの値が分割される、
（３）Bob及びAliceの両者の鍵が分割される、
（４）ブラインドのための値ではなく、Alice及びBobの鍵全体が分割される。
【００４６】
Aliceが範囲[１,(n−１)]の中で値αを選択するとする。次に以下を計算する。
【００４７】
β=hash(α+１)
γ=hash(α+β)
δ=hash(α+γ)
βが閾値である場合、AliceはＴｕ個のパーティのグループであると考えられ、A１〜ATvは、Aiと表記される特定のインスタンスを有するAliceのスライスまたは閾値バージョンである。ここで、αは、以下の詳述するアルゴリズム＃１を用いて選択される。
【００４８】
事前作業
シャミア秘密共有方式（Shamir  Secret  Sharing  Scheme：SSSS）
シャミア（１９７９）は、最初に、鍵の分散型管理を可能にするディーラーに基づくシークレット共有方式を導入した。この方式に関連する問題は、検証できないディーラーを信用する必要から生じる。この形式の方式は、本願に開示するシステムと完全に互換性があり、ここに示す処理を通じて生成される個別鍵スライスのグループ配信のために使用できる。
【００４９】
共同ランダム秘密共有（Joint  Random  Secret  Sharing：JRSS、Pedersen,１９９２）
この手順の明記された目的は、任意の参加者がシークレットを知ること無く、参加者グループが共同でシークレットを共有する方法を生成することである。各参加者は、ランダム値を彼らのローカルシークレットとして選択し、グループによりSSSSを用いて導出された値を配信する。各参加者は、次に、自身のものを含む参加者からの全てのシェアを加算する。この和は、共同ランダムシークレットシェアである。単一の誠実な参加者により提供されるランダム性は、結合されたシークレット値の信頼性を維持するのに十分である。この状態は、(n−１)人の他の参加者全員が意図的に非ランダムシークレット値を選択した場合でも、真である。
【００５０】
共同ゼロ秘密共有（Joint  Zero  Secret  Sharing：JZSS、Ben−Or,１９８８）
JZSSはJRSSと同様であるが、各参加者がランダム値の代わりに０を共有することが異なる。この技術を使用して生成されたシェアは、JRSSアルゴリズムの中で任意の可能性のある弱点（weak  point）を除去するのを支援する。
【００５１】
Desmedt[１９８７]は、グループ指向型暗号法の概念を導入した。この処理は、参加者のうちの選択された一部のみがメッセージを解読することを許可される方法で、参加者が人々のグループへメッセージを送信することを可能にした。このシステムでは、メンバーは、送信者が公開鍵を用いてメンバーを知る必要があるかどうかを知らされていて、メンバーから独立に保たれるグループの単一の公開鍵が存在する場合、グループは匿名である。本願に開示するシステムは、両方の方法を統合し、知られている匿名の送信者及び署名者が、グループ内で同時に存在することを可能にする。
【００５２】
ブラインド署名（Blind  Signatures、Chaum,１９８２）
ブラインド署名は、署名者によりメッセージが見られることなく、セキュアな方法で、パーティが、別のパーティのために有効な署名を生成することを可能にする。本システムでは、署名者のみが有効な署名を生成でき、一方で、署名されるべきメッセージの所有者は、彼らのメッセージが変更されていないこと、及び正しく配信されることを保証され、彼らがBitcoin内で使用されるようなシステムにおいて彼らの資金を償還することを可能にする。さらに、システムは、署名の適用されることを要求するパーティ以外のパーティが、ブラインド値及び非ブラインド（unblinded）値と署名ペアとの間の関係を、導出することができないという点で、考えられないものである。
【００５３】
ブラインド署名の閾値システムへの導入は、署名者がBitcoinアドレスに所有権をリンクできないBitcoinプロトコルにおけるメッセージの署名を可能にする。この方法では、署名者は、彼らが保護しているパーティにより保持される資金額又は移転される額を決定できない。この追加のプライバシレベルは、資金を盗むための鍵を保護している閾値グループ内で共謀することがもはや不可能であるので、追加のセキュリティを加える。これは、どのブラインド鍵がどのデポジットに関連付けられるかを知る必要があるので、実行不可能になる。ピアグループでは、閾数のグループメンバが他のメンバーの鍵を保護するよう動作するこのようなシステムが構築され得る。このシナリオでは、預金者（depositor）のグループは、それぞれ、他のメンバーの間で署名機能を分割し得る。その結果、どのメンバーも、グループ内の他者の持ち分を知らない。
【００５４】
このシナリオは、他の形式のメッセージ交換でも使用でき、分散型ピアグループが全てのメンバーのプライバシを保護すると同時に、グループのメンバーに関連する機密情報を開示できない。
【００５５】
＜方法及び実装＞
本発明の実施形態のプロトコルは、秘密鍵の階層的導出に基づく楕円曲線暗号法（  elliptic  curve  cryptography：ECC）を用いて、参加者の間で送信される必要のあるシークレット情報を暗号化できる。この場合、全てのメッセージを、全てのユーザに送信されるべき単一のパケットに揃える（collate）ことが可能であり賢明である。その結果、検証は、必要なときに、侵害された可能性がある又は敵対的参加者に対して行うことができる。
【００５６】
署名生成は、調整参加者p(c)により提案される。デフォルトで、任意の鍵スライスは、調整参加者として動作でき、要件は、プロトコルの個別実装に依存する。使用されるアルゴリズムは、以下に記載され、後の章はそれらの展開に関する詳細を提供する。
【００５７】
＜ディーラー不要ブラインドECDSA閾鍵を生成する＞
本発明の実施形態のシステムでは、第１参加者Alice(i)の所有権グループが定義される。このグループは、第２参加者のグループであるBob(i)グループ又はシステムの能力を用いてブラインド署名されるべき秘密鍵の有利な管理者である。
【００５８】
＜Aliceグループ＞
始めに、アンブラインド処理された（un−blinded）閾値グループAlice(i)は、乱数の形式の第１シークレット値のセットを選択する。
【数１】
2021510954.tif 000004
グループは、閾Tuの中のTv個のメンバーを有し、その結果、AaiはシークレットAaのi番目のメンバーのスライスである。
【００５９】
アルゴリズム１：鍵生成−アルゴリズム１のより詳細なバージョンについては、以下の付録を参照する。
ドメインパラメータ（CURVE,  Cardinality  n,  Generator  G）
インプット：N/A
アウトプット：ブラインド鍵シェア：Aa１,..Aai,Ab１,…Abi,Ac１…Aci,Ad１…Adi.
アルゴリズム１を用いて、Aliceのグループのメンバーは、JRSSのTvのうちのTu閾数交換に従うことができる。ここで、AliceのTv人のメンバーのうちの閾数Tuは、第２シークレット値Aaを生成し又は使用することを要求される。
【００６０】
同様に、JRSS処理は、アルゴリズム１と共に使用され、更なる第２シークレット値AbをAbiと共に、AcをAciと共に、AdをAdiと共に生成する。
【００６１】
値の各々が使用でき、同じ閾グループ(u,v)を用いて生成でき、又は、各値は、分割でき、個別閾値及びメンバーを用いて生成できる。
【００６２】
このシステムでは、種々のシークレットAai,Abi,Aci及びAdiは１回のみ使用される。これらの値が再び使用される必要がある場合、以下の詳述するアルゴリズム２が、JZSSの変形を用いてシークレットを再共有するために使用される。
【００６３】
アルゴリズム２：秘密鍵の更新−アルゴリズム２のより詳細なバージョンについては、以下の付録を参照する。
インプット：参加者Piの、秘密鍵Aa,Ab,Ac,Adのシェアは、それぞれ、Aai,Abi,Aci,Adiとして示される。
アウトプット：参加者Piの、新しい秘密鍵シェア：A’ai,A’bi,A’ci,A’di
理想的な場合には（シェアの１つのセットのみ(Tu,Tv)）、単一のAliceグループのみが存在し、処理は、値としてTvブロードキャストを要求する。
【００６４】
Aai,Abi,Aci,Adiは、それぞれ、単一のブロードキャストメッセージで送信できる。
【００６５】
＜Bobグループ＞
第１参加者のBobグループBob(i)は、署名グループとして定義される。このグループは、(Tu’,Tv’)、又は第１シークレット値(Bp,Bq)を共有し及び使用するために必要な、Tv’人の全員のうちのTu’人のメンバーを有し、Bp及びBqはAliceグループのためのブラインドメッセージを署名するためにBobグループにより使用される再生成されたブラインド値である。
【００６６】
＜アルゴリズム４：Bobグループのブラインド鍵＞
（１）BobグループのメンバーであるBob(i)は、乱数の形式で第２シークレット値のセットを選択する。
【数２】
2021510954.tif 000005
【００６７】
（２）Bobグループは、以下の値を計算する。
BP=(Bp−１.G)
BQ=(Bq.Bp−１.G)
ここで、BPは、本願の添付に更に詳細に記載されるアルゴリズム３の変形を用いて計算される。
【００６８】
（３）マスクシェアを生成する：
JRSSを用いてbai←Zq
JZSSによりbbi,bci←Zq２
【００６９】
（４）ブロードキャスト：
αi=Bpi.bai+bbi  mod  q
βi=G×bai
【００７０】
（５）χ=Interpolate(αi,…,αTv)
[=Bp.ba  mod  q]
ここで、演算Interpolate(αi,…,αTv)は、シェアαiにより参加者の間で共有されるシークレット値の復元を表す。
【００７１】
（６）δ=Exp−Interpolate(βi,…,βTv)
=Gxba
ここで、演算Exp−Interpolate(βi,…,βTv)は、シェアβiにより参加者の間で共有される楕円曲線点シークレット値の復元を表す。
【００７２】
（７）
【数３】
2021510954.tif 000006
これは、点関数であり、私たちは(Bp−１xG)を変更されたアルゴリズム１への入力として使用できる。
【００７３】
（８）Bqi、つまりBqのシェア、及びステップ（７）からの(Bp−１.G)を用いて、Bob(i)の各メンバーは、以下をブロードキャストする：fi=Bqix(Bp−１.G)
【００７４】
（９）
【数４】
2021510954.tif 000007
【００７５】
（１０）２つのEC点、つまりBP及びBQは、第３データの形式でAliceグループへ送信される。シークレット交換は、国際特許出願WO２０１７/１４５０１６に開示されたような例で実装され、信頼性を維持するために使用できる。
【００７６】
＜ブラインド処理されるべき閾値メッセージ＞
次に、Alice(i)グループは、Bob(i)グループからの値を使用して、（５）を用いてブラインド処理されるときに安全に発行可能な値を計算する。
【００７７】
＜アルゴリズム５：Alice（単一グループ）＞
Aliceは、Bob(i)グループの前のブロードキャストから、BP及びBQを知っている。
【００７８】
Aliceは、シークレット値の計算により開始する。AK=(Ac.Aa)−１BP
これは以下のように行われる。
【００７９】
（１）マスクシェアを生成する：JZSSを用いるMai、したがって、JZSSによりMai←Zq２
【００８０】
（２）Alice(i)は以下の値をブロードキャストする：
【数５】
2021510954.tif 000008
【００８１】
（３）Alice(i)グループは、Aμを計算する。
Aμ=Interpolate(Aμ１,…,AμTv)mod  q
=Ac.Aa  mod  q
ここで、Aμ−１=(Ac.Aa)−１
【００８２】
（４）
【数６】
2021510954.tif 000009
次に、Alice(i)グループは、ブラインド処理されたB公開鍵を計算する。
AT=(Ac.AK(x))−１(AbG+BQ+Ad.Ac−１×BP)
ここで、AK(x)は楕円曲線点AKのｘ座標を表す。
【００８３】
BobグループはAT又はAKを知らず、彼の値又は努力のいずれもAT及び関連するBitcoinアドレスへ及びそれからの資金の任意の移動に関与せず、Aa,Ab,Ac,及びAdを発見しない。Aliceグループがこれらをセキュアな閾値として維持する場合、Bob又は任意の他のパーティは、Aliceの詳細を決して知ることができない。
【００８４】
Aliceは、Bitcoinアドレスの標準的な生成において、公開鍵ATを使用し、Bobがトランザクションに署名するのを助ける際に役立った場合でも、Bob(i)に彼女のアドレスを決定させる能力を更に弱める。
【００８５】
＜アルゴリズム６：Aliceは公開鍵を計算する＞
（１）マスクシェアを生成する：JRSSを用いて、bai←Zq
（２）マスクシェアを生成する：JZSSにより、Mbi,Mci←Zq２.
（３）以下を計算する：
【数７】
2021510954.tif 000010
Aμiを全てのAlice(i)メンバーにブロードキャストする。
（ここで、AK(x)は点AKのｘ座標を表す。）
（４）アルゴリズム１を用いて、(Ab.G)を計算する。
ここで、Afi=G×Abi
Afiを全てのAlice(i)メンバーにブロードキャストする。
【数８】
2021510954.tif 000011
（５）[Aa.AK(x)]−１を計算する。
最初にAμを取り入れる。
ここで、
【数９】
2021510954.tif 000012
したがって、これは、後に[AaAK(x)]−１を計算するために使用できる。
（６）値(Ac−１.BP)は、アルゴリズム４で使用されたのと同じ方法を用いて先ず計算される。
（７）これは、値(Ad.Ac−１.BP)を計算するために使用される。
（８）マスクシェアを生成する：
JRSSを用いて、Mdi←Zq
JZSSを用いて、Mei,Mfi←Zq２
（９）Alice(i)グループに値をブロードキャストする。
αi=Aci.Mdi+Mei  mod  q
βi=BP×Mdi
（１０）
【数１０】
2021510954.tif 000013
（１１）
【数１１】
2021510954.tif 000014
（１２）
【数１２】
2021510954.tif 000015
曲線上の点BPとして、Ac−１.BPを返す。これはｍアルゴリズム１への入力として使用される。
（１３）Adi及びEC点(Ac−１.BP)を用いて、Alice(i)の各メンバーがブロードキャストする：
fi=Adi×(Ac−１BP)
（１４）
【数１３】
2021510954.tif 000016
（１５）ここで、部分の全てが、公開鍵ATを計算するために存在する。これは、以下の式を用いて計算される。
AT=(Aa.AK(x))−１.(Ab.G+BQ+Ad.Ac−１BP)
=Aa−１AK(x)−１(Ab+BqBp−１+AdAc−１Bp−１)G  (１)
つまり：
アルゴリズム(５.４)x[(６.４)+BQ+(６.１４)]、これは、ブラインド処理された公開鍵として機能するEC点ATを返す。
【００８６】
＜Bitcoinアドレスを生成する＞
この公開鍵は、標準的な方法で変換されて、Bitcoinアドレスを生成する。
AT=AT(x,y)
（１）AT(y)のパリティ及び完全なAT(x)座標を用いて、公開鍵を表す。
（２）公開鍵を２回ハッシュする。
（a）SHA２５６を用いる。
（b）RIPEMD１６０を用いる。
（３）バージョン（これは、Bitcoinアドレスバージョン番号である）番号を先頭に追加する。プロトコルが標準である場合、バージョン０１が使用される。Ｐ２ＳＨが使用される場合、これをバージョン０３にすることも可能である。
（４）（３）からのバージョンを追加された公開鍵ハッシュの末尾にチェックサムを付加する。チェックサムは、（３）から返された値のダブルSHA２５６ハッシュの最初の４バイトである。
（５）BASE５８が（４）で生成された値を符号化する。これは、標準的なフォーマットのBitcoinアドレスであり、Alice(i)グループは、このアドレスへの支払いを受信してよく、このアドレスはこの時点で任意の通常のｂBitcoinアドレスのように表示する。
Bobを含むどのパーティも、Aliceが値Aa,Ab,Ac及びAdを漏らさない限り、誰がATのアドレスを所有するかが分からない。
【００８７】
これらが漏洩した場合でも、Alice(i)は、これらの値がBob(i)署名グループに関連することを他者に知らせる必要がない。Aliceが粗悪なRNGを有する場合、Bob(i)が手順にランダム性を導入できるので、彼女は安全なままである。
【００８８】
＜閾値グループの中のブラインド署名＞
Bitcoinを使用する要件であるメッセージに署名するために、又は（匿名のホスト上にある電子メールメッセージのような）任意の他のメッセージに署名するために、Alice(i)グループは、メッセージ又はトランザクションのハッシュe=h(m)を有する必要がある。メッセージ（又はトランザクション）及び署名付きハッシュにより、Alice(i)は、メッセージ（トランザクション）を再構成し、Bitcoin公開鍵AT及び関連するBitcoin基本５８アドレスから資金を償還（redeem）できる。
【００８９】
アルゴリズム３：鍵生成−アルゴリズム３のより詳細なバージョンについては、以下の付録を参照する。
ドメインパラメータ（CURVE,  Cardinality  n,  Generator  G）
インプット：署名されるべきメッセージ→e=H(m)
秘密鍵シェア→dA(i)∈Zn*
アウトプット：署名→e=H(m)について、(r,s)∈Zn*
Aliceは、Bob(i)にメッセージ（トランザクション）の内容を知らせないことにより、プライバシを維持する。したがって、Bob(i)は、彼がATに関連するメッセージに署名していることが分からず、Alice(i)はハッシュ値をブラインド処理する。
【００９０】
＜アルゴリズム７：ハッシュ値をブラインド処理する＞
Aliceは、ハッシュされたメッセージ（トランザクション）eである第２データのブラインド処理されたバージョンの形式で第１データを生成する。
【００９１】
ここで、e２=Aa.e+Ab(mod  q).これは以下のように生成される。
（１）Alice(i)は、マスクシェアを生成することにより開始する：JZSSを用いてMai←Zq
（２）Alice(i)は、値を送信する：Av(i)=Aa(i)e+Ab(i)+Ma(i)  mod  q
Alice(i)は、値Av(i)を、この値セットを挿入できるAliceの他のメンバーに送信する。
（３）e２=Interpolate(Av１,…,Avv)=Aa.e+Ab  mod  q
（４）e２はBob(i)グループにブロードキャストされる。これは、BobがAliceのアイデンティティを検証する場合に暗号化チャネルを用いて行われる。これは、例えば国際特許出願WO２０１７/１４５０１６に開示されるような構成を用いて達成できる。ここで、Aliceは、署名のためにBobに支払い、閉じられた暗号化されたセッションチャネルを介して交換する。
【００９２】
Bobが非Aliceパーティからメッセージを受信し、これに署名した場合、値は、アンブラインド処理できず、したがって安全なままである。Bobが支払い及び記録を有する場合でも、値e２はブラインド処理され、AliceはBobにブラインド処理されたハッシュのみを送信し、メッセージを送信しなかったので、彼は、署名されたAliceのトランザクションに関する情報を有しない。
【００９３】
Bobグループは、ブラインド処理されたハッシュに署名し、これを、つまり第１データのデジタル署名を、Aliceに返す。
【００９４】
Bob(i)は、メッセージs１=Bp.e２+Bq  mod  qを生成する。
【００９５】
s１はAliceに返され、署名のブラインド処理されたバージョンである。
【００９６】
これを行うために、Bob(i)はアルゴリズム８を用いて、彼の閾値グループから署名し、s１をAlice(i)に返す。
【００９７】
＜アルゴリズム８＞
s１=Bp.e２+Bq  mod  q
（１）Bob(i)は、JZSSを用いてマスクシェアを生成する。
JZSSにより、Mb(i)←Zq２
（２）Bob(i)はBsi=Bp(i).e２+Bq(i)+Mb(i)  mod  qをブロードキャストする。
（３）
【数１４】
2021510954.tif 000017
（４）Bob(i)は、s１、ブラインド処理されたs１署名値をAlice(i)へ送信する。
【００９８】
Aliceは、署名のブラインド処理されたs１部分及び(AK(x))であるr部分を有する。
【００９９】
Alice(i)は、アルゴリズム９を用いてブラインド処理されたs１値からの、s署名値、つまり第２データのデジタル署名を復元するために、閾値アンブラインド方法を使用できる。
【０１００】
＜アルゴリズム９＞
Alice(i)は、s１ブラインド処理された部分から、アンブラインド処理されたs署名成分を得たいと望む。彼女は、s=Ac.s１+Ad(mod  q)を計算することによりこれを行う。
【０１０１】
これを行うために、彼女は、以下を行う：
（１）JZSSを用いてハッシュシェアを生成する。
JZSSにより、Ma(i)←Zq２
（２）Alice(i)は以下をブロードキャストする：
si=Ac(i)s１+Ad(i)+Ma(i)
全ての他のAliceメンバーに。
（３）
【数１５】
2021510954.tif 000018
Alice(i)グループ内の各パーティは、有効なECDSA署名であり、通常、公開鍵AT又は関連するBitcoinアドレスを用いるBitcoinプロトコルの中で検証可能な(AK(x),s)を有する。
【０１０２】
Sは、以下のように、eの有効なECDSA署名であることが示される。
sを展開する：
s=Acs１+Ad=Ac(Bpe２+Bq)+Ad
=AcBp(Aae+Ab)+AcBq+Ad=AcBpAae+AcBpAb+AcBq+Ad
=(AcBpAa)(e+Aa−１[Ab+BqBp−１+AdAc−１Bp−１)
しかし、上述の式１から、公開鍵ATに対応する秘密鍵dAは、
Aa−１AK(x)−１(Ab+BqBp−１+AdAc−１Bp−１)
これから、以下の通りである。
s=(AcBpAa)[e+AK(x)dA]=k−１[e+AK(x)dA]、ここで、k=(AcBpAa)−１、これから、sがeの有効なECDSA署名であり公開鍵ATにより検証されることが分かる。
【０１０３】
メッセージによるこの署名は、標準的なBitcoinトランザクションを形成することができ、ここで、Alice(i)は該トランザクションがBitcoinネットワークにブロードキャストされた場合に資金を償還できる。
【０１０４】
Bob(i)は、Aliceの有するどのアドレスが使用されたかに関する情報を有しない。
【０１０５】
彼は、Bitcoinアドレスも、トランザクションの額も、それがどこに送られているかも、分からない。
【０１０６】
Bob(i)が鍵を保持し保護している場合でも、彼は、トランザクションの知識を有しない。
【０１０７】
＜セキュリティの検討＞
Bengeret.al.(２０１４)は、Flash及びリロード方法を用いてECDSA秘密鍵復元の一例を提案した。これは、しかし、システムRAM及びCacheに対する攻撃の一例である。これらの方法は、秘密鍵を再構成するとき、シャミアのSSS[１９７９]のような手順の使用を望む。さらに、秘密鍵が再構成される任意のシナリオでは、信頼の要件が導入される。このシナリオでは、秘密鍵を保持するエンティティのシステム及び処理に依存する必要がある。信頼できるパーティが悪意がない場合でも、彼らの処理に依存する必要がある。多くの最近の侵害から分かるように、秘密鍵を再構成することへのこの依存は、攻撃の道を開く。
【０１０８】
既存のECDSA実装の完全な置き換えであると同時に、現在のBitcoinプロトコルと完全に透過であり互換性があるので、その実装のためにハードフォークまたはソフトフォークは必要なく、実装は、任意の現在のトランザクションと区別されない。本発明は、個人を別個の参加者として扱うことができ、復元機能により鍵のグループ署名を可能にする。一例として、２−ｏｆ−２（two  of  two）方式が、４ｋ所の鍵スライスを用いて実装できる。ここで、オンラインウォレットプロバイダ又は取引所は、２つの鍵スライスを維持し、エンドユーザは２つのスライスを維持する。取引所及びユーザは、それぞれ、彼らの鍵スライスに対して２−ｏｆ−２処理を有し、これは、次に、必要なときにメッセージのセキュアな署名のために互いに組み合わせて使用される。
【０１０９】
本方式では、グループBob(i)は、少なくとも、Alice(i)から提供されたメッセージのハッシュを見ることができる。
【０１１０】
１．Bob(i)のメンバーは、誰も、一緒に又は独立にAa又はAbを知ることができないので、このグループのどのメンバーも、e２がメッセージハッシュのブラインド処理されたバージョンeかどうかを決定できない。
【０１１１】
２．同様に、Bob(i)は、値Ac又はAdが分からないので、署名値sとs１との間の関係を決定できない。
【０１１２】
３．Rabin()署名の計算で使用される同様の方法では、Bob(i)は値AaAcを直ちに決定できない。楕円曲線離散対数問題の仮定の下では、Bob(i)は、AT(x)と楕円曲線点BPとの間の関係を決定できない。
【０１１３】
４．同様の方法で、Bob(i)は、値BP又BQがAlice(i)グループの公開鍵AT(x,y)を構成する際に使用されたか否かに関する知識を得ない。
【０１１４】
５．ここで、アンブラインド処理されたメッセージがAlice(i)によりブロードキャストされると、トランザクションに関連付けられた公開鍵の値は分からないままである。Alice(i)がBob(i)から受信したブラインドメッセージ署名をブロードキャストするのを遅らせた場合、Bitcoinブロック内に多くの他のトランザクションを含めることは、Bob(i)が、Alice(i)が署名付きメッセージを有すること及びそれが受信された後に処理した可能性があることしか決定できないことを意味する。
【０１１５】
６．外部パーティがAlice(i)とBob(i)の間のトランザクションに関する情報を有する必要はなく、したがって、これらのパーティ間のプライバシレベルが向上される。
【０１１６】
この処理の効果的な成果は、グループの全体を表してよく又はそうでなくてもよいAlice(i)の閾値グループが、トランザクション又はメッセージの署名の際に支援できる保護者（Guardian）グループBob(i)へ送信できると同時に、Alice(i)により提供されたメッセージの内容が隠されたままであることである。
【０１１７】
Alice(i)が、メッセージの送信に対してある程度の否定ができる立場のままであり、及び（Bitcoinのような）システム内のメッセージの量がゼロより有意に上のままである限り、Bob(i)は、Alice(i)から来るかも知れないメッセージを決定できない。
【０１１８】
本方式では、Alice(i)が、異なるハッシュ値に署名するとき、パラメータAa&Abを再利用しないことが重要である。これらの値が異なる値eと共に再利用された場合、これは、情報の計算により、Bob(i)が分からなくされた（obscured）ハッシュe２をブロードキャストメッセージの元のハッシュ値eにリンクできるようにする。これは、更に線形方程式を追加すると、Bob(i)がAa&Abの間の関係、従ってメッセージｅを挿入（interpolate）できるというシナリオを生じる。結果として、Bob(i)は、値eをブロックチェーン上で検索し、対応するAlice(i)グループの公開鍵AT(x,y)に、場合によってはこのグループに関連付けられた他の導出した公開鍵にリンクさせることができる。
【０１１９】
同様に、重要なことに、パラメータAc&AdがBob(i)にブラインド処理された署名とAlice(i)により発行された署名との間の関係を計算可能にし、したがって、パラメータAc&Adの再利用と同様の方法でブロックチェーンを検索して彼がAlice(i)グループの公開鍵AT(x,y)を決定することを可能にするので、Alice(i)はパラメータAc&Adを再利用しない。
【０１２０】
同様に、パラメータBp&Bq及びBob(i)により生成されたBP&BQは、再利用されるべきではない。これらが無ければ、Alice(i)は、Bob(i)により生成されたブラインド処理された署名の偽物を生成することができず、したがって、公開鍵AT(x,y)により生成されたように見える署名をアンブラインド処理できない。値Bp&Bqは導出された鍵スキームを用いて、例えば国際特許出願WO２０１７/１４５０１６に開示されたような構成を用いてBob(i)により計算されるので、Bp&Bqの各値は、Alice(i)により生成された各メッセージにユニークであり、衝突のないハッシュアルゴリズムの仮定の下で、サービスを使用する任意のパーティは、決して再利用されない各メッセージについて生成されたBp&Bqの彼ら自身のバージョンを有する。
【０１２１】
本発明は、グループ署名処理の導入により、暗号通貨の求めるものが達成することを拡張する。フォルトトレラントな署名システムを分散型鍵生成システムの結合に追加することは、全ての集中化及び信頼要件を除去する。多くのシステムは、信頼の必要性と共に進化する。さらに、暗黙的に非集中化されたシステムの導入は、より堅牢で回復力のあるプロトコルの生成を可能にする。ECDSA[Johnson,２００１]とシャミアのSSS[Shamir,１９７９]との間の互換性は、新しい検証可能なシークレット共有方式によりBitcoinを拡張するシステムの導入を可能にした。このシステムは、セキュリティにおいて何も失わずに、Feldman[Feldman,１９８７]又はPedersen[Pedersen,１９９２]により導出されるものよりも遙かに効率的である。
【０１２２】
Chaum(１９８２)の研究を拡張する閾値署名ブラインド処理の導入の結果として、信頼できるパーティがウェブに基づく交換においてさえ存在する必要がない。ここで、真の形式の偽名の（pseudonymous）デジタルキャッシュ又はアセット移転システムが維持でき、更に安全なプライベート投票システムへとリンクできる。
【０１２３】
本願では、基本プロトコルの変更を必要とせずに、Bitcoinの機能を拡張するシステムが開示される。本発明のシステムを用いると：
１）鍵シークレットの選択又は配信のために、信頼できる第三者が必要ない。
２）第三者の信頼に依存しない分散型銀行取引システムが生成できる。
３）各メンバー又はメンバーのグループは、保持されているシークレット鍵のシェアがBitcoinアドレス及び広告された公開鍵に対応するかを独立に検証してよい。
４）盗聴及び関連する攻撃の影響を低減するために秘密鍵スライスをリフレッシュするプロトコルが存在する。
５）トランザクション及びメッセージのグループ署名のために、信頼できる第三者が必要ない。
６）第三者は、閾値グループの中で鍵の完全性を維持できる。署名者のこのグループは、どれだけ多くのBitcoin又は他のアセットが彼らの保護下に保持されているかを知らない。これは閾値システムであるので、署名グループのうちの一部のメンバーが利用可能でない場合、依然として、他のメンバーがトランザクションにブラインド署名することが可能であり、資金の移動が保護されることを可能にする。
【０１２４】
本発明のシステムは、メモリに現れない機密データなので、多くの現存するセキュリティリスクを解決した。さらに、取引の分散に基づくシステム、ウェブウォレット、及び他の形式の通商を可能にする。本システムでは、階層的閾値グループは、他の階層的閾値グループと相互作用でき、時間にわたり鍵の完全性を保証する。このシナリオでは、所与のイベントにより資金の移転を可能にするソリューションが生成できる。このようなシナリオは、制御及び保護することの可能な意思（Wills）及び財産の移転を含み、多様なシナリオにおいて鍵の復元を可能にする。
【０１２５】
図２を参照すると、本開示の少なくとも一実施形態を実施するために使用され得るコンピューティング装置２６００の説明のための簡略ブロック図が提供される。種々の実施形態で、コンピューティング装置２６００は、上述の図示のシステムのうちのいずれかを実装するために使用されてよい。例えば、コンピューティング装置２６００は、データサーバ、ウェブサーバ、ポータブルコンピューティング装置、パーソナルコンピュータ、又は任意の電子コンピューティング装置として使用するために構成されてよい。図２に示すように、コンピューティング装置２６００は、主メモリ２６０８及び永久記憶装置２６１０を含む記憶サブシステム２６０６と通信するよう構成され得る１つ以上のレベルのキャッシュメモリ及びメモリ制御部（集合的に２６０２とラベル付けされる）を備える１つ以上のプロセッサを含んでよい。主メモリ２６０８は、図示のように、動的ランダムアクセスメモリ（ＤＲＡＭ）２６１８及び読み出し専用メモリ（ＲＯＭ）２６２０を含み得る。記憶サブシステム２６０６及びキャッシュメモリ２６０２は、本開示で説明されたようなトランザクション及びブロックに関連付けられた詳細事項のような情報の記憶のために使用されてよい。プロセッサ２６０２は、本開示で説明されたような任意の実施形態のステップ又は機能を提供するために利用されてよい。
【０１２６】
プロセッサ２６０２は、１つ以上のユーザインタフェース入力装置２６１２、１つ以上のユーザインタフェース出力装置２６１４、及びネットワークインタフェースサブシステム２６１６とも通信できる。
【０１２７】
バスサブシステム２６０４は、コンピューティング装置２６００の種々のコンポーネント及びサブシステムが意図した通りに互いに通信できるようにするメカニズムを提供してよい。バスサブシステム２６０４は、単一のバスとして概略的に示されるが、バスサブシステムの代替の実施形態は、複数のバスを利用してよい。
【０１２８】
ネットワークインタフェースサブシステム２６１６は、他のコンピューティング装置及びネットワークへのインタフェースを提供してよい。ネットワークインタフェースサブシステム２６１６は、幾つかの実施形態では、コンピューティング装置２６００の他のシステムからデータを受信し及びそれへデータを送信するインタフェースとして機能してよい。例えば、ネットワークインタフェースサブシステム２６１６は、データ技術者が、装置をネットワークに接続することを可能にする。その結果、データ技術者は、データセンタのような遠隔地にいがなら、データを装置へ送信し、データを装置から受信できる。
【０１２９】
ユーザインタフェース入力装置２６１２は、キーボード、統合型マウス、トラックボール、タッチパッド、又はグラフィックタブレットのような指示装置、スキャナ、バーコードスキャナ、ディスプレイに組み込まれたタッチスクリーン、音声認識システム、マイクロフォンのようなオーディオ入力装置、及び他の種類の入力装置のような、１つ以上のユーザ入力装置を含んでよい。通常、用語「入力装置」の使用は、コンピューティング装置２６００に情報を入力する全ての可能な種類の装置及びメカニズムを含むことを意図する。
【０１３０】
１つ以上のユーザインタフェース出力装置２６１４は、ディスプレイシステム、プリンタ、又はオーディオ出力装置のような非視覚的ディスプレイ、等を含んでよい。ディスプレイサブシステムは、陰極線管（CRT）、液晶ディスプレイ（LCD）、発光ダイオード（LED）ディスプレイ、又はプロジェクションのような平面装置、又は他のディスプレイ装置を含んでよい。通常、用語「出力装置」の使用は、コンピューティング装置２６００から情報を出力する全ての可能な種類の装置及びメカニズムを含むことを意図する。１つ以上のユーザインタフェース出力装置２６１４は、例えば、ユーザインタフェースを提示して、ここに記載したプロセス及び変形を実行するアプリケーションとのユーザ相互作用が適切であるとき、そのような相互作用を実現するために使用されてよい。
【０１３１】
記憶サブシステム２６０６は、本開示の少なくとも１つの実施形態の機能を提供する基本プログラミング及びデータ構造を記憶するコンピュータ可読記憶媒体を提供してよい。アプリケーション（例えば、プログラム、コードモジュール、命令）は、１つ以上のプロセッサにより実行されると、本開示の１つ以上の実施形態の機能を提供し、記憶サブシステム２６０６に格納されてよい。これらのアプリケーションモジュール又は命令は、１つ以上のプロセッサ２６０２により実行されてよい。記憶サブシステム２６０６は、更に、本開示に従い使用されるデータを格納するレポジトリを提供する。例えば、主メモリ２６０８及びキャッシュメモリ２６０２は、プログラム及びデータのための揮発性記憶を提供できる。永久記憶装置２６１０は、プログラム及びデータの永久（不揮発性）記憶を提供でき、磁気ハードディスクドライブ、取り外し可能媒体に関連付けられた１つ以上のフロッピディスクドライブ、取り外し可能媒体に関連付けられた１つ以上の光ドライブ（例えば、ＣＤ−ＲＯＭ、又はＤＶＤ、又はＢｌｕｅ−Ｒａｙ）ドライブ、及び他の同様の記憶媒体を含んでよい。このようなプログラム及びデータは、本開示に記載した１つ以上の実施形態のステップを実行するためのプログラム、及び本開示に記載したトランザクション及びブロックに関連付けられたデータを含み得る。
【０１３２】
コンピューティング装置２６００は、ポータブルコンピュータ装置、タブレットコンピュータ、ワークステーション、又は後述する任意の他の装置を含む種々のタイプのものであってよい。さらに、コンピューティング装置２６００は、１つ以上のポート（例えば、USB、ヘッドフォンジャック、光コネクタ、等）を通じてコンピューティング装置２６００に接続可能な別の装置を含み得る。コンピューティング装置２６００に接続され得る装置は、光ファイバコネクタを受けるよう構成される複数のポートを含んでよい。したがって、この装置は、光信号を、処理のために装置を接続するポートを通じてコンピューティング装置２６００に送信される電気信号に変換するよう構成されてよい。コンピュータ及びネットワークの絶えず変化する特性により、図２に示したコンピューティング装置２６００の説明は、装置の好適な実施形態を説明する目的の特定の例としてのみ意図される。図２に示したシステムより多くの又は少ないコンポーネントを有する多くの他の構成が可能である。
【０１３３】
上述の実施形態は、本発明を限定するのではなく、説明すること、及び当業者は添付の特許請求の範囲により定められる本発明の範囲から逸脱することなく多くの代替的実施形態を考案できることに留意すべきである。特許請求の範囲において、括弧内の任意の参照符号は、請求項を限定することを意図しない。用語「有する」及び「含む」（comprising、comprises）等は、任意の請求項又は明細書全体に列挙されたもの以外の要素またはステップの存在を排除しない。本願明細書では、「有する」は「有する又は構成される」を意味し、「含む」は「含む又は構成される」を意味する。要素の単数の参照は、該要素の複数の参照を排除しない。逆も同様である。本発明は、幾つかの別個の要素を含むハードウェアにより、及び適切にプログラムされたコンピュータにより、実装できる。幾つかの手段を列挙する装置クレームでは、これらの手段のうちの幾つかは、１つの同じハードウェアアイテムにより具現化されてよい。単に特定の手段が相互に異なる従属請求項に記載されるという事実は、これらの手段の組み合わせが有利に使用されないことを示さない。
【０１３４】
＜付録＞
アルゴリズム１：鍵生成
ドメインパラメータ（CURVE,  Cardinality  n,  Generator  G）
インプット：N/A
アウトプット：ブラインド鍵シェア（Blinding  Key  Shares）αA(１),αA(２),…,αA(i),…,αA(m)
（m）人の参加者からのl個のスライスの閾値について、参加者(i)及び参加者(i)がブラインド鍵に署名するためにシークレットを交換する他のパーティである参加者(h)として指名された(m−１)人の参加者に関連付けられたブラインド鍵セグメントαA(i)iが構成される。
【０１３５】
・本方式では、mは参加者の合計人数であり、１≦m、したがって、i=m−１である。
【０１３６】
・したがって、(l+１,m)閾値共有方式が存在する。
【０１３７】
アルゴリズム１の方法は以下の通りである。
【０１３８】
（１）(j)の各参加者p(i)は、ECC公開鍵（又はこの実装ではBitcoinアドレス）を全ての他の参加者と交換し、ここで１≦i≦jである。このアドレスは、グループアイデンティティアドレスであり、任意の他の目的で使用される必要がない。
【０１３９】
留意すべきことに、これは、例えば国際特許出願WO２０１７/１４５０１６に開示されるように導出されたアドレス、及び該出願に開示された処理から参加者の各々の間の共有された値に基づく鍵である。
【０１４０】
（２）各参加者p(i)は、全ての他のパーティから秘密である方法で、ランダムな係数を有する次数（k−１）の多項式fi(x)を選択する。
【０１４１】
この関数は、多項式の自由項として選択された参加者のシークレットa０(i)の影響を受ける。この値は共有されない。この値は、導出された秘密鍵を用いて計算される。
【０１４２】
fi(h)は、点（x=h）における値について参加者p(i)により選択された関数f(x)の結果であると定義され、参加者p(i)の基本方程式は、関数：f(x)=Σp=０(k−１)apxpとして定義される。
【０１４３】
この式で、a０(i)は各参加者p(i)のシークレットであり、共有されない。
【０１４４】
したがって、各参加者p(i)は、該参加者のシークレットとして定義される自由項a０(i)を有する次数（k−１）の多項式として表される秘密に保たれた以下の関数fi(x)を有する。
【０１４５】
fi(x)=Σγ=０(k−１)aγxγmod  n
（３）各参加者p(i)は、参加者P(h)∀h={１,…,(i−１),(i+１),…,j}へのfi(h)tを、上述のようにP(h)の公開鍵１を用いて暗号化し、復号するためにP(h)の値を交換する。
【０１４６】
留意すべきことに、任意の基本点Gについて、次式であることに留意する。
【数１６】
2021510954.tif 000019
したがって、(b,b１,b２,…)として表すことのできる整数の任意の集合B:{bi∈Zn}について、bG=[b１G+b２G+…]mod  pならば、b=[b１+b２+…]mod  nである。さらに、bG=[b１b２…]mod  pならば、b=[b１b２…]mod  nである。
【０１４７】
Znがフィールド（field）であり、ECC秘密鍵として選択された値に対してnを法としてラグランジュ補間を有効に実行できる場合、シャミアのシークレット共有方式SSSS（Shamir’s  Secret  Sharing  Scheme）[５]がZnに対して実施できるという結論に至る条件が存在する。
【０１４８】
（４）各参加者P(i)は、全ての参加者に以下の値をブロードキャストする。
【０１４９】
（a）aK(i)G∀k={０,…,(k−１)}
（b）fi(h)G∀h={１,…,j}
上式の変数hに関連付けられた値は、参加者P(h)の位置であり得る。その結果、参加者P(h)が方式の中で第３参加者を表す場合、h=３又は等価に、参加者により使用されるECC公開鍵の値を整数として表してよい。いずれの実装についても使用例及びシナリオが存在する。後者の実装では、値h={１,…,j}は、個々の参加者の利用した公開鍵にマッピングされた値の配列により置き換えられ得る。
【０１５０】
（５）各参加者P(h≠i)は、各他の参加者からものにより、受信したシェアの一貫性を検証する。つまり：
ΣK=０(k−１)hkak(i)G=fi(h)G
そして、fi(h)Gは、参加者のシェアと一致する。
【０１５１】
（６）各参加者P(h≠i)は、該参加者（P(h≠i)）により所有され及び受信されたシェアが他の受信されたシェアと一致するかを検証する。
【０１５２】
a０(i)G=Σh∈Bβjfi(h)G∀P(h≠i)
これが一致しない場合、参加者はプロトコルを拒否し、再び開始する。
【０１５３】
（７）参加者p(i)は彼らのシェアdA(i)を次のように計算する。
【０１５４】
SHARE(p(i))=dA(i)=Σh=１jfh(i)mod  n
ここで、SHARE(p(i))∈Zn及びdA(j)
及び
ここで、
【数１７】
2021510954.tif 000020
戻り値：(dA(i),QA)
参加者p(i)は、署名を計算する際にシェアを使用する。この役割は、任意の参加者により又はパーティp(c)により、行うことができる。参加者p(c)は、変化し、トランザクションに署名するために十分なシェアを集めようとする度に同じパーティである必要はない。
【０１５５】
したがって、秘密鍵シェアdA(i)←Zn*は、他の参加者を知らずに、生成される。
【０１５６】
アルゴリズム２：秘密鍵を更新する
インプット：秘密鍵dAの参加者PiのシェアdA(i)
アウトプット：参加者Piの、新しい秘密鍵シェアdA(i)‘
アルゴリズム２は、秘密鍵を更新するため、及びプロトコルにランダム性を追加するために使用できる。
【０１５７】
再構成又は計算された秘密鍵の存在を有しないで、階層的サブ鍵の再計算を実行することができる。このように、正しく展開されると、過去に生じた任意の大規模な詐欺行為又はデータベース盗難を除去する、Bitcoinアドレス及び秘密鍵スライスの階層構造を構成することが可能である。
【０１５８】
（１）各参加者は、ゼロを自由項とする次数（k−１）のランダム多項式を選択する。これは、アルゴリズム１と類似するが、参加者は全ての他の参加者の選択されたシークレットがゼロであることを検証しなければならない。
【０１５９】
以下に留意すべきである。
【数１８】
2021510954.tif 000021
ここで、楕円曲線上の無限遠における点である。
【０１６０】
この式を用いて、全てのアクティブな参加者は以下の関数を検証する。
【数１９】
2021510954.tif 000022
類推についてはFeldman(１９８７)を参照する。
【０１６１】
ゼロシェアを生成する：zi←Zn*
（２）dA(i)’=dA(i)+zi
（３）戻り値：dA(i)’
このアルゴリズムの結果は、元の秘密鍵と関連付けられた新しい鍵シェアである。このアルゴリズムの変形は、第１アルゴリズムのランダム性を増大し、又はBitcoinアドレスを変更する必要無しに新しい鍵スライスを生じる再共有運動（exercise）に従事する両方の能力を可能にする。このように、本発明のプロトコルは、参加者が、基本的な秘密鍵を変更することなく、秘密鍵シェアを追加的にマスクすることを可能にする。この処理は、基本Bitcoinアドレス及び秘密鍵を変更することなく、個々の鍵シェアの連続した使用及び展開に関連付けられた任意の起こり得る鍵漏洩を最小限に抑えるために使用できる。
【０１６２】
アルゴリズム３：署名生成
ドメインパラメータ（CURVE,  Cardinality  n,  Generator  G）
インプット：署名されるべきメッセージ：e=H(m)
秘密鍵シェア：dA(i)∈Zn*
アウトプット：署名：e=H(m)について、(r,s)∈Zn*
A)    分散型鍵生成
（１）アルゴリズム１を用いて短命な鍵シェアを生成する：
Dk(i)←Zn*
（２）アルゴリズム１を用いてマスクシェアを生成する：
αi←Zn
（３）アルゴリズム２を用いてマスクシェアを生成する：
βi,ci←Zn２
署名生成
（４）e=H(m)：メッセージmのハッシュを検証する。
【０１６３】
（５）以下をブロードキャストする：
【数２０】
2021510954.tif 000023
及び
ωi=G×αi
（６）
【数２１】
2021510954.tif 000024
（７）
【数２２】
2021510954.tif 000025
（８）(Rx,Ry)を計算し、ここで、
【数２３】
2021510954.tif 000026
（９）r=rx=Rx  mod  n
r=０ならば、再開する（つまり、初期配信から）。
【０１６４】
（１０）Si=Dk(i)(e+DA(i)r)+Ci  mod  nをブロードキャストする。
【０１６５】
（１１）S=Interpolate(si,…,sn)  mod  n
s=０ならば、始め(A.１)からアルゴリズム３をやり直す。
【０１６６】
（１２）(r,s)を返す。
【０１６７】
（１３）Bitcoinでは、(r,s)ペアを有するトランザクションを再構成して、標準的なトランザクションを形成する。
【０１６８】
参考文献
1)  Bar−Ilan,  J.  Beaver,  "Non−Cryptographic  Fault−Tolerant  Computing  in  a  Constant  Number  of  Rounds",  Proc.  of  8th  PODC,  pp.  201−209,  1989.
2)  Berlekamp,  Elwyn  R.  (1968),  Algebraic  Coding  Theory,  McGraw-Hill,  New  York,  NY.
3)  Benger,  N.,  van  de  Pol,  J.,  Smart,  N.P.,  Yarom,  Y.:  "Ooh  Aah...  Just  a  Little  Bit":  A  Small  Amount  of  Side  Channel  Can  Go  a  Long  Way.  In:  Batina,  L.,  Robshaw,  M.  (eds.)  Cryptographic  Hardware  and  Embedded  Systems  |  CHES  2014,  LNCS,  vol.  8731,  pp.  75−92.  Springer  (2014)
4)  Ben−Or,  M.,  Goldwasser,  S.,  Wigderson,  A.:  “Completeness  theorems  for  noncryptographic  fault−tolerant  distributed  computation”.  In:  Proceedings  of  the  Twentieth  Annual  ACM  Symposium  on  Theory  of  Computing.  pp.  1-10.  STOC  ’88,  ACM,  New  York,  NY,  USA  (1988)
5)  BIP  65  OP_CHECKLOCKTIMEVERIFY  https://github.com/bitcoin/bips/blob/master/bip−0065.mediawiki
6)  Chaum,  David  (1983).  "Blind  signatures  for  untraceable  payments"  (PDF).  Advances  in  Cryptology  Proceedings  of  Crypto.  82  (3):  199-203.
7)  Chen  T.S.  Huang  G.S.  Liu  T.P.  and  Chung  Y.F  (2002),  ‘Digital  Signature  Scheme  Resulted  from  Identification  Protocol  for  Elliptic  Curve  Cryptosystem’,  Proceedings  of  IEEE  TENCON’02.  pp.  192−195
8)  Chinnici  M.  (1995),  ‘CUDA  Based  Implementation  of  Parallelized  Pollard’s  rho  algorithm  for  Menezes  A.  and  Vanstone  S.  Elliptic  Curve  Systems’,  Proposed  IEEE  P1363  Standard,  pp.  142.
9)  Chwei−Shyong  Tsai,  Min−Shiang  Hwang,  pei−ChenSung,  “Blind  Signature  Scheme  Based  on  Elliptic  Curve  Cryptography”  (http://mshwang.ccs.asia.edu.tw/www/myjournal/P191.pdf.)
10)  Dawson,  E.;  Donovan,  D.  (1994),  "The  breadth  of  Shamir's  secret−sharing  scheme",  Computers  &  Security,  13:  Pp.  69-78
11)  Desmedt.  Yuo  (1987).  “Society  and  Group  Oriented  Cryptography:  A  New  Concept”.  In  A  Conference  on  the  Theory  and  Applications  of  Cryptographic  Techniques  on  Advances  in  Cryptology  (CRYPTO  '87),  Carl  Pomerance  (Ed.).  Springer−Verlag,  London,  UK,  UK,  120−127.
12)  ElGamal  T.  (1985),  ‘A  Public−Key  Cryptosystem  and  a  Signature  Scheme  Based  on  Discrete  Logarithms’,  IEEE  Transactions  on  Information  Theory,  Vol.31,  pp.  469−472.
13)  Feldman.  P.  “A  practical  scheme  for  non−interactive  verifiable  secret  sharing”.  In  Proceedings  of  the  28th  IEEE  Annual  Symposium  on  Foundations  of  Computer  Science,  pages  427-437,  1987.
14)  Gennaro,  R.,  Jarecki,  S.,  Krawczyk,  H.,  Rabin,  T.:  “Robust  threshold  DSS  signatures”.  In:  Proceedings  of  the  15th  Annual  International  Conference  on  Theory  and  Application  of  Cryptographic  Techniques.  pp.  354-371.  EUROCRYPT’96,  SpringerVerlag,  Berlin,  Heidelberg  (1996)
15)  Ibrahim,  M.,  Ali,  I.,  Ibrahim,  I.,  El−sawi,  A.:  “A  robust  threshold  elliptic  curve  digital  signature  providing  a  new  verifiable  secret  sharing  scheme”.  In:  Circuits  and  Systems,  2003  IEEE  46th  Midwest  Symposium  on.  vol.  1,  pp.  276-280  (2003)
16)  Johnson,  D.,  Menezes,  A.,  Vanstone,  S.:  “The  elliptic  curve  digital  signature  algorithm  (ecdsa)”.  International  Journal  of  Information  Security  1(1),  36-63  (2001)
17)  Chakraborty,  Kalyan  &  Mehta,  Jay  (2011)  “A  Stamped  Blind  Signature  Scheme  based  on  Elliptic  Curve  Discrete  Logarithm  Problem”  (http://ijns.femto.com.tw/contents/ijns−v14−n6/ijns−2012−v14−n6−p316−319.pdf).
18)  Kapoor,  Vivek,  Vivek  Sonny  Abraham,  and  Ramesh  Singh.  "Elliptic  Curve  Cryptography."  Ubiquity  2008,  no.  May  (2008):  1−8.
19)  Knuth,  D.  E.  (1997),  “The  Art  of  Computer  Programming,  II:  Seminumerical  Algorithms”  (3rd  ed.),  Addison−Wesley,  p.  505.
20)  Koblitz,  N.  "An  Elliptic  Curve  Implementation  of  the  Finite  Field  Digital  Signature  Algorithm"  in  Advances  in  Cryptology  --  Crypto  '98.  Lecture  Notes  in  Computer  Science,  vol.  1462,  pp.  327−337,  1998,  Springer−Verlag.
21)  Liu,  C.  L.  (1968),  “Introduction  to  Combinatorial  Mathematics”,  New  York:  McGraw−Hill.
22)  National  Institute  of  Standards  and  Technology:  FIPS  PUB  186−4:  “Digital  Signature  Standard”  (DSS)  (2003)
23)  Pedersen,  T.:  “Non−interactive  and  information−theoretic  secure  verifiable  secret  sharing”.  In:  Feigenbaum,  J.  (ed.)  Advances  in  Cryptology  −  CRYPTO  ’91,  LNCS,  vol.  576,  pp.  129-140.  Springer  (1992)
24)  Rabin  T.  &  Ben−Or.  M.  (1989)  "Verifiable    secret    sharing    and    multiparty    protocols    with    honest    majority".    In    Proc.    21st    ACM    Symposium    on    Theory  of  Computing,  pages  73−−85,  1989.  
25)  Shamir,  Adi  (1979),  "How  to  share  a  secret",  Communications  of  the  ACM,  22  (11):  Pp.  612-613
26)  Wright,  C.  &  Savanah,  S.  (2016)  “Determining  a  common  secret  for  two  Blockchain  nodes  for  the  secure  exchange  of  information”  "Application  Number:  15087315".  2016:  n.  pag.  UK
【図１】
2021510954.tif 000027
【図２】
2021510954.tif 000028
【国際調査報告】
2021510954.tif 000029
2021510954.tif 000030