(57)【要約】秘密値を共有する方法が開示される。方法は、第１参加者（Ｐｉ）に知られている第１秘密値の各々の第１シェアを複数の第２参加者（Ｐｉ≠ｉ）に分配することを有し、第１シェアは、秘密鍵と、秘密鍵を乗じられた楕円曲線生成元点である公開鍵とを有する少なくとも１つの秘密−公開鍵対を用いて暗号化され、第１閾数の第１シェアが、第１秘密値を決定することを第２参加者に可能にするために必要とされる。各々の第２秘密値の少なくとも１つの第２シェアが、複数の第２参加者の夫々から受け取られ、第２シェアは、秘密鍵と、秘密鍵を乗じられた楕円曲線生成元点である公開鍵とを有する少なくとも１つの秘密−公開鍵対を用いて暗号化され、第２閾数の第２シェアが、第２秘密値を決定することを第２参加者以外の参加者に可能にするために使用される。第３秘密値の第３シェアが複数の第２シェアから形成され、第３閾数の第３シェアが、第３秘密値が決定されることを可能にするために必要とされる。
2020531893.tif 000002
【特許請求の範囲】
【請求項１】
暗号化システムの公開−秘密鍵対の公開鍵を用いて検証することができるデジタル署名を提供するよう、前記公開−秘密鍵対の秘密鍵を用いてデジタルメッセージにデジタル署名する方法であって、
前記デジタルメッセージの少なくとも閾数の部分署名を受け取り、前記部分署名の夫々は、前記メッセージに基づく各々の第１部分と、前記秘密鍵の各々のシェアに基づく各々の第２部分とを含み、前記秘密鍵は、該秘密鍵の前記閾数のシェアに利用可能であり、前記閾数に満たないシェアには利用不可能であり、前記部分署名の夫々は、第１多項式関数が、前記閾数の部分署名に利用可能であり、前記閾数に満たない部分署名には利用不可能であるように、前記第１多項式関数の各々の値に対応する、ことと、
前記部分署名の複数の既知の値から前記第１多項式関数の係数を決定することによって前記第１多項式関数を決定して、前記メッセージのデジタル署名を達成することと
を有する方法。
【請求項２】
前記第１多項式関数を決定することは、エラー訂正アルゴリズムを実行することを有する、
請求項１に記載の方法。
【請求項３】
前記第１多項式関数を決定することは、バーレカンプ−ウェルチ復号化アルゴリズムを実行することを有する、
請求項１又は２に記載の方法。
【請求項４】
前記第１多項式関数を決定することは、
誤り位置多項式関数、及び前記第１多項式関数と前記誤り位置多項式関数との積である第２多項式関数とを定義することと、
前記部分署名の複数の既知の値から前記第２多項式関数及び前記誤り位置多項式関数の係数を決定することと、
前記メッセージのデジタル署名を達成するよう前記第２多項式関数及び前記誤り位置多項式関数から前記第１多項式関数を決定することと
を有する、
請求項１乃至３のうちいずれか一項に記載の方法。
【請求項５】
暗号化システムの公開−秘密鍵対の公開鍵を用いて検証することができるデジタル署名を提供するよう、前記公開−秘密鍵対の秘密鍵を用いてデジタルメッセージにデジタル署名する方法であって、
前記デジタルメッセージの少なくとも閾数の部分署名を受け取り、前記部分署名の夫々は、前記メッセージに基づく各々の第１部分と、前記秘密鍵の各々のシェアに基づく各々の第２部分と、ゼロ定数項を有する第３多項式関数の各々の値に対応する各々の第３部分とを含み、前記秘密鍵は、該秘密鍵の前記閾数のシェアに利用可能であり、前記閾数に満たないシェアには利用不可能であり、前記第３多項式関数は、該第３多項式関数の前記閾数のシェアに利用可能であり、前記閾数に満たないシェアには利用不可能であり、前記部分署名の夫々は、第４多項式関数が、前記閾数の部分署名に利用可能であり、前記閾数に満たない部分署名には利用不可能であるように、前記第４多項式関数の各々の値に対応する、ことと、
前記メッセージのデジタル署名を達成するよう前記第４多項式関数を決定することと
を有する方法。
【請求項６】
少なくとも１つの前記部分署名の前記各々の第３部分は、対応する前記第１部分及び対応する前記第２部分に加えられる、
請求項５に記載の方法。
【請求項７】
前記部分署名の夫々は、一時鍵の各々のシェアに基づく各々の第４部分を更に含み、
前記一時鍵は、前記一時鍵の前記閾数のシェアに利用可能であり、前記閾数に満たないシェアには利用不可能である、
請求項１乃至６のうちいずれか一項に記載の方法。
【請求項８】
前記暗号化システムは、楕円曲線暗号化システムである、
請求項１乃至７のうちいずれか一項に記載の方法。
【請求項９】
第１参加者に知られている第１秘密値の少なくとも１つの各々の第１シェアを複数の第２参加者の夫々に分配し、前記第１シェアは、秘密鍵と、該秘密鍵を乗じられた楕円曲線生成元点である公開鍵とを有する少なくとも１つの秘密−公開鍵対を用いて暗号化され、第１閾数の第１シェアが、前記第１秘密値を決定することを前記第２参加者の夫々に可能にするために必要とされる、ことと、
複数の前記第２参加者の夫々から、当該第２参加者に知られている各々の第２秘密値の少なくとも１つの第２シェアを受け取り、前記第２シェアは、秘密鍵と、該秘密鍵を乗じられた楕円曲線生成元点である公開鍵とを有する少なくとも１つの秘密−公開鍵対を用いて暗号化され、第２閾数の第２シェアが、前記第２秘密値を決定することを当該第２参加者以外の参加者に可能にするために必要とされる、ことと、
複数の前記第２シェアから、第３秘密値の第３シェアを形成し、第３閾数の第３シェアが、前記第３秘密値が決定されることを可能にするために必要とされる、ことと
を更に有する請求項８に記載の方法。
【請求項１０】
前記第１閾数は、前記第２閾数に等しく、且つ／あるいは、
前記第２閾数は、前記第３閾数に等しく、且つ／あるいは、
前記第３閾数は、前記第１閾数に等しい、
請求項９に記載の方法。
【請求項１１】
前記第１参加者と複数の前記第２参加者の夫々との間の暗号化された通信を可能にすることを更に有する、
請求項９又は１０に記載の方法。
【請求項１２】
前記暗号化された通信は、前記第１参加者と、該第１参加者から独立して前記複数の第２参加者の夫々とによって決定された各々の共通の秘密を用いて可能にされる、
請求項１１に記載の方法。
【請求項１３】
前記第１参加者は、秘密鍵を更新し、前記複数の第２参加者の夫々に関連した各々の公開鍵を更新し、
前記複数の第２参加者の夫々は、各々の秘密鍵と、前記第１参加者に関連した公開鍵とを更新する、
請求項１２に記載の方法。
【請求項１４】
前記鍵は、前記第１参加者と対応する前記第２参加者との間で同意されたデータを基に更新される、
請求項１３に記載の方法。
【請求項１５】
前記第１秘密値の前記第１シェア及び前記第２秘密値の前記第２シェアは、各々のシャミア秘密分散スキームにより生成される、
請求項９乃至１４のうちいずれか一項に記載の方法。
【請求項１６】
複数の前記第３シェアは、第５多項式関数の各々の値であり、
前記第３秘密値は、前記第３閾数の前記値から前記第５多項式関数を導出することによって決定可能である、
請求項９乃至１５のうちいずれか一項に記載の方法。
【請求項１７】
複数の前記第２参加者に対して、楕円曲線生成元点を乗じられた各々の前記第１シェアを送ることを更に有する、
請求項９乃至１６のうちいずれか一項に記載の方法。
【請求項１８】
複数の前記第２参加者から、楕円曲線生成元点を乗じられた少なくとも１つの各々の前記第２シェアを受け取ることを更に有する、
請求項９乃至１７のうちいずれか一項に記載の方法。
【請求項１９】
少なくとも１の前記第２参加者から直接受け取られた少なくとも１つの前記第２シェアと、少なくとも１の更なる前記第２参加者から受け取られた、前記楕円曲線生成元点を乗じられた少なくとも１つの前記第２シェアとの一貫性を検証することを更に有する、
請求項１８に記載の方法。
【請求項２０】
前記検証することに基づき前記第３秘密値を更新することを更に有する、
請求項１９に記載の方法。
【請求項２１】
少なくとも１つの前記第２シェアは、各々の第６多項式関数の値であり、
対応する前記第２秘密値は、対応する第２閾数の前記値から対応する前記第６多項式関数を導出することによって決定可能である、
請求項１８乃至２０のうちいずれか一項に記載の方法。
【請求項２２】
複数の前記第２参加者の夫々から、楕円曲線生成元点を乗じられた各々の前記第６多項式関数の少なくとも１つの係数を受け取ることを更に有する、
請求項２１に記載の方法。
【請求項２３】
前記検証することは、前記楕円曲線生成元点を乗じられた前記係数から、前記楕円曲線生成元点を乗じられた前記第６多項式関数を再構成することを有する、
請求項１９及び２２に記載の方法。
【請求項２４】
前記第１秘密値と、複数の前記第２参加者から受け取られた、前記楕円曲線生成元点を乗じられた複数の前記第１シェアとの一貫性を検証することを更に有する、
請求項１８乃至２３のうちいずれか一項に記載の方法。
【請求項２５】
前記検証することに基づいて前記第３秘密値を更新することを更に有する、
請求項２４に記載の方法。
【請求項２６】
前記検証することは、複数の前記第２シェアに適用される場合に前記第２秘密値をもたらす方法を用いて、前記楕円曲線生成元点を乗じられた前記複数の第２シェアから、前記楕円曲線生成元点を乗じられた前記第２秘密値を取得することを有する、
請求項２４又は２５に記載の方法。
【請求項２７】
少なくとも１の前記第２参加者から、値ゼロ有する第４秘密値の少なくとも１つの第４シェアを受け取ることを更に有し、
前記第４シェアは、秘密鍵と、該秘密鍵を乗じられた楕円曲線生成元点である公開鍵とを有する少なくとも１つの秘密−公開鍵対を用いて暗号化される、
請求項９乃至２６のうちいずれか一項に記載の方法。
【請求項２８】
前記第２参加者又は夫々の前記第２参加者とは異なる少なくとも１の第３参加者から、値ゼロを有する第４秘密値の少なくとも１つの第４シェアを受け取ることを更に有し、
前記第４シェアは、秘密鍵と、該秘密鍵を乗じられた楕円曲線生成元点である公開鍵とを有する少なくとも１つの秘密−公開鍵対を用いて暗号化される、
請求項９乃至２７のうちいずれか一項に記載の方法。
【請求項２９】
前記楕円曲線生成元点を乗じられた複数の前記第４シェアと、ゼロ第４秘密値との一貫性を検証することを更に有する、
請求項２７又は２８に記載の方法。
【請求項３０】
前記検証することに基づいて前記第３秘密値を更新することを更に有する、
請求項２９に記載の方法。
【請求項３１】
前記検証することは、複数の前記第４シェアに適用される場合に前記第４秘密値をもたらす方法を用いて、前記楕円曲線生成元点を乗じられた前記複数の第４シェアから、前記楕円曲線生成元点を乗じられた前記第４秘密値を取得することを有する、
請求項２９又は３０に記載の方法。
【請求項３２】
前記第３シェア及び前記第４シェアから、前記第３秘密値の第５シェアを形成することを更に有し、
第４閾数の第５シェアが、前記第３秘密値が決定されることを可能にするために必要とされる、
請求項２７乃至３１のうちいずれか一項に記載の方法。
【請求項３３】
前記メッセージは、ブロックチェーントランザクションである、
請求項１乃至３２のうちいずれか一項に記載の方法。
【請求項３４】
請求項１乃至３３のうちいずれか一項に記載の方法を実行するよう構成されたコンピュータ実装システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、データ及びコンピュータに基づくリソースの安全性に関係がある。より具体的には、本発明は、暗号通貨及び暗号化に、更には、楕円曲線暗号化（Elliptic  Curve  Cryptography）、楕円曲線デジタル署名アルゴリズム（Elliptic  Curve  Digital  Signature  Algorithm）（ＥＣＤＳＡ）、及び閾値暗号化（Threshold  Cryptography）に関係がある。本発明は、（例えば）ビットコインのような、ブロックチェーンにより実施される暗号通貨に関して利益をもたらすよう使用され得るが、この点において制限されず、より広い適用可能性を有することができる。本発明は、一実施形態では、ディーラーなしの秘密分配のための分配プロトコルを提供するものとして記載され得る。
【背景技術】
【０００２】
本文書中、我々は、あらゆる形式の電子的な、コンピュータに基づく分散台帳（distributed  ledgers）を含むように語「ブロックチェーン」を使用する。それらは、合意に基づくブロックチェーン及びトランザクションチェーン技術、許可（permissioned）及び無許可（un-permissioned）台帳、共有台帳、並びにこれらの変形を含む。ブロックチェーン技術の最も広く知られた応用は、他のブロックチェーン実施が提案及び開発されているとはいえ、ビットコイン台帳である。ビットコインが、便宜上、単に説明のために本明細書で言及され得るが、本発明は、ビットコインブロックチェーンとともに使用することに限られず、代替のブロックチェーン実施及びプロトコルが本発明の適用範囲内にあることが留意されるべきである。
【０００３】
ブロックチェーンは、ピア・ツー・ピアの電子台帳であり、これは、トランザクションから成るブロックで構成された、コンピュータに基づく非中央集権型システムとして実装される。各トランザクションは、ブロックチェーンシステム内の参加者間のデジタルアセットの制御の移転を符号化するデータ構造であり、少なくとも１つの入力及び少なくとも１つの出力を含む。ブロックチェーンにその始まり以来書き込まれてきた全てのトランザクションの永久的且つ不変な記録を構成するようブロックどうしが連鎖するように、各ブロックは前のブロックのハッシュを含む。
【０００４】
非中央集権化（decentralisation）の概念は、ビットコインメソッドロジにおいて基本的なことである。非中央集権型システムには、分散型又は中央集権型システムとは異なり、単一障害点がないという利点がある。従って、それらは、向上した安全性及び回復力のレベルを提供する。この安全性は、楕円曲線暗号化及びＥＣＤＳＡのような既知の暗号化技術の使用によって更に高められる。
【０００５】
しかし、ビットコインプロトコル自体は、本願の出願時点で、如何なる有意な攻撃に対しても回復力を持つことが証明されている一方で、ビットコインネットワークを補完又は構築するやり取り及びウォレットに対する攻撃も存在している。ビットコインの価値が高まるにつれて、マウントゴックス（Mt  Gox）及びビットフィネックス（Bitfinex）に関連するもののような事件が、標準の中央集権型システムでますます起こる可能性がある。
【発明の概要】
【０００６】
よって、そのようなシステムの安全性を更に高める解決法の必要性が存在する。本発明は、とりわけ、そのような利点を提供する。
【０００７】
本発明は、添付の特許請求の範囲で定義される方法及びシステムを提供する。
【０００８】
本発明の態様によれば、暗号化システムの公開−秘密鍵対の公開鍵を用いて検証することができるデジタル署名を提供するよう、前記公開−秘密鍵対の秘密鍵を用いてデジタルメッセージにデジタル署名する方法であって、
前記デジタルメッセージの少なくとも閾数の部分署名を受け取り、前記部分署名の夫々は、前記メッセージに基づく各々の第１部分と、前記秘密鍵の各々のシェアに基づく各々の第２部分とを含み、前記秘密鍵は、該秘密鍵の前記閾数のシェアに利用可能であり、前記閾数に満たないシェアには利用不可能であり、前記部分署名の夫々は、第１多項式関数が、前記閾数の部分署名に利用可能であり、前記閾数に満たない部分署名には利用不可能であるように、前記第１多項式関数の各々の値に対応する、ことと、
前記部分署名の複数の既知の値から前記第１多項式関数の係数を決定することによって前記第１多項式関数を決定して、前記メッセージのデジタル署名を達成することと
を有する方法が提供される。
【０００９】
前記部分署名の複数の既知の値から前記第１多項式関数の係数を決定することによって前記第１多項式関数を決定することによれば、これは、当該方法の計算効率を改善するという利点をもたらす。
【００１０】
前記第１多項式を決定することは、エラー訂正アルゴリズムを実行することと、ＡＤＳＬのような電子データ通信で使用される従来の復号器が使用されることを可能にすることとを有してよい。
【００１１】
これは、デジタル署名プロセスの正確さを向上させるという利点をもたらす。
【００１２】
前記第１多項式関数を決定することは、バーレカンプ−ウェルチ（Berlerkamp-Welch）復号化アルゴリズムを実行することを有してよい。
【００１３】
前記第１多項式関数を決定することは、
誤り位置多項式関数、及び前記第１多項式関数と前記誤り位置多項式関数との積である第２多項式関数とを定義することと、
前記部分署名の複数の既知の値から前記第２多項式関数及び前記誤り位置多項式関数の係数を決定することと、
前記メッセージのデジタル署名を達成するよう前記第２多項式関数及び前記誤り位置多項式関数から前記第１多項式関数を決定することと
を有してよい。
【００１４】
本発明の他の態様によれば、暗号化システムの公開−秘密鍵対の公開鍵を用いて検証することができるデジタル署名を提供するよう、前記公開−秘密鍵対の秘密鍵を用いてデジタルメッセージにデジタル署名する方法であって、
前記デジタルメッセージの少なくとも閾数の部分署名を受け取り、前記部分署名の夫々は、前記メッセージに基づく各々の第１部分と、前記秘密鍵の各々のシェアに基づく各々の第２部分と、ゼロ定数項を有する第３多項式関数の各々の値に対応する各々の第３部分とを含み、前記秘密鍵は、該秘密鍵の前記閾数のシェアに利用可能であり、前記閾数に満たないシェアには利用不可能であり、前記第３多項式関数は、該第３多項式関数の前記閾数のシェアに利用可能であり、前記閾数に満たないシェアには利用不可能であり、前記部分署名の夫々は、第４多項式関数が、前記閾数の部分署名に利用可能であり、前記閾数に満たない部分署名には利用不可能であるように、前記第４多項式関数の各々の値に対応する、ことと、
前記メッセージのデジタル署名を達成するよう前記第４多項式関数を決定することと
を有する方法が提供される。
【００１５】
各部分署名が、ゼロ定数項を有する第３多項式関数の各々の値に対応する各々の第３部分を含み、前記第３多項式が、該第３多項式関数の前記閾数のシェアに利用可能であり、前記閾数に満たないシェアには利用不可能である方法を提供することによれば、これは、デジタル署名プロセスで使用される秘密鍵及び／又は任意の一時鍵をマスキングし、それによって、それらの鍵が権限のないパーティによって決定されるリスクを最小限することによって、当該方法の安全性を高めるという利点をもたらす。
【００１６】
少なくとも１つの前記部分署名の前記各々の第３部分は、対応する前記第１部分及び対応する前記第２部分に加えられてよい。
【００１７】
前記部分署名の夫々は、一時鍵の各々のシェアに基づく各々の第４部分を更に含んでよく、前記一時鍵は、前記一時鍵の前記閾数のシェアに利用可能であり、前記閾数に満たないシェアには利用不可能である。
【００１８】
前記暗号化システムは、楕円曲線暗号化システムであってよい。
【００１９】
当該方法は、
第１参加者に知られている第１秘密値の少なくとも１つの各々の第１シェアを複数の第２参加者の夫々に分配し、前記第１シェアは、秘密鍵と、該秘密鍵を乗じられた楕円曲線生成元点である公開鍵とを有する少なくとも１つの秘密−公開鍵対を用いて暗号化され、第１閾数の第１シェアが、前記第１秘密値を決定することを前記第２参加者の夫々に可能にするために必要とされる、ことと、
複数の前記第２参加者の夫々から、当該第２参加者に知られている各々の第２秘密値の少なくとも１つの第２シェアを受け取り、前記第２シェアは、秘密鍵と、該秘密鍵を乗じられた楕円曲線生成元点である公開鍵とを有する少なくとも１つの秘密−公開鍵対を用いて暗号化され、第２閾数の第２シェアが、前記第２秘密値を決定することを当該第２参加者以外の参加者に可能にするために必要とされる、ことと、
複数の前記第２シェアから、第３秘密値の第３シェアを形成し、第３閾数の第３シェアが、前記第３秘密値が決定されることを可能にするために必要とされる、ことと
を更に有してよい。
【００２０】
複数の前記第２シェアから、第３秘密値の第３シェアを形成し、第３閾数の第３シェアが、前記第３秘密値が決定されることを可能にするために必要とされる、ことによれば、第１秘密値及び第２秘密値に対応する秘密鍵がメモリにおいて開示又は記憶されることはもはや不要であるから、これは、第１秘密値及び第２秘密値へのアクセスを最小限し、それによって、当該方法の安全性を改善するという利点をもたらす。
【００２１】
前記第１閾数は、前記第２閾数に等しくてよく、且つ／あるいは、前記第２閾数は、前記第３閾数に等しくてよく、且つ／あるいは、前記第３閾数は、前記第１閾数に等しくてよい。
【００２２】
当該方法は、前記第１参加者と複数の前記第２参加者の夫々との間の暗号化された通信を可能にすることを更に有してよい。
【００２３】
これは、一貫性のない又は不審なシェアを暗号化するために使用された暗号鍵を識別することによって、不正直な参加者がより容易に識別されることを可能にするという利点をもたらす。
【００２４】
前記暗号化された通信は、前記第１参加者と、該第１参加者から独立して前記複数の第２参加者の夫々とによって決定された各々の共通の秘密を用いて可能にされてよい。
【００２５】
これは、システムの安全性を高めるという利点をもたらす。
【００２６】
前記第１参加者は、秘密鍵を更新し、且つ、前記複数の第２参加者の夫々に関連した各々の公開鍵を更新してよく、前記複数の第２参加者の夫々は、各々の秘密鍵と、前記第１参加者に関連した公開鍵とを更新してよい。
【００２７】
前記鍵は、前記第１参加者と対応する前記第２参加者との間で同意されたデータを基に更新されてよい。
【００２８】
これは、システムの安全性を更に高める。
【００２９】
前記第１秘密値の前記第１シェア及び前記第２秘密値の前記第２シェアは、各々のシャミア秘密分散スキームにより生成されてよい。
【００３０】
複数の前記第３シェアは、第５多項式関数の各々の値であってよく、前記第３秘密値は、前記第３閾数の前記値から前記第５多項式関数を導出することによって決定可能である。
【００３１】
当該方法は、複数の前記第２参加者に対して、楕円曲線生成元点を乗じられた各々の前記第１シェアを送ることを更に有してよい。
【００３２】
当該方法は、複数の前記第２参加者から、楕円曲線生成元点を乗じられた少なくとも１つの各々の前記第２シェアを受け取ることを更に有してよい。
【００３３】
当該方法は、少なくとも１の前記第２参加者から直接受け取られた少なくとも１つの前記第２シェアと、少なくとも１の更なる前記第２参加者から受け取られた、前記楕円曲線生成元点を乗じられた少なくとも１つの前記第２シェアとの一貫性を検証することを更に有してよい。
【００３４】
これは、異なる第２参加者から受け取られたシェアの一貫性が、秘密鍵又はシェアを開示せずに、チェックされることを可能にし、それによって、当該方法の安全性を脅かすことなく、疑わしい信用できない参加者が無視されることを可能にするという利点をもたらす。
【００３５】
当該方法は、前記検証することに基づき前記第３秘密値を更新することを更に有してよい。
【００３６】
これは、システムの安全性を改善するという利点をもたらす。
【００３７】
少なくとも１つの前記第２シェアは、各々の第６多項式関数の値であってよく、対応する前記第２秘密値は、対応する第２閾数の前記値から対応する前記第６多項式関数を導出することによって決定可能である。
【００３８】
当該方法は、複数の前記第２参加者の夫々から、楕円曲線生成元点を乗じられた各々の前記第６多項式関数の少なくとも１つの係数を受け取ることを更に有してよい。
【００３９】
これは、第２多項式関数を再構成することによって、当該方法の安全性を脅かすことなく、第１参加者によって分配された第１シェアと、第２参加者から受け取られた、楕円曲線生成元点を乗じられた第１シェアとの一貫性が検証されることを可能にするという利点をもたらす。
【００４０】
前記検証することは、前記楕円曲線生成元点を乗じられた前記係数から、前記楕円曲線生成元点を乗じられた前記第６多項式関数を再構成することを有してよい。
【００４１】
当該方法は、前記第１参加者から直接受け取られた前記第１シェアと、複数の前記第２参加者から受け取られた、前記楕円曲線生成元点を乗じられた前記第１シェアとの一貫性を検証することを更に有してよい。
【００４２】
これは、当該方法の安全性を脅かすことなく、信用できない可能性がある参加者が識別されることを可能にするという利点をもたらす。
【００４３】
当該方法は、前記第１秘密値と、複数の前記第２参加者から受け取られた、前記楕円曲線生成元点を乗じられた複数の前記第１シェアとの一貫性を検証することを更に有してよい。
【００４４】
当該方法は、前記検証することに基づいて前記第３秘密値を更新することを更に有してよい。
【００４５】
前記検証することは、複数の前記第２シェアに適用される場合に前記第２秘密値をもたらす方法を用いて、前記楕円曲線生成元点を乗じられた前記複数の第２シェアから、前記楕円曲線生成元点を乗じられた前記第２秘密値を取得することを有してよい。
【００４６】
当該方法は、１の前記第２参加者から受け取られた、前記楕円曲線生成元点を乗じられた前記第１シェアと、他の前記第２参加者から受け取られた、前記楕円曲線生成元点を乗じられた前記第１シェアとの一貫性を検証することを更に有してよい。
【００４７】
これも、当該方法の安全性を脅かすことなく、信用できない可能性がある参加者が識別されることを可能にするという利点をもたらす。
【００４８】
当該方法は、少なくとも１の前記第２参加者から、値ゼロ有する第４秘密値の少なくとも１つの第４シェアを受け取ることを更に有してよく、前記第４シェアは、秘密鍵と、該秘密鍵を乗じられた楕円曲線生成元点である公開鍵とを有する少なくとも１つの秘密−公開鍵対を用いて暗号化される。
【００４９】
当該方法は、複数の第２参加者に対して、値ゼロを有する第４秘密値の各々の第４シェアを分配することを更に有してよく、前記第４シェアは、秘密鍵と、該秘密鍵を乗じられた楕円曲線生成元点である公開鍵とを有する少なくとも１つの秘密−公開鍵対を用いて暗号化される。
【００５０】
これは、シェア及び／又は秘密鍵が更新されることを可能にし、それによって、安全でない又は一貫性のない参加者が参加から除かれることを可能にするという利点をもたらす。
【００５１】
当該方法は、前記第２参加者又は夫々の前記第２参加者とは異なる少なくとも１の第３参加者から、値ゼロを有する第４秘密値の少なくとも１つの第４シェアを受け取ることを更に有してよく、前記第４シェアは、秘密鍵と、該秘密鍵を乗じられた楕円曲線生成元点である公開鍵とを有する少なくとも１つの秘密−公開鍵対を用いて暗号化される。
【００５２】
これは、ランダムさの導入を可能にするように外部オラクルが導入される可能にし、それによって、システムの安全性を改善するという利点をもたらす。
【００５３】
当該方法は、前記楕円曲線生成元点を乗じられた複数の前記第４シェアと、ゼロ第４秘密値との一貫性を検証することを更に有してよい。
【００５４】
当該方法は、前記検証することに基づいて前記第３秘密値を更新することを更に有してよい。
【００５５】
前記検証することは、複数の前記第４シェアに適用される場合に前記第４秘密値をもたらす方法を用いて、前記楕円曲線生成元点を乗じられた前記複数の第４シェアから、前記楕円曲線生成元点を乗じられた前記第４秘密値を取得することを有してよい。
【００５６】
当該方法は、前記第３シェア及び前記第４シェアから、前記第３秘密値の第５シェアを形成することを更に有してよく、第４閾数の第５シェアが、前記第３秘密値が決定されることを可能にするために必要とされる。
【００５７】
前記メッセージは、ブロックチェーントランザクションであってよい。
【００５８】
本発明の更なる態様によれば、上記の方法を実行するコンピュータ実装システムが提供される。
【００５９】
本発明のこれら及び他の態様は、本明細書で記載される実施形態から明らかであり、それらを参照して説明される。
【００６０】
これより、本発明の実施形態が、単なる例として、添付の図面を参照して記載される。
【図面の簡単な説明】
【００６１】
【図１】本発明を具現する楕円曲線デジタル署名プロセスの部分を表す。
【図２】楕円曲線デジタル署名プロセスの更なる部分を表す。
【図３】本発明を具現する方法によって分配されるシェアの再構成階層を表す。
【図４】本発明の方法で使用されるブロックチェーントランザクションのスクリプトの表現を示す。
【図５】図４のスクリプトとともに使用される第１署名の詳細を示す。
【図６Ａ】図４のスクリプトとともに使用される第２署名の第１実施形態の詳細を示す。
【図６Ｂ】図４のスクリプトとともに使用される第２署名の第２実施形態の詳細を示す。
【図７】本発明を具現する方法を実行するバーレカンプ−ウェルチ復号器を示す。
【発明を実施するための形態】
【００６２】
＜概要＞
本発明は、不正アクセスから保護される必要があるコンピュータシステム及びリソースの安全性を高めるために使用され得る新規且つ独創的な技術を提供する。本明細書では、ビットコインを含む暗号通貨に関連したシステムに関係がある実施、使用ケース及び実例が紹介される。しかし、本発明は、より広い適用性を有しており、他のタイプのシステム及びコンピュータに基づくリソースを守ために使用されてよく、本発明はこの点で制限されないことに留意することが重要である。
【００６３】
本発明の実施形態は、ディーラーを伴わない展開のための能力と結合された、グループに基づく閾値暗号化の付加を可能にすることによって、改善された安全性をもたらす。実施形態はまた、メッセージの非インタラクティブな署名をサポートし、且つ、個人及びグループに分配され得るシェアへの秘密鍵の分割を提供する。更に、本発明は、不正行為又は攻撃の如何なる脅威も最小限としながら如何なる中央集権的制御の必要性も排除する分散型鍵生成システムを構築する解決法を提供する。ＥＣＤＳＡに対するＤＳＡの閾値に基づく解決法の適用において、本発明は、如何なる単一障害点も緩和する完全に分配的な署名システムを提供する。
【００６４】
ビットコイン又は代わりとなるものに関して使用される場合に、それは、暗号通貨を展開する無限に拡張可能であって且つ安全な手段にＣＬＴＶ及びマルチシグウォレット（multisig  wallets）を関係させる検索方式と結合可能である。グループ及びリングに基づくシステムによれば、本発明は、発行されたトランザクションに対してブラインド署名を実装するために利用可能である。
【００６５】
本願は、ビットコインと完全互換である、閾値に基づく、ディーラーなしの秘密鍵分配システムを開示する。システムは、ビットコインウォレット内で展開される従来の個別署名システムから離れるグループ署名スキームを足場とする。展開される場合に、システムは、拡張性があり且つ堅牢であって、エラー及び悪意のある敵に耐性がある。システムは、ディーラーあり及びディーラーなし両方のシステム並びに大いに柔軟な分配組み合わせでの展開を支援する。
【００６６】
個々のパーティは、単独の参加者として又は共同して、彼らの保護された鍵スライスのスライスを、安全性及び回復力のためにマシン全体に、又は役割及びアクセス制御リストの投票閾値に基づいた展開のためにグループで分配するディーラーの役割を果たすことができる。
【００６７】
どの程度までスライスが分割可能であるかの深さに制限はない。この複雑性の問題は、個々の展開に対して重み付けされる必要がある。このようにして、署名及びトランザクションの記録は、この方法を用いて、グループ内からのものであっても、その後の書類で提示される拡張子を持った全ての外部の参加者から隠され得るということで、本発明の実施形態は、ユーザに対する偽名を用いた保護（pseudonymous  protection）の標準を高めながら、ある程度の匿名性及びもっともらしい否認（plausible  deniability）をビットコイントランザクションに導入する。
【００６８】
Ibrahim  et  al.［２００３］は、初期のロバストな閾値ＥＣＤＳＡスキームを開発した。続くプロトコルは、Gennaro  et  al.［１９９６］によって紹介された閾値ＤＳＳの楕円曲線式を形成するものの更なる拡張である。
【００６９】
【表１】
2020531893.tif 000003
群数学（group  mathematics）の使用は、ＲＳＡ及びＤＳＡスキームから秘密の隠蔽におけるShamir［１９７９］の研究並びにFeldman［１９８７］及びPedersen［１９９２］の研究を拡張する検証可能秘密分散スキーム（verifiable  secret  sharing  scheme）（ＶＳＳ）の構築を可能にし、それにより、それは、ビットコイン［Koblitz，１９９８］のような、ＥＣＣ及びＥＣＤＳＡに基づく署名システム内で使用され得る。本発明の実施形態は、悪意のある敵に耐性があり、停止し（halting）、傍受に対して堅牢である。
【００７０】
本開示は、どのパーティも秘密鍵を知らない場合にＥＣＤＳＡ署名の共同署名を可能にする方法の提示から始まる。更に、それは、秘密鍵を変更する必要なしに、秘密鍵対が更新及びリフレッシュされることを可能にする。これは有意な技術的利点である。
【００７１】
既存の解決法は全て、信頼できるパーティを必要とする。本発明を利用することはまた、代替ブロックチェーン又はサイドチェーンの要件を陳腐化しながら、ビットコインブロックチェーン上で直接解決され得る電子ノード発行の真に分散された方法へと中央集権型システムからChaum［１９８３］の研究を拡張することを可能にする。
【００７２】
上記の生成元Ｇに関して、ビットコインはｓｅｃｐ２５６ｋ１を使用する。これは，ビットコインで使用されるＥＣＤＳＡ曲線のパラメータを定義し、Standards  for  Efficient  Cryptography（ＳＥＣ）（Certicom  Research，http://www.secg.org/sec2-v2.pdf）から参照され得る。
【００７３】
＜信頼の問題＞
全ての既存のシステムは、ある程度の信頼を必要とする。これまで、ビットコインは、世界から隔絶されているセキュアシステムを使用した秘密鍵の保護を必要としてきたが、これは達成するのが困難であることが分かっている。注目すべきは、ビットコインが交換又は保管され得るシステムは、中央当局（centralised  authority）に対する信頼を必要とする点である。本発明は、この要件を完全に変えて、プロトコルの中核的要件のいずれも変えることなく、ビットコイン内の鍵生成及びメッセージ署名プロセスを分散化及び分権化する。本明細書で言及される方法は、ビットコインプロトコルを変更せずに実装され得、実際には、署名されたメッセージの解析を通じてこのプロセスが展開されているかどうかを判定する方法はない。
【００７４】
ビットコインのための分散型署名スキームを構築することにおいて、本発明は、人々又はシステムのグループが、個人が自分で署名を生成することができないように鍵を安全に保持することを可能にする。拡張される場合に、このスキームはまた、ビットコインの秘密鍵自体及びシェアの夫々の安全な回復も可能にする。グループにより生成された署名は、既存のプロトコルから生成されたものと区別不可能である。そのようなものとして、署名検証は、それが標準のトランザクションを使用して一人の署名者により成立されたかのようなままである。
【００７５】
ｎ人の参加者のグループ又はｍ個の参加者グループによって秘密鍵が共有されるということで、信頼性のこのような向上が実現される。トランザクションの署名には閾数の参加者が必要とされ、最小閾値を満足する参加者又は参加者グループの任意の連合が署名動作を実行することができる。重要なことに、このプロトコルは、個人又はグループが参加者の連合を作ろうと試みることができる一括処理として、又は同期して成立され得る。
【００７６】
＜背景研究＞
最初に、Shamir［１９７９］が、鍵の分散管理を可能にするディーラーに基づいた秘密分散スキームを紹介した。このスキームに付随する問題は、検証不可能なディーラーを信頼する必然に由来する。このような形式のスキームは、本発明と完全互換であり、本明細書で言及されるプロセスを通じて生成される個々の鍵スライスのグループ分配のために使用され得る。
【００７７】
＜ジョイントランダム秘密分散（ＪＲＳＳ）［Pedersen，１９９２］＞
このプロシージャの明言された目的は、どの参加者も秘密を知ることなく参加者グループが協調して秘密を共有し得る方法を構築することである。各参加者は、彼らの局部的秘密としてランダムな値を選択し、このランダムな値から導出される値を、グループによるシャミアの秘密分散スキーム（Shamir’s  secret  sharing  scheme）（ＳＳＳＳ）を用いて分配する。次いで、各参加者は、自身を含む参加者から受け取られた全てのシェアを足し合わせる。この和がジョイントランダム秘密シェア（joint  random  secret  share）である。結合された秘密値の秘密性を保つには、一人の正直な参加者によって提供されるランダムさで十分である。この状態は、たとえ（ｎ−１）人の他の全ての参加者がランダムでない秘密値を意図的に選択するとしても、依然として保たれる。
【００７８】
＜ジョイントゼロ秘密分散（ＪＺＳＳ）［Ben-Or，１９８８］＞
ジョイントゼロ秘密分散（Joint  Zero  Secret  Sharing）（ＪＺＳＳ）はジョイントランダム秘密分散（Joint  Random  Secret  Sharing）（ＪＲＳＳ）に似ているが、各参加者がランダムな値に代わるものとして０を共有する点で相違する。この技術により生成されるシェアは、ＪＲＳＳアルゴリズムにおける如何なる潜在的な弱点も解消することに役立つ。
【００７９】
Desmedt［１９８７］は、グループ指向の暗号化の概念を紹介した。このプロセスにより、参加者は、参加者の中の選択された一部しかメッセージを暗号解読することができないようにして人々のグループへメッセージを送ることが可能となった。システムにおいて、メンバーは、送信者が公開鍵を使用してメンバーを知る必要がある場合に知られていることを伝えられ、グループは、メンバーから独立して保持されるそのグループのための単一の公開鍵しかない場合に匿名である。本発明は、両方の方法を統合し、既知及び匿名の送信者及び署名者が同時にグループ内に存在することを可能にする。
【００８０】
＜本発明＞
大きい位数の素数を有する任意の楕円曲線（ＣＵＲＶＥ）、及び素数体Ｚｐにわたって定義される位数ｎの基底点Ｇ∈ＣＵＲＶＥ（Ｚｐ）について、如何なる参加者も閾数に満たないシェアから元の秘密鍵を再生することがでないように、鍵シェアへのＥＣＣ秘密鍵の安全な分配及びその使用を可能にするシステムが構築され得る。
【００８１】
未知の整数ｄＡについて、１≦ｄＡ≦（ｎ−１）の場合に、ＱＡ＝ｄＡ×Ｇを前提として、ｄＡを計算することは極めて困難であることが知られている［Kapoor，２００８］。
【００８２】
本発明の基本的な技術は、閾値暗号化の適用により得られる。このシステムにおいて、ＥＣＤＳＡ秘密鍵は、潜在的なものとしてしか存在せず、どのシステムでも再生される必要がない。それらの複数のシェアの夫々は、拡張可能であって且つグループ及び個人の両方の署名フォーマットの導入を可能にする方法で、複数の参加者［ｐ（ｉ）］に分配される。よって、署名プロセスは、ビットコイン内で展開されるものとは異なる。このプロセスでは、調整参加者ｐ（ｃ）が、グループに分配されるトランザクション及びメッセージ署名を生成する。各参加者は、部分署名を計算するか又はパスするかによって、その秘密鍵シェアの使用に投票することができる。
【００８３】
実際に、パスすることは、反対票（no  vote）と同等である。調整参加者ｐ（ｃ）は、応答を照合し、最低限の閾数の部分署名を受け取った場合にそれらを結合して完全な署名を形成する。
【００８４】
調整参加者ｐ（ｃ）は、反対票を受け入れ、他のパーティからのヌル値に基づき計算を行うか、あるいは、パーティに働きかけて、メッセージに署名するように説得するか、いずれかを行うことができる。プロトコルは、設定された調整者（coordinator）により実装され得るか、あるいは、任意の個人又はグループが、この役割を形成し、署名されるべき閾グループへのトランザクションを提案することができる。本発明は、完全に分散されたＥＣＤＳＡ秘密鍵生成アルゴリズムを提供するようにIbrahim  et  al.［２００３］の研究を拡張する。本願はまた、ビットコインとともに使用される分散型鍵再分散アルゴリズム及び分散型ＥＣＤＳＡ署名アルゴリズムを提示する。鍵再分散アルゴリズムは、新しいものを支持して現在存在する全ての秘密鍵シェアを無効にするために、又は新しい参加者への秘密鍵シェアの再割り当てのために、使用されてよい。このプロトコルは、ＥＣＤＳＡ秘密鍵だけでなく秘密鍵シェアの分散にも及ぶ。この結果は、シェアが構成され、グループ処理として採決され得ることを意味する。
【００８５】
本発明は、信頼できるサードパーティが存在するための全ての要件を取り除く。その結果、既存のプロトコルと完全互換であって且つ更なる拡張性を可能にしながら残りの単一障害点を全て解消するビットコイン用の新しいオーバーレイ及びウォレットを構築することが可能である。本発明はまた、ブラインド署名の導入を可能にするように拡張することもできる。
【００８６】
本発明は、秘密鍵をメモリにロードする必要がないので、信頼できるサードパーティの必要性を取り除くだけでなく、更には、広範囲の一般的な攻撃を排除する。プロトコルは、必要とされるシェア数及びシェアの分配が使用ケース、経済シナリオ及びリスク要件によって決定されることを可能にするように拡張可能である。
【００８７】
本発明は、全てのサイドチャネル攻撃、従って、あらゆるキャッシュタイミング攻撃を軽減する。このシステムは、Gennaro  et  al.［１９９６］の研究を取り込み、それをＤＳＳから拡張して、如何なるＥＣＤＳＡに基づくアプリケーションでも成功裏に使用され得るようにする。
【００８８】
＜ＥＣＤＳＡ＞
ビットコインは、ｓｅｃｐ２５６ｋ１曲線に基づきＥＣＤＳＡを使用する。ＥＣＤＳＡは、最初に、楕円曲線暗号化（elliptic  curve  Cryptography）（ＥＣＣ）を使用したDiffie-Hellmanに基づく鍵交換のための要件を変更するように、２００３年にＮＩＳＴによって標準化された［ＮＩＳＴ］。ＥＣＣの生成は、他の公開／秘密鍵システムと比べた場合に、鍵サイズ及び処理電力の低減により特に重要であった。劣指数的（sub-exponential）時間アルゴリズムはＥＣＤＬＰについて発見されていない。ＥＣＤＬＰは、扱いにくいことが知られており、楕円曲線離散対数問題（elliptic  curve  discrete  logarithm  problem）を指す［Johnson，２００１］。
【００８９】
本願を通じて使用されるパラメータは、上記の表１で提供されている。
【００９０】
＜安全性の懸案事項＞
システムは、ビット内の現在の制限であるＥＣＤＳＡの安全性によって制限される。現在、ＥＣＤＳＡは、秘密鍵が安全に展開され得る場合に安全なままである。本発明は、鍵の再生成イベントの前に閾数の参加者が危殆化されていることを要求する閾値まで、サイドチャネル攻撃及びメモリ開示攻撃を軽減する。更に、危殆化されていない閾値の大多数は、危殆化された参加者を閾値未満で識別することができる。
【００９１】
停止性問題（Halting  problem）
サービスの中断は、参加者に対してサービス拒否攻撃を仕掛けようと試みる悪意のある敵が加担する可能性がある攻撃の一種である。この攻撃により、参加者は、解析に処理時間を費やすことになる無効な署名、又はその後にドロップされることになる膨大なネットワークメッセージを受け取らざるを得ない。
【００９２】
ＥＣＣ又は署名暗号化（signcryption）に基づくＥＣＣのいずれかを用いて参加者へのメッセージを暗号化する要件は、このような攻撃経路（attack  vector）を軽減する。攻撃者が無効な部分的に署名されたメッセージを送るには、参加者を既に危殆化している必要があるので、このような攻撃はもはや不要である。
【００９３】
ランダム（Randomness）
アルゴリズム２は、たとえ（ｎ−１）人の参加者がランダムな値を選ぶことができないとしても、十分なランダムさが導入されるシナリオを提供する。このプロトコルに追加できるものは、署名及び鍵再生成プロセスへのランダムな値の導入のためにもっぱら設計されたグループオラクルの導入である。この任意のシナリオでは、鍵スライスの夫々が同じプロトコルを用いて生成され得る。例えば、ｍ  ｏｆ  ｎのプライマリスライス要件がある場合に、基礎となる鍵スライスの夫々も、ｍ’  ｏｆ  ｎ’閾値条件を用いて生成及び管理され得る。
【００９４】
このシステムを使用する参加者は、ランダムさをプロトコルに注入する以外何もしない外部オラクルを追加することができる。ｍ’個の鍵スライス（なお、ｍ’＜ｎ−１）を有するユーザは、彼らが保持する鍵スライスに基づき彼らの署名ソリューションを再現し処理することを選択するか、あるいは、ランダムさの導入のため以外に不要である外部オラクルを導入し得る。
【００９５】
各スライスは、ロバスト性及び安全性のために同様に分割され得る。鍵スライスは、ユーザが携帯電話機又はスマートカードのような外部デバイス及びコンピュータで実行されるソフトウェアプログラムでスライスを有するように分配されてよく、それにより、彼らが部分署名を生成するために、ソースの組み合わせは必要とされることになる。
【００９６】
一意のランダムな一時鍵（ephemeral  key）Ｄｋが、鍵が使用されるたびに変更されるランダムな値に基づき生成されるか、あるいは、秘密鍵ｄＡを再現するために情報を使用することが可能であることが重要である。
【００９７】
＜公開署名＞
このプロトコルによるトランザクション署名の主たる目的は、ビットコイントランザクションの分散署名を可能にすることである。ブロックチェーンに公開されたことがない如何なるトランザクションも参加者によって非公開で保持され得る。従って、調整参加者ｐ（ｃ）が機会あるごとに、トランザクションに成功裏に署名するために、必要とされる水準の投票を達成することができなかった場合には、新しいビットコイントランザクションを生成することは不要である。鍵スライスがそれ自体閾値に対して安全である場合には、決済された如何なるトランザクションの所有権も安全なままである。
【００９８】
システムが適切に展開される場合に、危殆化される参加者を（ｋ−１）人までとする能力は、システムを、閾値未満の攻撃に対して安全なままとする。周期的な鍵再生成プロトコル（アルゴリズム２）と結合される場合に、本発明の実施形態は、サイドチャネル攻撃及びメモリ開示に耐えることができる。
【００９９】
＜本発明の方法及び実施＞
本発明の実施形態は、例えば、国際特許公開ＷＯ２０１７／１４５０１６で開示されているように、階層的な導出に基づいてＥＣＣを使用して参加者間で送られる必要がある秘密情報を暗号化するので、必要に応じて、危殆化されるか又は敵意を持たれる可能性がある参加者に対して妥当性確認が行われ得るように、全てのメッセージを、全ユーザへ送られる単一のパケットにまとめることが可能であり且つ望ましい。
【０１００】
署名生成は、調整参加者ｐ（ｃ）によって提案される。デフォルトで、任意の鍵スライスが、調整参加者として機能することができ、要件は、プロトコルの個々の実施に帰着する。使用されるアルゴリズムは、以下で説明され、後の項目は、それらの展開に関して詳細を提供する。
【０１０１】
＜アルゴリズム１  鍵生成＞
ドメインパラメータ（ＣＵＲＶＥ，濃度ｎ，生成元Ｇ）
入力：  ＮＡ
出力：  公開鍵ＱＡ
秘密鍵シェアｄＡ（１），ｄＡ（２），・・・，ｄＡ（ｊ）
（ｊ）人の参加者からのｋ個のスライスの閾値について、構成される鍵セグメントｄＡ（ｉ）は、参加者（ｉ）と、参加者（ｉ）が鍵に（従って、ビットコイントランザクションに）署名するために秘密をやり取りする残りのパーティである、参加者（ｈ）として指名される（ｊ−１）人の参加者とに関連付けて構成される。
【０１０２】
・スキームにおいて、ｊは参加者の総数であり、このとき、ｋ≦ｊ、従って、ｈ＝ｊ−１。  
・従って、（ｋ，ｊ）−閾値分散スキームが存在する。
【０１０３】
アルゴリズム１のための方法は、次の通りである：
１）１≦ｉ≦ｊとして、（ｊ）の中の各参加者ｐ（ｉ）は、ＥＣＣ公開鍵（すなわち、この実施では、ビットコインアドレス）を他の全ての参加者とやり取りする。このアドレスは、グループ識別アドレスであり、如何なる他の目的にも使用される必要がない。
【０１０４】
これは、国際特許出願ＷＯ２０１７／１４５０１６のプロセスから参加者の夫々の間の共有値に基づき導出されたアドレス及び鍵である点が留意されるべきである。
【０１０５】
２）各参加者ｐ（ｉ）は、他の全てのパーティから秘密であるようにランダムな係数を用いて次数（ｋ−１）の多項式ｆｉ（ｘ）を選択する。
【０１０６】
この関数は、多項式自由項として選択される参加者の秘密ａ０（ｉ）の形で第１秘密値を条件とする。この値は共有されない。この値は、ＷＯ２０１７／１４５０１６で開示されているように、導出された秘密鍵を用いて計算される。
【０１０７】
ｆｉ（ｈ）は、点（ｘ＝ｈ）での値について参加者ｐ（ｉ）によって選択された関数ｆ（ｘ）の結果であると定義され、参加者ｐ（ｉ）の基本式は、関数：
【数１】
2020531893.tif 000004
として定義される。
【０１０８】
この式で、ａ０は、各参加者ｐ（ｉ）の秘密であり、共有されない。
【０１０９】
従って、各参加者ｐ（ｉ）は：
【数２】
2020531893.tif 000005
であるように、自由項ａ０（ｉ）がその参加者の秘密として定義されている次数（ｋ−１）の多項式として表される秘密に保たれた関数ｆｉ（ｘ）を有する。
【０１１０】
３）各参加者ｐ（ｉ）は、上記の通りに、Ｐ（ｈ）の公開鍵を用いて参加者Ｐ（ｈ）∀ｈ＝｛１，・・・，（ｉ−１），（ｉ＋１），・・・，ｊ｝への第１シェアｆｉ（ｈ）を暗号化し［Wright，２０１６］、Ｐ（ｈ）が暗号解読するために値をやり取りする。各参加者ｐ（ｉ）は、例えば、国際特許出願ＷＯ２０１７／１４５０１０で開示されている方法によって、各他の参加者ｐ（ｊ）との各々の安全な暗号化された通信チャネルをセットアップする。
【０１１１】
素数ｐの位数ｎの如何なる基底点Ｇ∈Ｅ（Ｚｐ）についてもｎ×Ｇ＝φであることが留意されるべきである。ビットコインの場合に、値は：
楕円曲線式：  ｙ２＝ｘ３＋７
素数モジュロ：  ２２５６−２３２−２９−２８−２７−２６−２４−１
＝FFFFFFFF  FFFFFFFF  FFFFFFFF  FFFFFFFF  FFFFFFFF  FFFFFFFF  FFFFFFFE  FFFFFC2F
基底点＝04  79BE667E  F9DCBBAC  55A06295  CE870B07  029BFCDB  2DCE28D9  59F2815B  16F81798  483ADA77  26A3C465  5DA4FBFC  0E1108A8  FD17B448  A6855419  9C47D08F  FB10D4B8
位数＝FFFFFFFF  FFFFFFFF  FFFFFFFF  FFFFFFFE  BAAEDCE6  AF48A03B  BFD25E8C  D0364141
である。
【０１１２】
そのようなものとして、（ｂ，ｂ１，ｂ２，・・・）として表現可能な整数の任意の組Ｂ：｛ｂｉ∈Ｚｎ｝について、ｂＧ＝［ｂ１Ｇ＋ｂ２Ｇ＋・・・］ｍｏｄｐの場合に、ｂ＝［ｂ１＋ｂ２＋・・・］ｍｏｄｎ。更に、ｂＧ＝［ｂ１ｂ２・・・］Ｇｍｏｄｐの場合に、ｂ＝［ｂ１ｂ２・・・］ｍｏｄｎ。
【０１１３】
Ｚｎが体（field）であり、ｎを法とするラグランジュ補間がＥＣＣ秘密鍵として選択された値に対して有効に行われ得るとすれば、シャミアの秘密分散スキーム（ＳＳＳＳ）［５］がＺｎに対して実施され得るという結論に至る条件が存在する。
【０１１４】
４）各参加者ｐ（ｉ）は、以下の値
【数３】
2020531893.tif 000006
を全参加者へブロードキャストする。
【０１１５】
上記の式中の変数ｈに関連した値は、参加者Ｐ（ｈ）がスキームにおける第３の参加者に相当する場合にはｈ＝３であるように参加者Ｐ（ｈ）のポジションであることができ、あるいは、同様に、整数として参加者によって使用されるＥＣＣ公開鍵の値を表し得る。使用ケース及びシナリオは、いずれの実施についても存在する。後者の実施では、値ｈ＝｛１，・・・，ｊ｝は、個々の参加者の利用される公開鍵にマッピングされた値のアレイによって置換される。
【０１１６】
５）各参加者Ｐ（ｈ≠ｉ）は、受け取られたシェアと、各他の参加者から受け取られるものとの一貫性を検証する。すなわち：
【数４】
2020531893.tif 000007
そして、ｆｉ（ｈ）Ｇは、参加者のシェアと一致する。
【０１１７】
６）各参加者Ｐ（ｈ≠ｉ）は、その参加者（Ｐ（ｈ≠ｉ））によって所有されている受け取られたシェアが、他の受け取られたシェアと一致することを妥当性確認する：
【数５】
2020531893.tif 000008
実際に、このステップは、シェアｆｉ（ｈ）の楕円曲線暗号化されたバージョン（すなわち、ｆｉ（ｈ）Ｇ）に対して、ｆｉ（ｈ）の暗号化されていないバージョンに対して実行された場合に秘密値ａ０（ｉ）を回復する動作を実行して、Ｇａ０（ｉ）を回復することから成る。従って、シャミアの秘密分散スキームの場合に、係数ｂｈは、秘密をその対応するシェアから回復するのに必要なラグランジュ補間係数を表す。
【０１１８】
これに一貫性がない場合には、参加者はプロトコルを拒否し、再び開始する。更には、各参加者ｐ（ｊ）はそれ自身の暗号化された通信チャネルによって参加者ｐ（ｉ）と通信するので、どの参加者ｐ（ｊ）がいずれかの一貫性のないシェアに関連するのかを識別することが可能である。
【０１１９】
７）このとき、参加者ｐ（ｉ）は各々、彼らのシェアｄＡ（ｉ）を、
【数６】
2020531893.tif 000009
として計算する。ここで、Σｈ＝１ｉｆｈ（ｉ）ｍｏｄｎは、各参加者Ｐ（ｈ≠ｉ）から受け取られる各々の第２秘密値ａ０の第２シェアであり、そして、
ＳＨＡＲＥ（ｐ（ｉ））∈Ｚｎ  且つ  ｄＡ（ｊ）
このとき、
【数７】
2020531893.tif 000010
演算Exp−Interpolate（）は、楕円曲線暗号化されたシェアから楕円曲線暗号化された秘密を回復する演算として定義される。この演算は、次のように更に詳細に定義され得る。
【０１２０】
せいぜい（ｋ−１）個の値がヌル（null）であり、残りの値がＧ×αｉの形をとるとして、｛ω１，・・・，ωｊ｝（ｊ≧（２ｋ−１））がセットされ、各αｉが何らかの（ｋ−１）次の多項式Ｈ（・）に存在するならば、その場合に、θ＝Ｇ×Ｈ（０）。
【０１２１】
この値は、θ＝Σｉ∈Ｖωｉ×λｉ＝Σｉ∈Ｖ（Ｇ×Ｈ（ｉ））×λｉβによって計算され得る。この場合に、Ｖは、正しいωｉ値の（ｋ）−サブセットであり、更には、λｉは、結果として起こるラグランジュ補間係数を表す。多項式は、バーレカンプ−ウェルチ復号器を使用することによって計算され得る。
リターン      （ｄＡ（ｉ），ＱＡ）
このとき、ｄＡ（ｉ）は、第３秘密値の第３シェアである。
【０１２２】
参加者ｐ（ｉ）は、このとき、署名を計算することにおいてシェアを使用する。この役割は、署名を収集するプロセスにおいて調整者となるいずれかの参加者又はパーティｐ（ｃ）によって行われ得る。参加者ｐ（ｃ）は変化してよく、トランザクションに署名するために十分なシェアを収集しようとする各試みにおいて同じパーティである必要がない。
【０１２３】
従って、秘密鍵シェアｄＡ（ｉ）←Ｚｎ＊は、他の参加者のシェアを知ることなしに生成された。
【０１２４】
＜アルゴリズム２  秘密鍵の更新＞
入力：  ｄＡ（ｉ）と表される秘密鍵ｄＡの参加者Ｐｉのシェア
出力：  参加者Ｐｉの新しい秘密鍵シェアｄＡ（ｉ）
アルゴリズム２は、秘密鍵を更新すること及びランダムさをプロトコルに加えることの両方のために使用され得る。
【０１２５】
国際特許公開ＷＯ２０１７／１４５０１６のフォーマットの鍵を使用すると、このプロセスは、秘密鍵の再構成又は計算された存在さえなしで、階層的なサブキーの再計算をもたらすことができる。このようにして、正確に展開される場合に、過去に起こった如何なる大規模な不正行為又はデータベース窃盗も排除するビットコインアドレス及び秘密鍵スライスのヒエラルキーを構成することが可能である。
【０１２６】
１）各参加者は、その自由項としてゼロに従う次数（ｋ−１）のランダム多項式を選択する。これは、アルゴリズム１に類似しているが、参加者は、全ての他の参加者の選択された秘密がゼロであることを妥当性確認しなければならない。
【０１２７】
φＧ＝ｎＧ＝０であることが留意されるべきであり、このとき、０は、楕円曲線上で無限遠にある点である。
【０１２８】
この式を用いると、全てのアクティブな参加者は、関数：
【数８】
2020531893.tif 000011
を妥当性確認する。例えば、Feldman（１９８７）を参照されたい。
【０１２９】
ゼロシェアを生成：  ｚｉ←Ｚｎ＊
２）ｄＡ（ｉ）′＝ｄＡ（ｉ）＋ｚｉ
３）リターン：  ｄＡ（ｉ）′
このアルゴリズムの結果は、元の秘密鍵に関連する新しい鍵シェアである。このアルゴリズムの変形は、とり得るビットコインアドレスを変更する必要なしに新しい鍵スライスをもたらす再分散実行に従事するか、あるいは、第１アルゴリズムのランダムさを増大させることができる。このようにして、本発明は、基礎となる秘密鍵を変えずに秘密鍵シェアを追加的にマスキングすることをグループに可能にする。このプロセスは、基礎となるビットコインアドレス及び秘密鍵を変えずに、個々の鍵シェアの継続的な使用及び展開に関連した如何なる潜在的な鍵漏えいも最小限にするために使用され得る。
【０１３０】
＜アルゴリズム３  署名生成＞
ドメインパラメータ：  ＣＵＲＶＥ，濃度ｎ，生成元Ｇ
入力：  署名されるメッセージ  ｅ＝Ｈ（ｍ）
秘密鍵シェア  ｄＡ（ｉ）∈Ｚｎ＊
出力：  署名  ｅ＝Ｈ（ｍ）に対して（ｒ，ｓ）∈Ｚｎ＊
Ａ）分散型鍵生成
１）アルゴリズム１により一時鍵シェアを生成する：
Ｄｋ（ｉ）←Ｚｎ＊
２）アルゴリズム１によりマスクシェアを生成する：
αｉ←Ｚｎ
３）アルゴリズム２によりマスクシェアを生成する：
ｂｉ，ｃｉ←Ｚｎ２
次数２（ｋ−１）の多項式を用いてアルゴリズム２を２度実行することによって、それらのプロトコルで生成されるシェアは、
【数９】
2020531893.tif 000012
と表される。これらは、加算マスク（additive  masks）として使用される。マスキングされる数が次数（ｋ−１）の２つの多項式の積を含むということで、多項式は次数２（ｋ−１）でなければならない。これは、秘密を回復するために必要とされるシェアの必要数を２倍にする。
【０１３１】
ｂ及びｃのシェアは、次いで、参加者によって秘密に保たれる。
【０１３２】
Ｂ）署名生成
４）ｅ＝Ｈ（ｍ）    メッセージｍのハッシュを妥当性確認する。
【０１３３】
５）θｉ＝Ｄｋ（ｉ）αｉ＋βｉｍｏｄｎ及びωｉ＝Ｇ×αｉをブロードキャストする。
【０１３４】
６）
【数１０】
2020531893.tif 000013
ここで、演算μ＝Interpolate（θ１，・・・，θｎ）ｍｏｄｎは、シェアから秘密を回復する演算として定義される。この演算は、次のように更に詳細に定義され得る。
【０１３５】
大部分の（ｋ−１）がヌル（null）であり、且つ、全ての残余値が（ｋ−１）次多項式Ｆ（．）にあるように、｛θ１，・・・，θｎ｝（ｊ≧（２ｋ−１））が集合を形成する場合に、μ＝Ｆ（０）。
【０１３６】
７）
【数１１】
2020531893.tif 000014
８）（Ｒｘ，Ｒｙ）を計算する。ここで
【数１２】
2020531893.tif 000015
９）ｒ＝ｒｘ＝Ｒｘｍｏｄｎ
ｒ＝０の場合に、再び（すなわち、初期分布から）開始する。
【０１３７】
１０）Ｓｉ＝Ｄｋ（ｉ）（ｅ＋ＤＡ（ｉ）ｒ）＋Ｃｉｍｏｄｎ
ｓｉ＝Ｄｋ（ｉ）−１（ｅ＋ｄＡ（ｉ）ｒ）＋ｃｉｍｏｄｎをブロードキャストする。
【０１３８】
１１）Ｓ＝Interpolate（ｓｉ，・・・，ｓｎ）ｍｏｄｎ  Ｓ＝Interpolate（ｓｉ，・・・，ｓｎ）
ｓ＝０の場合に、アルゴリズム３を最初からやり直す（Ａ．１）。
【０１３９】
１２）（ｒ，ｓ）を返す。
【０１４０】
１３）ビットコインでは、スタンダードトランザクションを形成するように（ｒ，ｓ）対によりトランザクションを再構成する。
【０１４１】
図７は、デジタルメッセージの部分署名を表す多項式関数を取得するための従来のバーレカンプ−ウェルチ復号器７０の新規の使用を示す。
【０１４２】
伝送データ内のエラーを訂正するためのバーレカンプ−ウェルチアルゴリズムの従来の使用では、メッセージｍは、符号器７２で連続するｋ個のバイトに分けられ、各バイトｃ０，ｃ１，・・・，ｃｋ−１は、整数モジュロｐとして符号化される。次いで、メッセージは、多項式関数：
【数１３】
2020531893.tif 000016
によって表される。次いで、多項式関数ｍ（ｘ）の値は、（ｘ、ｙ）対の連続を生成するようにｘの多数の既知の値について決定され、次いで、それは、送信器７４によって受信器７６へ送られる。
【０１４３】
受信器７６で受信されたデータＭ（すなわち、受信されたメッセージ）は、元のメッセージを表す多項式関数上の点に対応する対（ａ１，ｂ１，・・・，ａｎ，ｂｎ）を有する：
【数１４】
2020531893.tif 000017
送信された（ｘ，ｙ）対のいくつかが送信中に破損したと考えられる場合に、誤り位置多項式関数（error  locator  polynomial  function）が次のように定義され得る：
Ｐ（ａｉ）≠ｂｉの場合に、Ｅ（ａｉ）＝０
他の場合に、Ｅ（ａｉ）≠０
積多項式関数（product  polynomial  function）Ｑ（ａｉ）がＱ（ａｉ）＝ｂｉＥｉ（ａｉ）と定義される場合に、夫々の受信される（ａｉ，ｂｉ）対について、ｂｉの値が破損しているかどうかにかかわらず、Ｐ（ａｉ）≠ｂｉの場合にＥ（ａｉ）＝０であるから、Ｑ（ａｉ）＝ｂｉＥｉ（ａｉ）＝Ｐ（ａｉ）Ｅｉ（ａｉ）。
【０１４４】
（ａｉ，ｂｉ）のｎ個の既知の値について、Ｅ（ａｉ）は次数ｅの多項式関数であり、Ｐ（ａｉ）は次数（ｋ−１）の多項式関数であるから、Ｑ（ａｉ）は次数（ｅ＋ｋ−１）の多項式関数である。従って、（ａｉ，ｂｉ）の既知の値は、線形系として表され得る：
【数１５】
2020531893.tif 000018
線形系は、２ｅ＋ｋ−１個の未知の項（Ｅ（ｘ）からｅ及びＱ（ｘ）からｅ＋ｋ−１）を含み、その結果として、Ｑ（ａｉ）及びＥ（ａｉ）の係数は、ｎ≧２ｅ＋ｋ−１の場合に決定され得る。Ｑ（ａｉ）及びＥ（ａｉ）が決定され得る場合に、元のメッセージｍ（ｘ）を回復するためにＰ（ａｉ）を決定することが可能である。
【０１４５】
従って、バーレカンプ−ウェルチ復号器７０は、多項式関数上の点を表す対を入力として受け取り、多項式関数を出力する。従って、復号器７０は、多項式によって表される閾数のシェアからその多項式を決定するために、本発明ではラグランジュ補間に代わるものとして使用され得る。
【０１４６】
＜モデル−閾値ＥＣＤＳＡ（Ｔ，ＥＣＤＳＡ）＞
本発明の実施形態に従って、参加者として指名されるｎ個のグループ又は個人のシステムが認められる。各プレイヤーは、単独の参加者若しくはグループ又はそれらの組み合わせとして個人であることができる。参加者ｐ（ｉ）は、一般的に導出された公開鍵計算を用いて識別子（identity）に対してマッピングされてよく、あるいは、参加者ｐ（ｉ）は、個人にマッピングされ直すことなしに、このプロトコルのためにのみ使用される参加者の公開鍵を用いて偽名エンティティ（pseudonymous  entity）として残されてもよい。
【０１４７】
本発明は、スキームの有効なプレイヤー及びメンバーとしての他の参加者の認識を可能にすると同時に、グループ内のメンバーが識別されないままであることを可能にする専用のブロードキャストチャネルを導入する。メッセージが参加者ｐ（ｉ）からブロードキャストされるとき、グループ内のメンバーは、鍵に関連するエンドユーザ又は個人を識別することが必ずしもできなくても、メッセージを認定されたパーティに由来するものとして認める。また、そのようなシステムが保証されているならば、鍵の識別子を個人とリンクすることも可能である。
【０１４８】
プロセスフローは、次のように要約される。
【０１４９】
図１中：
ステップ１）
図１を参照されたい。
【０１５０】
ステップ２）
Ｐｃが生の（raw）トランザクションをグループへ送る。これが妥当性確認する場合に（すなわち、生のトランザクションが署名されるハッシュと一致する場合に）、参加者は、それに署名することによって投票する。
【０１５１】
ステップ３）
肯定判断である場合に、各参加者は、部分署名されたトランザクションを返す。
【０１５２】
図２を参照されたい。
【０１５３】
ステップ４）
閾数の部分署名されたトランザクションが受け取られる場合に、Ｐｃ（又は任意の他の参加者）は完全な署名を再構成する。
【０１５４】
ステップ５）
Ｐｃは、署名されたビットコイントランザクションとしてトランザクションをブロードキャストする。
【０１５５】
メッセージ署名の計算は、変化しない個人によって、又は一時的なブロードキャストパーティを通じて、開始され得る。プロトコル調整者の役割は、署名を収集するプロセスにおいて調整者となる任意の参加者によって又はパーティｐ（ｃ）によって果たされ得る。
【０１５６】
＜鍵生成＞
変更されたＥＣＤＳＡ鍵生成アルゴリズムは、署名スキームを完全に分散させるために使用される。このスキームでは、秘密鍵は、隠匿されたランダム秘密の組み合わせを用いて分散グループによって共同して選択される。
【０１５７】
閾値鍵導出アルゴリズムは、アルゴリズム１で与えられる。
【０１５８】
アルゴリズムは拡張可能であり、アルゴリズムの各ステップは、ディーラーなしであらゆる参加者によって同時に、あるいは、グループ又は個人又はディーラーにおいて、実行され得る。この実施は、現在のビットコインプロトコルと完全互換である。如何なる署名者も、あたかも標準の方法で署名されたかのように外部の観測者又は検証者に見える。結果として、標準フォーマットで又は本発明の高度なプロトコルを用いて鍵が生成されたかどうかを伝える方法はない。
【０１５９】
＜署名生成＞
閾値署名生成の概念は、［Shamir，１９７９］に記載されている。アルゴリズム３は、ＤＨに基づくシステムに基づいており且つＥＣＤＳＡを可能にするように変更されている［Feldman，１９８７］で報告されたプロシージャに関係がある。
【０１６０】
本発明は、ビットコイントランザクションの処理及び署名の両方と完全互換であるようにこのプロセスを拡張する。これはまた、マルチシグトランザクションに及び、必要である複数の署名の夫々に対して、分散される鍵を求めることが可能である。
【０１６１】
＜秘密鍵の再分散＞
このプロセスは、完全分散型鍵再分散スキームを導入するように拡張され得る。この再分散は、現在の参加者がアルゴリズム２を１回実行して、結果として得られたゼロシェアを参加者の秘密鍵シェアに加える場合に、完了される。新しいシェアは、１人の参加者がランダムな値を導入した場合にランダムに分散される。
【０１６２】
このプロセスは、実際の秘密鍵を変更せずに、秘密鍵シェアの付加的なマスキング（additive  masking）を可能にする。
【０１６３】
＜閾値ＥＣＤＳＡ署名導出＞
閾値ＥＣＤＳＡ署名生成システムは、［Shamir，１９７９］で開発されたスキームに従った［Feldman，１９８７］で見られる閾値ＤＳＳ署名生成プロトコルに関するアイディアを用いて導出される。
【０１６４】
＜検証＞
本発明は、如何なる値も既知のビットコインアドレスへ転送される前に、メッセージのオフラインの署名及び検証を可能にする。各パーティは、アルゴリズム１で言及されたプロセスを用いて独立してアドレスを計算及び妥当性確認することができる。従って、全ての参加者は、ビットコインアドレスに資金を出すことを求める如何なる実行よりも前に、彼らのシェアが有効であると認識することができる。このプロセスでは、検証スキームが可能であるが、それらは不要である。無効な署名スライスを送ることを選択する如何なる閾値参加者も、実際には、否定的な投票を行っている。すなわち、メッセージに署名せず、従って、ビットコインでトランザクションを完了しないという投票が、無活動から達成される。その影響は、彼らが全くメッセージ署名しなかったかのようである。
【０１６５】
アルゴリズム２は、参加者が彼らのシェアの一貫性を検証され得る方法を提供する。閾数の悪意のない参加者が保たれる場合には、鍵再生成時に如何なる既知の悪意のある参加者も除外することが可能である。従って、鍵スライスは、新しいスライスを既知の悪意のある参加者に割り当てずに更新可能であり、スライスの再割り当てを更に可能にする方法で鍵のリフレッシュを可能にする。
【０１６６】
信頼性が乏しく、悪意のある敵が標準として予想されるべき環境で、安全なマルチパーティ計算を完了するときに、ｊ／２の受動的な及びｊ／３の能動的な敵［Ben-Or，１９８９；Rabin，１９８８］に対して守る能力を高めながら検証プロセスのロバスト性を更に強化することが可能である。システムのロバスト性は、追加のプロセスを用いて強化され得る：
１．次数（ｋ−１）の多項式Ａ（ｘ）でｊ人の参加者の間で共有される秘密をＤａとする。  
２．個別に参加者ｐ（ｉ）は、グループに利用可能にされるＤａのシェアＤａ（ｉ）及びＤａ（ｉ）Ｇ∀（ｉ∈０，・・・，ｊ）を有する。  
３．全ての参加者は、次に、アルゴリズム２を使用することによって秘密ｂを共有し、それにより、各参加者ｐ（ｉ）は、次数（ｋ−１）の多項式でＤｂの新しい隠匿されたシェアＤｂ（ｉ）を有する。  
【数１６】
2020531893.tif 000019
に留意すべきであり、ここで、Ｄｂ（ｉ）（ｈ）は、参加者ｐ（ｈ≠ｉ）から参加者ｐ（ｉ）にサブミットされたサブシェアである。  
４．参加者は、アルゴリズム２を使用し、それにより、各参加者ｐ（ｉ）は、自由項がゼロに等しい次数（２ｋ−１）の多項式で新しい隠匿されたシェアＺ（ｉ）を有する。  
５．各参加者ｐ（ｉ）は、Ｄａ（ｉ）Ｄｂ（ｉ）（ｈ）Ｇ∀（ｈ∈０，・・・，ｊ）及びＤａ（ｉ）Ｄｂ（ｉ）Ｇをグループへ発行する。  
６．各参加者ｐ（ｈ≠ｉ）は、彼らがＤｂ（ｉ）（ｈ）及びＤａ（ｉ）Ｇを有するということで、Ｄａ（ｉ）Ｄｂ（ｉ）（ｈ）Ｇの妥当性を検証することができる。  
７．また、参加者ｐ（ｉ）は、
【数１７】
2020531893.tif 000020
を更に検証することができる。
【０１６７】
如何なる参加者も、このシステムにより、他の参加者が悪意を持って行動しているかどうかを判定することができる。
【０１６８】
＜分散型鍵生成＞
このスキームによれば安全な方法で分散型自律企業（distributed  autonomous  corporations）（ＤＡＣ）及び分散型自律社会組織（distributed  autonomous  social  organisations）（ＤＡＳＯ）の両方の実施を完了することが可能である。如何なるｋ人のメンバーも、識別スキームを通じて（認証局によって署名及び発行されたデジタル証明書によることを含む。）そのようなグループを表すことができること、及び如何なるｋ人のメンバーも、組織に代わってデジタル署名を構成することができることが示されている。このシステムは、如何なる識別機能もなしで検証し、価値の移動を提供するビットコイントランザクションの署名に拡張される。これらの認証スキームは、安全であることが証明されている。
【０１６９】
＜方法及び実施＞
プロトコルは、国際特許出願ＷＯ２０１７／１４５０１６で開示されている技術に基づき、ＥＣＣを用いて、参加者間で送られる必要がある秘密情報を暗号化するということで、必要に応じて、危殆化されるか又は敵意を持たれる可能性がある参加者に対して妥当性確認が行われ得るように、全てのメッセージを、全ユーザへ送られる単一のパケットにまとめることが可能であり且つ望ましい。
【０１７０】
署名生成は、調整参加者ｐ（ｃ）によって提案される。デフォルトで、任意の鍵スライスが、調整参加者として機能することができ、要件は、プロトコルの個々の実施に帰着する。ｐ（ｃ）による有効な生のトランザクションの生成時に、トランザクション及びトランザクションのメッセージハッシュは、暗号化されたチャネルを用いて全参加者ｐ（ｉ≠ｃ）へブロードキャストされる。
【０１７１】
Ａ．一時鍵シェアＤｋ（ｉ）を生成する。
【０１７２】
参加者は、アルゴリズム１を用いて、次数（ｋ−１）の多項式により、Ｚｎ＊において一様分布した一時鍵Ｄｋを生成して、シェア
【数１８】
2020531893.tif 000021
を生成する。
【０１７３】
Ｄｋのシェアは、各参加者によって個々に保持されながら秘密に保たれる。
【０１７４】
Ｂ．マスクシェアαｉを生成する。
【０１７５】
各参加者は、シェア
【数１９】
2020531893.tif 000022
を生成するように、アルゴリズム１を用いて、次数（ｋ−１）の多項式により、Ｚｎ＊において一様分布したランダムな値αｉを生成する。これらは、Ｄｋ（ｉ）を乗算的にマスキングするために使用される。
【０１７６】
αｉのシェアは秘密であり、対応する参加者によって保持される。
【０１７７】
Ｃ．マスクシェアβｉ，ｃｉを生成する。
【０１７８】
次数２（ｋ−１）の多項式を用いてアルゴリズム２を２度実行する。
【０１７９】
これらのプロトコルで生成されるシェアを
【数２０】
2020531893.tif 000023
と表す。これらは、加算マスクとして使用される。マスキングされる数が次数（ｋ−１）の２つの多項式の積を含むということで、多項式は次数２（ｋ−１）でなければならない。これは、秘密を回復するために必要とされるシェアの必要数を２倍にする。
【０１８０】
ｂ及びｃのシェアは、参加者によって秘密に保たれるべきである。
【０１８１】
Ｄ．メッセージｍ：ｅ＝Ｈ（ｍ）のダイジェストを計算する。
【０１８２】
この値は、ｐ（ｃ）から取得されるトランザクションの受け取られたハッシュに対してチェックされる。
【０１８３】
Ｅ．νｉ＝Ｄｋ（ｉ）αｉ＋βｉｍｏｄｎ及びωｉ＝Ｇ×αｉをブロードキャストする。
【０１８４】
参加者Ｐｉは、νｉ＝Ｄｋ（ｉ）αｉ＋βｉｍｏｄｎ及びωｉ＝Ｇ×αｉをブロードキャストする。
【０１８５】
Ｐｉから応答が受け取られない場合に、使用される値はヌル（null）にセットされる。
【０１８６】
【数２１】
2020531893.tif 000024
が留意されるべきである。
【０１８７】
Ｆ．μ＝Interpolate（ν１，・・・，νｊ）ｍｏｄｎを計算する。
【０１８８】
Interpolate（）［２］：
ここで、大部分の（ｋ−１）がヌル（null）であり、且つ、全ての残余値が（ｋ−１）次多項式Ｆ（．）にあるように、｛ν１，・・・，νｎ｝（ｊ≧（２ｋ−１））が集合を形成する場合に、μ＝Ｆ（０）。
【０１８９】
多項式は、一般の多項式補間を用いて計算され得る。関数“Interpolate（）”は、バーレカンプ−ウェルチ補間［２］であり、ＢＣＨ及びリード・ソロモン符号のためのエラー訂正アルゴリズムとして定義される。これは、http://mathworld.wolfram.com/LagrangeInterpolatingPolynomial.htmlで及びWhittaker,  E.  T.  and  Robinson,  G.  "Lagrange's  Formula  of  Interpolation."  §17  in  The  Calculus  of  Observations:  A  Treatise  on  Numerical  Mathematics,  4th  ed.  New  York:  Dover,  pp.28-30,  1967,  更に、https://jeremykun.com/2015/09/07/welch-berlekamp/で更に詳細に記載されている。
【０１９０】
Ｇ．θ＝Exp−Interpolate（ω１，・・・，ωｊ）を計算する。
【０１９１】
Exp−Interpolate（）［１０］：
せいぜい（ｋ−１）個の値がヌル（null）であり、残りの値がＧ×αｉの形をとるとして、｛ω１，・・・，ωｊ｝（ｊ≧（２ｋ−１））がセットされ、各αｉが何らかの（ｋ−１）次の多項式Ｈ（・）に存在するならば、その場合に、θ＝Ｇ×Ｈ（０）。
【０１９２】
この値は、θ＝Σｉ∈Ｖωｉ×λｉ＝Σｉ∈Ｖ（Ｇ×Ｈ（ｉ））×λｉβによって計算され得る。この場合に、Ｖは、正しいωｉ値の（ｋ）−サブセットであり、更には、λｉは、結果として起こるラグランジュ補間係数を表す。多項式は、バーレカンプ−ウェルチ復号器を使用することによって計算され得る。
【０１９３】
Ｈ．（Ｒｘ，Ｒｙ）＝θ×μ−１を計算する。
【０１９４】
Ｉ．ｒ＝Ｒｘｍｏｄｑを割り当てる。ｒ＝０の場合に、ステップＡへ進む。
【０１９５】
各参加者ｐ（ｉ）は、ステップＪでｒｉの彼らのスライスを計算する。調整者ｐ（ｃ）は、閾数の応答を受け取った場合に、ｓを再構成するためにそれらの値を使用することができる。
【０１９６】
Ｊ．ｓｉ＝Ｄｋ（ｉ）−１（ｅ＋ｄＡ（ｉ）ｒ）＋ｃｉｍｏｄｎをブロードキャストする。
【０１９７】
応答がＰｉから懇願／受信されない場合に、使用される値はヌル（null）にセットされる。
【０１９８】
【数２２】
2020531893.tif 000025
が留意されるべきである。
【０１９９】
Ｋ．ｓ＝Interpolate（ｓ１，・・・，ｓｎ）ｍｏｄｎを計算する。
【０２００】
ｓ＝０の場合に、ステップＩへ進む。
【０２０１】
ここで、関数Interpolate（）は、先に定義された通りである。
【０２０２】
各参加者ｐ（ｉ）は、ステップＪでｒｉの彼らのスライスを計算する。調整者ｐ（ｃ）は、閾数のｓｉ個の応答を受け取った場合に、ｓを再構成するためにそれらの値を使用することができる。
【０２０３】
Ｌ．（ｒ，ｓ）を返す。
【０２０４】
Ｍ．生のトランザクションの署名セクションを置換し、これをネットワークへブロードキャストする。
【０２０５】
＜スライスのディーラー分配＞
上記の実施形態は、グループシェアの導入を通じてはるかに柔軟にされ得る。このようにして、シェアの割り当ては、任意のレベルの階層的深さで、ディーラー、複数のディーラー、ディーラーを含まないグループ、又はそれらの任意の可能な組み合わせの間で分割され得る。
【０２０６】
値ｄＡ及びその対応する鍵スライスｄＡ（ｉ）を、同じアルゴリズムを用いて導出された値により置換することによって、投票のヒエラルキーが生成され得る。例えば、スキームは：
１）ディーラーに基づく分配
２）複数のディーラー
３）ディーラーなし
から導出されるシェアを同時に統合して構築され得る。
【０２０７】
従って、スキームは拡張可能であり、任意のビジネス構造又は組織システムを組み込むように作られ得る。
【０２０８】
スライスの割り当ても拡張可能である。一様でない割り当てプロセスを展開することは、シェアに対する重み付けが加えられることを可能にする。図３に示されるスキームでは、５つの上位メンバーにより仮想組織を構築することが可能である。なお、これには、ｎ＝５の均等に重み付けされたシェアの値をセットする必要はない。この仮想組織において、次のように、上位スキーマのための投票構造をセットすることが可能である：
・閾値（０）    ６１シェア
・ＤＬ０２      １５シェア
・ＤＬ１        １５シェア
・ＤＬ２        １５シェア
・Ｄ１          ４５シェア
・Ｄ２          １０シェア
ここで、ｎ＝１００がセットされている。述べられているように、これは、任意の組織構造を反映することができる任意の値である。図３の組織は、否認（veto）シナリオ（Ｄ１）を可能にし、重層的な割り当ての導入を通じて、想像可能な任意の投票構造を可能にする。
【０２０９】
マルチレベル下位層構造でしばしば見落とされるものは、たとえ秘密のスライスが割り当てられているとしても、それらが等しく分配される必要がなく、更には、サブグループの所有権が他のレベルの所有権を反映する必要がないことである。図３には、閾値の７５％でシェアの総数の４５％を制御する一見強力なブロックが存在する。シェアの下位レベル割り当てがその場合に考えられるならば、シナリオははるかに複雑になる。テーブル上で複数のレベル及び位置で議決権付きシェア（voting  shares）を保持する個人との相互所有権（cross-owenership）を生成することが可能である。
【０２１０】
表３の分布は、（保持されるシェア，閾値，割り当て｛ｎ｝）と定義される。
【０２１１】
表３から、参加者Ｐ１及びＰ２は夫々投票を支配するが、参加者Ｐ４との連携は、Ｐ１又はＰ２が投票を拒否しない限り、Ｐ１又はＰ２のどちらか一方に、十分な投票ブロック（voting  block）をもたらす。
【０２１２】
本発明における投票フォーマットの実施及び構造には制限がないので、これは、安全なバックアップ及び回復方法を確かにしながら、想像され得る如何なる組織的ヒエラルキーも構築するために使用され得る。
【０２１３】
【表２】
2020531893.tif 000026
結果として、より高いレベルの署名シェアに割り当てられる拒否権及び投票権を有することが可能である。本例では、Ｓにおけるシェアの所有権は、ＤＬ０２、Ｄ１Ａ及びＤ２Ａで保持され得る。
【０２１４】
＜安全なマルチパーティ計算＞
ｎ人の参加者ｐ（１），・・・，ｐ（ｉ），・・・，ｐ（ｎ）による安全なマルチパーティ関数計算は、ｘ（ｉ）を含む関数Ｆ（ｘ１，・・・，ｘｉ，・・・，ｘｎ）を評価する必要性に基づく問題である。ｘ（ｉ）は、ｐ（ｉ）によって供給される秘密値であって、参加者ｐ（ｊ≠ｉ）又は外部のパーティがｘ（ｉ）を全く知り得ないように秘密に保たれる必要がある。従って、目的は、計算の正確さを保証することが可能でありながら、各参加者の値の秘密性を保つことである。
【０２１５】
このシナリオで、信頼できるサードパーティＴは、様々な参加者ｐ（ｉ：１・・・ｎ）から全ての値ｘ（ｉ：１・・・ｎ）を収集し、計算を返す。この設計は、暗黙的にＴを信頼することができる理想的な世界でのみ機能する。Ｔが悪意があるか、無法者であるか、あるいは、危殆的であるかのいずれかである何らかの可能性がある場合に、信頼できるサードパーティの使用は実行可能でなくなる。このシナリオは、参加者が投票者であり、信頼できるサードパーティが政府によって行われる既存の選挙を反映する。
【０２１６】
信頼できるサードパーティを用いて安全な方法で計算され得る如何なる値も、個々の秘密ｘ（ｉ）の安全性を保ちながら、信頼できるパーティなしでも計算され得ることが証明されている［Bar-Ilan，１９８９］。ここで提示されるプロトコルは、個人の計算に対して安全であり、危険な参加者の非閾グループが協働することができる場合でさえ安全な計算を提供する。
【０２１７】
＜単純乗算＞
ｎ人の参加者ｐ（ｉ：１・・・ｎ）の間で分配される２つの秘密値ｘ及びｙが存在する場合に、両方の入力変数ｘ及びｙの秘密性を保ち、同時に、参加者ｐ（ｉ）が秘密性を維持することによって個々の秘密ｘ（ｉ：１・・・ｎ）及びｙ（ｉ：１・・・ｎ）が保持されることを確かにしながら、積ｘｙを計算することが可能である。
【０２１８】
このスキームで、ｘ及びｙは、次数（ｋ−１）の多項式を用いて参加者の閾グループの間で夫々共有される。各参加者ｐ（ｉ）は、ｘの次数（ｋ−１）の多項式上のｘ（ｉ：１・・・ｎ）及びｙに対する次数（ｋ−１）の多項式内のｙ（ｉ：１・・・ｎ）の彼らの共有を乗算することができる。
【０２１９】
アルゴリズム２を導入することは、参加者ｐ（ｉ）に、次数（２ｋ−１）の多項式であるｚ（ｉ）のシェアを返す。この値により、各参加者ｐ（ｉ）は、値ｘ（ｉ）ｙ（ｉ）＋ｚ（ｉ）を計算する。
【０２２０】
ｘ（ｉ）ｙ（ｉ）＋ｚ（ｉ）の戻り値は、次数（２ｋ−１）の多項式に対するｘ・ｙの計算の有効なシェアを表す。閾数のシェアのために行動する任意の参加者又は調整者は、個々のシェアの如何なる知識も得ることなしに、ｘ・ｙの真の値を計算するために、各参加者によって保持されている戻り値を使用することができる。
【０２２１】
＜単純加算＞
ｎ人の参加者ｐ（ｉ：１・・・ｎ）の間で分配される２つの秘密値ｘ及びｙが存在する場合に、両方の入力変数ｘ及びｙの秘密性を保ち、同時に、参加者ｐ（ｉ）が秘密性を維持することによって個々の秘密ｘ（ｉ：１・・・ｎ）及びｙ（ｉ：１・・・ｎ）が保持されることを確かにしながら、和ｘ＋ｙを計算することが可能である。
【０２２２】
簡単な乗算のためのプロセスのように、各参加者ｐ（ｉ）は、値ｘ（ｉ）＋ｙ（ｉ）＋ｚ（ｉ）を計算する。ｚ（ｉ）の計算は不要であるが、プロセスに更なるレベルのランダムさ及び秘密性を加える。
【０２２３】
ｘ（ｉ）＋ｙ（ｉ）＋ｚ（ｉ）の戻り値は、次数（２ｋ−１）の多項式に対するｘ＋ｙの計算の有効なシェアを表す。閾数のシェアのために行動する任意の参加者又は調整者は、個々のシェアの如何なる知識も得ることなしに、ｘ＋ｙの真の値を計算するために、各参加者によって保持されている戻り値を使用することができる。
【０２２４】
参加者がそれほど敵対的でない場合に、これは、付加的なステップなしでｘ（ｉ）＋ｙ（ｉ）加算として簡単化され得る。
【０２２５】
＜逆数（inverse）又は逆数（reciprocal）＞
分配された秘密値、すなわち、ｊ人の参加者の間でｘ（ｉ：１・・・ｊ）として秘密に分配されるｘｍｏｄｎについて、値ｘ（ｉ）、ｘ又はｘ−１を開示する如何なる情報も公開せずに、ｘ−１ｍｏｄｎの値に関連した多項式のシェアを生成することが可能である［Gennaro，１９９６］。先と同じく、各参加者ｐ（ｉ）は、次数（ｋ−１）の多項式上でｘ（ｉ）によって表される値ｘのシェアを保持する。
【０２２６】
アルゴリズム１を使用して、各参加者は、次数（ｋ−１）の多項式で未知の秘密ｘ・ｙのシェアｘ（ｉ）を生成する。次いで、各参加者は、アルゴリズム２を実行して、次数（２ｋ−１）の多項式でゼロ秘密の（ｋ−１）を計算する。各参加者（２ｋ−１）は、値ｘ（ｉ）ｙ（ｉ）＋ｚ（ｉ）を計算する計算を行う。
【０２２７】
上記のInterpolate（）ルーチンを使用して、各参加者は、μ＝ｘ（ｉ）ｙ（ｉ）＋ｚ（ｉ）の値を計算して、μｉの収集された値から値μを返すことができる。次いで、各参加者は、μ−１ｍｏｄｎの値を計算することができる。
【０２２８】
これらの値は、任意の参加者ｐ（ｉ）が次数（２ｋ−１）の多項式でζｉ＝γｉμ−１を用いてｘｉ−１の関連するシェアを計算することができるほど十分である。バーレカンプ−ウェルチ復号化スキーム［Berlekamp，１９６８］は、このプロセスを完了するために使用され得るいくつかの方法のうちの１つを提供する。
【０２２９】
＜割り当て＞
検証可能且つ立証可能な方法でトランザクションに署名する能力は、非公開で所有権を証明し、更には、ブロックチェーン上で何も公に動かさずに、ビットコイン秘密鍵の所有権及び関連するビットコインアドレスを破棄又は交換する機会をもたらす。このようにして、ビットコインアドレスに資金を提供することができ、そのアドレスの内容は、公的な記録を残さずに移転又は販売され得る。このプロセスは閾値システムであるから、鍵スライスの割り当ては、ブロックチェーン上で追加の決済を記録することなしに安全に実現され得る。
【０２３０】
このようにして、ブロックチェーン上で既に精算されたノートの所有権を、そのノートを処理するプロセスから分離することが可能である。
【０２３１】
＜ＣＬＴＶ＞
ビットコインメッセージ、又はより一般的な用語では、トランザクションは、ＣＬＴＶ［BIP  65］エントリの包含により生成され得る。この追加により、トランザクションは、全ての鍵スライスの壊滅的な喪失が発生した場合、又はエンティティからの複数のスライスが、最小閾値による署名の安全な再構成を可能にしないように失われるか若しくは信用できないと見なされる場合でさえ、回復可能にされ得る。
【０２３２】
これは更に、エンティティがサードパーティサービスを使用しており、サービスが鍵へのアクセスを保持又は拒絶することができないことを確かにすることを望む場合に、可能である。時間に基づくフェイルセーフ（failsafe）でビットコイントランザクションを構成することにおいて、ユーザは、悪意のあるサードパーティ又は危殆化された交換サイト若しくは銀行が彼らの鍵へのアクセスを彼らに強要することができないことを知っている。最悪のシナリオとして、壊滅的なレベルへの危殆化は、ＣＬＴＶ条件に基づき、事前に定義されたアドレスへのトランザクションの時間に基づく逆戻りをもたらすことになる。この事前に定義されたアドレスは、本願で開示されるプロトコルを用いて生成され得る。そのようなものとして、容易に危殆化され得ない一連のトランザクション及び鍵を構成することが可能である。
【０２３３】
＜安全性の懸案事項＞
Benger  et.  al.（２０１４）は、フラッシュ（Flash）及びリロード（reload）方法によるＥＣＤＳＡ秘密鍵回復の一例を提案している。この出来事は、システムＲＡＭ及びキャッシュに対する攻撃の一例にすぎない。これらの方法は、それらが秘密鍵を再構成するということで、シャミアのＳＳＳ［１９７９］のような手順の使用を欠いたままとする。更に、秘密鍵がいつでも再構成される任意のシナリオで、信頼性に対する要件が導入される。このシナリオでは、秘密鍵を保持するエンティティのシステム及びプロセスに依存する必要がある。
【０２３４】
信頼できるパーティがたとえ悪意がないとしても、彼らのプロセスに依存する必要がある。最近の多数の妥協案から分かるように、秘密鍵を再構成することへのこの依存は、攻撃の道を残している。
【０２３５】
既存のＥＣＤＳＡ実装のためのドロップイン置換と、現在のビットコインプロトコルとの完全な透明性及び互換性との両方を備えているために、その実装にはハードフォーク又はソフトフォークが不要であり、実装は、如何なる現在のトランザクションとも区別不可能である。本発明は、回復機能を備えた鍵のグループ署名を可能にする個別の参加者として個人を扱うことができる。一例として、ツー・オブ・ツー（two  of  two）のスキームが４つの鍵スライスを用いて実装可能であり、このとき、オンラインウォレットプロバイダ又は取引所が２つの鍵スライスを保持し、エンドユーザが２つのスライスを保持する。取引所及びユーザは夫々、彼らの鍵スライスに対するツー・オブ・ツーのプロセスを有し、それらは、必要に応じてメッセージの安全な署名のためにお互いに連結して使用され得る。
【０２３６】
図４を参照すると、ビットコイントランザクションのようなブロックチェーントランザクションで使用されるスクリプト（script）４００は、トランザクションを実行するために第１署名４１０及び第２署名４２０の夫々を必要とする。
【０２３７】
これより図５を参照すると、図４のトランザクションの第１署名４１０が、上記のアルゴリズム１によって、３  ｏｆ  ４の多重署名配置に分けられている。この配置では、４つの鍵シェアのうちのいずれか３つが、図４のトランザクションの第１署名４１０をもたらすために必要とされる。４つの鍵シェアは、ユーザが鍵シェア５１０を有し、取引所５２０の２つの分離したエンティティ（例えば、交換機能及びその精算所機能）が夫々各々の鍵シェア５３０、５４０を有し、分離したエスクロー（escrow）動作が鍵シェア５５０を有するように、分配される。
【０２３８】
図６Ａに示されるように、図４のトランザクションの第２署名４２０は、上記のアルゴリズム１、又はＷＯ２０１７／１４５０１０で記載されている方法によって、２  ｏｆ  ３の他住所名配置に分けられている。この配置では、３つの鍵シェアのうちのいずれか２つが、図４のトランザクションの第２署名４２０をもたらすために必要とされる。３つの鍵シェアは、図４のトランザクションの第１署名４１０の鍵シェア５１０を有しているユーザが、携帯電話機で保持される鍵シェア６１０と、スマートカード上の鍵シェア６２０とを更に有し、一方、図４のトランザクションの第１署名４１０の鍵シェア５３０、５４０を有している図５の取引所５２０が、図４のトランザクションの第２署名４２０の鍵シェア６３０を更に有するように、分配される。このようにして様々なパーティ間で図４のトランザクションの分離した署名４１０、４２０の鍵を分配することによって、これは、安全性のこのような改善を達成するために必要とされるリソースの量を有意に増大させることなく、不正署名をもたらすためのいずれかのパーティ間の協働もより一層難しくすることによって、システムの安全性を改善する。
【０２３９】
図６Ｂは、図６Ａの配置の代替実施形態を示し、図中、その実施形態に共通する特徴は、同じ参照番号によって表されている。図６Ｂの配置では、図６Ａの実施形態の鍵シェア６３０が、一対の鍵シェア６４０、６５０によって置換され得る。鍵シェア６４０は、図５の取引所５２０に残り、鍵シェア６５０は、分離したエスクロー動作のような別個のエンティティにより制御される。
【０２４０】
＜おわりに＞
本発明は、グループ署名プロセスの導入により、ビットコインが達成しようとしたものの基礎を形成する。分散型鍵生成システムの結合による耐障害性署名システムの付加は、全ての中央集権化及び信頼要件を除く。
【０２４１】
更に、暗黙的に非中央集権型のシステムの導入は、より堅牢であり且つ回復力のあるプロトコルの生成を可能にする。ＥＣＤＳＡ［Johnson，２００１］とシャミアのＳＳＳ［Shamir，１９７９］との間の互換性により、本発明は、新しい検証可能な秘密分散スキームによりビットコインを拡張するシステムを導入することができた。このシステムは、安全性において何も失うことなく、フェルドマン［Feldman，１９８７］又はペダーセン［Pedersen，１９９２］によって導出されたものよりもはるかに有効である。
【０２４２】
本願では、基本プロトコルの変更を必要とせずにビットコインの機能性を拡張するシステムが記載されてきた。本発明によれば：
１．信頼できるサードパーティは、鍵秘密の選択又は分散のためにもはや必要とされない。  
２．サードパーティの信用に依存しない分散型銀行取引システムが構築され得る。  
３．夫々のメンバー又はメンバーのグループは、保持されている秘密鍵のシェアが、公示されているビットコインアドレス及び公開鍵に対応することを独立して検証し得る。  
４．傍受及び関連する攻撃の影響を軽減するように秘密鍵スライスをリフレッシュするプロトコルが存在する。  
５．信頼できるサードパーティは、トランザクション及びメッセージのグループ署名のために不要である。
【０２４３】
本発明は、機密事項を扱うデータが決してメモリに現れないようにするということで、多くの現存している安全性リスクを完全に解決する。
【０２４４】
上記の実施形態は、本発明を制限するのではなく説明しているのであって、当業者は、添付の特許請求の範囲によって定義される本発明の適用範囲から外れることなしに、多くの代替の実施形態を設計することが可能である点が留意されるべきである。特許請求の範囲において、かっこ内の如何なる参照符号も、特許請求の範囲を制限するものとして解釈されるべきではない。語「有する」（comprising及びcomprises）などは、いずれかの請求項又は明細書の全文に挙げられているもの以外の要素又はステップの存在を除外しない。本明細書中、「有する」（comprises）は、「〜を含むか、又はそれらから成る」（includes  or  consists  of）を意味し、「有する」（comprising）は、「〜を含むか、又はそれらから成る」（including  or  consisting  of）を意味する。要素の単一参照は、そのような要素の複数参照を除外せず、逆もまた同じである。本発明は、いくつかの個別要素を有するハードウェアを用いて、且つ、適切にプログラムされたコンピュータを用いて、実施されてよい。いくつかの手段を列挙している装置クレームでは、それらの手段のうちのいくつかが、ハードウェアの同一アイテムによって具現されてもよい。特定の手段が相互に異なる請求項で挙げられているという単なる事実は、それらの手段の組み合わせが有利に使用され得ないことを示すものではない。
【０２４５】
＜参考文献＞
１）Bar-Ilan,  J.  Beaver,  "Non-Cryptographic  Fault-Tolerant  Computing  in  a  Constant  Number  of  Rounds",  Proc.  of  8th  PODC,  pp.201-209,  1989.
２）Berlekamp,  Elwyn  R.  (1968),  Algebraic  Coding  Theory,  McGraw‐Hill,  New  York,  NY.
３）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)
４）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)
５）BIP  65  OP_CHECKLOCKTIMEVERIFY  https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
６）Chaum,  David  (1983).  "Blind  signatures  for  untraceable  payments"  (PDF).  Advances  in  Cryptology  Proceedings  of  Crypto.  82  (3):  199‐203.
７）Dawson,  E.;  Donovan,  D.  (1994),  "The  breadth  of  Shamir's  secret-sharing  scheme",  Computers  &  Security,  13:  Pp.69‐78
８）Desmedt.  You  (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.
９）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.
１０）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)
１１）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)
１２）Johnson,  D.,  Menezes,  A.,  Vanstone,  S.:  “The  elliptic  curve  digital  signature  algorithm  (ecdsa)”.  International  Journal  of  Information  Security  1(1),  36‐63  (2001)
１３）Kapoor,  Vivek,  Vivek  Sonny  Abraham,  and  Ramesh  Singh.  "Elliptic  Curve  Cryptography."  Ubiquity  2008,  no.  May  (2008):  1-8.
１４）Knuth,  D.  E.  (1997),  “The  Art  of  Computer  Programming,  II:  Seminumerical  Algorithms”  (3rd  ed.),  Addison-Wesley,  p.505.
１５）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.
１６）Liu,  C.  L.  (1968),  “Introduction  to  Combinatorial  Mathematics”,  New  York:  McGraw-Hill.
１７）National  Institute  of  Standards  and  Technology:  FIPS  PUB  186-4:  “Digital  Signature  Standard”  (DSS)  (2003)
１８）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)
１９）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.  
２０）Shamir,  Adi  (1979),  "How  to  share  a  secret",  Communications  of  the  ACM,  22  (11):  Pp.612‐613
２１）Wright,  C.  &  Savanah,  S.  (2016)  “Determining  a  common  secret  for  two  Blockchain  nodes  for  the  secure  exchange  of  information”    Application  Number:  WO  2017/145016.  2016:  n.  pag.  UK
【図１】
2020531893.tif 000027
【図２】
2020531893.tif 000028
【図３】
2020531893.tif 000029
【図４】
2020531893.tif 000030
【図５】
2020531893.tif 000031
【図６Ａ】
2020531893.tif 000032
【図６Ｂ】
2020531893.tif 000033
【図７】
2020531893.tif 000034
【国際調査報告】
2020531893.tif 000035
2020531893.tif 000036
2020531893.tif 000037