(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-07-19
(45)【発行日】2023-07-27
(54)【発明の名称】デジタル資産へのアクセスを移すためのコンピュータ実施方法及びシステム
(51)【国際特許分類】
H04L 9/08 20060101AFI20230720BHJP
H04L 9/14 20060101ALI20230720BHJP
H04L 9/32 20060101ALI20230720BHJP
【FI】
H04L9/08 A
H04L9/14
H04L9/32 200B
(21)【出願番号】P 2020552031
(86)(22)【出願日】2019-03-26
(86)【国際出願番号】 IB2019052428
(87)【国際公開番号】W WO2019193452
(87)【国際公開日】2019-10-10
【審査請求日】2022-02-28
(32)【優先日】2018-04-05
(33)【優先権主張国・地域又は機関】GB
(73)【特許権者】
【識別番号】318001991
【氏名又は名称】エヌチェーン ライセンシング アーゲー
(74)【代理人】
【識別番号】100107766
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】フレッチャー,ジョン
(72)【発明者】
【氏名】トレヴェサン,トーマス
【審査官】中里 裕正
(56)【参考文献】
【文献】特表2017-515252(JP,A)
【文献】国際公開第2017/145002(WO,A1)
【文献】国際公開第2017/145007(WO,A1)
【文献】国際公開第2017/145010(WO,A1)
【文献】国際公開第2017/145016(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 9/08
H04L 9/14
H04L 9/32
JSTPlus/JMEDPlus/JST7580(JDreamIII)
IEEE Xplore
(57)【特許請求の範囲】
【請求項1】
デジタル資産へのアクセスを移転させる方法であって:
複数の第2
コンピュータシステムの各々によって、第1
コンピュータシステムから、第1ブロックチェーントランザクションを受け取るステップであって、前記第1
コンピュータシステムは、暗号システムの第1秘密-公開鍵ペアの第1秘密鍵を有し、各々の
コンピュータシステムは、前記暗号システムの第2秘密-公開鍵ペアの第2秘密鍵のそれぞれの共有分を有し、前記第1ブロックチェーントランザクションは前記第1秘密鍵で署名される、ステップと;
複数の前記第2
コンピュータシステムによって、前記第1ブロックチェーントランザクションが前記第1秘密鍵で署名されていることを検証するステップと;
前記第2秘密鍵のそれぞれの前記共有分を前記第1ブロックチェーントランザクションに適用して、第1秘密値のそれぞれの共有分を生成するステップであって、前記第1秘密値は、前記第2秘密鍵で署名された第2ブロックチェーントランザクションであり、前記第1秘密値は、前記第1秘密値
の前記共有分
の第1閾値数がアクセス可能であり、前記第1秘密値
の前記共有分
の前記第1閾値数未満はアクセス可能ではないステップと;
前記第1
コンピュータシステム及び複数の前記第2
コンピュータシステムからの前記第1秘密値の少なくとも前記第1閾値数の前記共有分を組み合わせて、前記第1秘密値を生成するステップと;
を含む、方法。
【請求項2】
複数の前記第2
コンピュータシステムの各々は、前記暗号システムのそれぞれの秘密鍵を有する、
請求項1に記載の方法。
【請求項3】
前記第1
コンピュータシステム及び少なくとも
1つの前記第2
コンピュータシステムの間で、前記第1
コンピュータシステムの所有
する前記第2秘密鍵の共有の共有分を分配するステップ、
を更に含む、請求項1又は2に記載の方法。
【請求項4】
前記第2
コンピュータシステムが非応答性になった場合、前記デジタル資産へのアクセスを、前記暗号システムの第3秘密鍵に移転させるステップ、
を更に含む、請求項1乃至3のいずれか一項に記載の方法。
【請求項5】
前記デジタル資産は、所定の時間の間、前記第3秘密鍵の制御下にとどまる、
請求項4に記載の方法。
【請求項6】
複数の前記
コンピュータシステムの間で、前記第2秘密鍵の前記共有分を分配するステップ、
を更に含む、請求項1乃至5のいずれか一項に記載の方法。
【請求項7】
デジタル資産へのアクセスを移転させる方法であって、当該方法は:
第1
コンピュータシステムから複数の第2
コンピュータシステムに第1ブロックチェーントランザクションを送信するステップであって、前記第1
コンピュータシステムは、暗号システムの第1秘密-公開鍵ペアの第1秘密鍵を有し、各々の
コンピュータシステムは、前記暗号システムの第2秘密-公開鍵ペアの第2秘密鍵のそれぞれの共有分を有し、前記第1ブロックチェーントランザクションは、前記第1秘密鍵で署名される、ステップと;
複数の前記第2
コンピュータシステムから、第1秘密値のそれぞれの共有分を受け取るステップであって、前記第1秘密値は、前記第2秘密鍵で署名された第2ブロックチェーントランザクションであり、前記第1秘密値は、前記第1秘密値
の前記共有分の
第1閾値数がアクセス可能であり、前記第1秘密値の
前記共有分
の前記第1閾値数未満はアクセス可能ではなく、前記第2秘密鍵の各々の前記共有分は、前記第1ブロックチェーントランザクションが前記第1秘密鍵で署名されたことを、対応する前記第2
コンピュータシステムによって検証した後、前記第2ブロックチェーントランザクションに適用される、ステップと;
前記第1
コンピュータシステム及び複数の前記第2
コンピュータシステムからの前記第1秘密値の少なくとも前記第1閾値数の前記共有分を組み合わせて、前記第1秘密値を生成するステップと;
を含む方法。
【請求項8】
複数の前記第2
コンピュータシステムの各々は、前記暗号システムのそれぞれの秘密鍵を有する、
請求項7に記載の方法。
【請求項9】
前記第1
コンピュータシステム及び少なくとも
1つの前記第2
コンピュータシステムの間で、前記第1
コンピュータシステムの所有
する前記第2秘密鍵の共有の共有分を分配するステップ、
を更に含む、請求項7又は8に記載の方法。
【請求項10】
前記第2
コンピュータシステムが非応答性になった場合、前記デジタル資産へのアクセスを前記暗号システムの第3秘密鍵に移転させるステップ、
を更に含む、請求項7乃至9のいずれか一項に記載の方法。
【請求項11】
前記デジタル資産は、所定の時間の間、前記第3秘密鍵の制御下にとどまる、
請求項10に記載の方法。
【請求項12】
前記第2秘密鍵の前記共有分を複数の前記
コンピュータシステムの間で分配するステップ、
を更に含む、請求項7乃至11のいずれか一項に記載の方法。
【請求項13】
前記暗号システムは、楕円曲線暗号システムであり、各々の公開-秘密鍵ペアの公開鍵は、秘密鍵と楕円曲線ジェネレータ点の乗算によって、対応する秘密鍵に関連付けられる、
請求項1乃至
12のいずれか一項に記載の方法。
【請求項14】
請求項1乃至
13のいずれか一項に記載の方法を実行するためのコンピュータ実装システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は一般に、データ及びコンピュータベースリソースのセキュリティに関する。より具体的には、本発明は、暗号通貨及び暗号法、並びに楕円曲線暗号法、楕円曲線デジタル署名アルゴリズム(ECDSA:Elliptic Curve Digital Signature Algorithm)及び閾値暗号法にも関する。本発明は、(例えば)ビットコインのようなブロックチェーンで実装される暗号通貨に関連して有利に使用することができるが、この点に限定されず、より広範な適用性を有することができる。本発明は、一実施形態では、閾値デジタル署名スキームを提供するものとして説明され得る。
【背景技術】
【0002】
本出願において、「ブロックチェーン」という用語は、電子的なコンピュータベースの分散台帳のすべての形式を包含するように使用される。これらは、コンセンサスベースのブロックチェーン及びトランザクションチェーン技術、許可及び未許可台帳、共有台帳並びにそれらの変形を含む。ブロックチェーン技術の最も広く知られている用途はビットコイン台帳であるが、他のブロックチェーン実装が提案され、開発されている。本明細書では、単に便宜性及び例示の目的のためにビットコインが参照され得るが、本発明は、ビットコインブロックチェーンでの使用に限定されず、代替的なブロックチェーン実装及びプロトコルが本発明の範囲内にあることに留意されたい。
【0003】
ブロックチェーンは、ブロックにより構成される、コンピュータベースの非集中システムとして実装されるピアツーピア電子台帳であり、ブロックはトランザクションにより構成される。各トランザクションは、ブロックチェーンシステム内の参加者間におけるデジタル資産のコントロールの移転を符号化するデータ構造であり、少なくとも1つの入力と少なくとも1つの出力を含む。各ブロックは、以前のブロックのハッシュを含み、その結果、ブロックは一緒にチェーン化されることになり、その始めからブロックチェーンに書き込まれたすべてのトランザクションの永久的な変更できないレコードを作成する。
【0004】
非集中化の概念は、ビットコイン方法の基礎である。非集中システムは、分散又は集中システムとは異なり、単一障害点(single point of failure)が存在しないという利点を提供する。したがって、それらは、強化されたレベルのセキュリティ及び障害許容力を提示する。このセキュリティは、楕円曲線暗号法及びECDSAのような既知の暗号技術の使用により更に強化される。
【0005】
マルチ署名システムは一般に、デジタル資産へのアクセスを提供するために2以上の当事者の署名を必要とすることによって、セキュリティを強化するようビットコインブロックチェーンで使用される。
【0006】
ECDSA閾値署名スキームは、ビットコインウォレットを保護するための「マルチ署名」システムに取って代わり、向上したセキュリティとプライバシー、並びにより小さな(したがって、コスト的により安価な)トランザクションを提供することができる。非特許文献1及び非特許文献2は、すべての1<t≦nについて、n個の鍵共有保持者のうちの任意のt+1が協力して完全な署名を対話的に生成し得るよう、閾値最適ECDSA署名スキームのバリエーションを提示している。
【0007】
しかしながら、これらのスキームは少なくとも2つの制限にわずらわされる。第1に、これらのスキームは、時間のテストにまだ耐えていない、新たな暗号法及び関連する仮定、例えば完全準同型(fully homomorphic)の暗号スキームに依存する。第2に、それらの複雑性及びゼロ知識プルーフの関与のために-例えば書き込み時にゼロ知識プルーフの生成及び検証だけでも、参加者ごとに約10秒かかるために-それらのスキームは計算コストが高く、したがって遅い。結果として、これらのシステムは、多くのディポジットを保護するために信頼されるべきではなく、(為替操作のように)迅速な署名を必要とする特定の用途には適さない。
【0008】
例えばこれらのスキームは、例えば非特許文献3に開示されるような、高頻度支払いチャネルベースのシステムで使用することができない。暗号通貨交換所(cryptocurrency exchanges)は、双方向支払いチャネルのための1つのアプリケーションであり、その1つでは高速署名が特に望ましい。
【0009】
ECDSA閾値署名の生成のために、より早く低複雑性でよりセキュアなスキームが存在するが、そのようなスキームには特定の制限がある。特に、「2 of 3」スキームのような一般的な選択肢を含め、tとnの特定の組合せが除外される。さらに、これらのスキームでは、部分署名の組合せを通して署名を生成するために必要とされるものよりも少ない鍵共有分(key shares)で、秘密鍵を再構築することが可能である。したがって、「2 of 3」マルチ署名技術を採用するビットコイン交換所によって採用される、セキュアなウォレットサービスシステムに対する改善の必要性が存在する。
【0010】
例えば非特許文献3に開示されるような双方向支払いチャネルは、クライアントが交換所に置かなければならない信用(trust)を大幅に減少させつつ、資産の取引を許可することができる。従来のモデルでは、クライアントは、交換所でビットコイン及びフィアット通貨のディポジットを保持し得る。クライアントが取引するとき、それらが所有するビットコインとフィアットの比率は変化する。しかしながら、これらの比率は、交換所によって記録される取引に依存するため、クライアントは、正確な記録を維持するために交換所を信用しなければならない。言い換えると、ビットコイン(及びトークン化されている場合は、フィアット)のディポジットは、エスクローサービスを採用することによって(ある程度)盗難から保護され得るが、クライアントは、交換所が危険にさらされて取引の記録が失なわれたり変更されたりした場合には、依然としてそれらのディポジットを失う可能性がある。
【0011】
双方向支払いチャネルは、複数の更なる欠点にわずらわされる。双方向支払いチャネルの標準的な実装を考える。アリスとボブは、彼らの間で暗号トークンを送り合いたい。彼らは各々、合意した数のトークンを有する「2 of 2」マルチ署名を提供し、その後、トークンは、チャネルの以前の状態を効率的に無効にする「値(value)」とともに、コミットメントトランザクションを交換することによって送信される(チャネルは更新される)。古いコミットメントトランザクションが、ある当事者によってブロードキャストされた場合、他の当事者は、適切な「値」を含む「違反救済トランザクション(breach remedy transaction)で応答することができ、それによって、チャネル内の残高(balance)全体を請求することができる。
【0012】
アリスとボブのいずれかがチャネルを清算(settle)したいとき、彼らは各々、最新のチャネル状態(いわゆる「ソフト解決策(soft resolution)」)に従って残高を分配するトランザクションに署名することに同意し得る。このようにして、コミットメントトランザクションは、両当事者が協力する限り、ブロードキャストされる必要はない。
【0013】
しかしながら、非特許文献3で説明されるように、支払いチャネルは、多数のチャネルを開いている当事者が長期間非応答性を提示している場合に起こる可能性がある、いわゆる「故障モード」が存在するという点で、主要な未解決の脆弱性を有する。これは、それらに接続している他の当事者に、コミットメントトランザクションをブロードキャストさせようとする可能性があり、当事者の数が多い場合、ブロックチェーンネットワークが圧倒される可能性がある。接続されている当事者が違反救済トランザクションに間に合うように応答することができないことを期待して、悪意ある当事者が、古いコミットメントチャネルをブロードキャストすることによって資金を盗もうとする可能性があるので、そのような状況は、支払いチャネルのコンテキストでは特に危険である。非特許文献3で説明される構成の別の制限は、(チャネルに資金が提供された後、両当事者のうちの一方が、第1コミットメントトランザクションを提供したがらない又は提供することができない可能性を回避するために)Segregated Witnessを必要とする複雑性である。
【0014】
背景
最新の交換セキュリティ
多くの仮想通貨交換所プラットフォームは現在、多くの場合はBitoGoによって供給されるような第三者サービスを介して、ビットコインスクリプトのマルチ署名機能に基づくセキュアなウォレットシステムを採用している。これらのシステムは、クライアント又は為替資金を、「2-of-3」マルチ署名スクリプトで(すなわち、任意の2 of 3公開鍵に対応する有効な署名を供給することによって)取り返す(redeem)ことができる出力下に置く。3つの対応する秘密鍵は、交換所、クライアント及び信頼できる第三者/エスクロー(BitGo)に分配されるであろう。(署名された有効なトランザクションを介する)資金の移動は、次いでi)クライアントと交換所又はii)(クライアントが非協力的であったか、鍵をなくしていた場合)交換所とBitoGo、のいずれかによって許可され得る。BitGoサービスは、交換所からの認証されたAPI要求を介して署名オペレーションを実行するであろう。
【0015】
この保護システムは、BitGo自体及びそのアプリケーションプログラミングインタフェース(API)のセキュリティオペレーション及びポリシーに加えて、いくつかの主要な欠点を有する。第1に、2-of-3マルチ署名(multisig)出力の使用は、クライアントと交換所の双方のプライバシーを危うくする。2-of-3マルチ署名トランザクション出力の数は、出力総数のごく一部であり、その結果、この匿名性の低下は、ブロックチェーンの観察者が、BitGoに関連付けられる資金及び交換ウォレットを識別することをより容易にする。加えて、2-of-3マルチ署名出力の使用は、ブロックチェーン上で内部交換オペレーションも明らかにする。外部観察者は、3つの鍵のうちどの鍵が特定のトランザクションを許可するために使用されたかを、スクリプト内のそれらの位置に基づいて判断することができる。例えば(2-of-3マルチ署名BitGoウォレットシステムを採用した)2016年の$60mのBitfinexハックでは、ビットコインブロックチェーン観察者は、資金を盗むために鍵1及び3が使用されたと判断することができた。さらに、2-of-3マルチ署名の使用の結果、トランザクションサイズがかなり大きくなり、したがって、ブロックチェーン上で確実かつ迅速に確認するためには、より大きなトランザクション(マイナ)報酬(fee)が必要となる。また、2-of-3マルチ署名スクリプトは、ビットコインクライアントでは「非標準」と考えられるので、それらは、P2SH(pay-to-script-hash)フォーマットでリディーム(redeem)スクリプトとして実装されなければならない。P2SHトランザクション出力タイプは基本的に、衝突攻撃(又はいわゆる「誕生日攻撃」)の対象となる可能性があるため、標準のP2PKH(pay-to-public-key-hash)出力よりもセキュアではない。P2SH出力は、ビットコインで160ビットのセキュリティを有し、これは、わずか80ビットのセキュリティで衝突攻撃が防止されることを意味する。このレベルのセキュリティは現時点では、攻撃することは計算上実現可能ではないが、無期限にそのままであるとは限らない。衝突攻撃は、(単一の公開鍵だけを使用する)P2PKH出力では可能でないので、(前画像攻撃(pre-image attack)の場合)160ビットのセキュリティを保持する。
【0016】
閾値署名スキーム
閾値署名プロトコルは、当事者(又はノード)のグループが、任意の時点で秘密鍵を再構築することなく、あるいは任意の参加者が任意の他の当事者の鍵共有分に関して何も学習することなく、閾値m of n鍵共有分(threshold m of n key shares)を使用して、共同してトランザクション署名することを可能にする。そのようなスキームの使用は、トランザクションを許可するために複数の別個の当事者を必要とするシステムにおける単一障害点を防ぐ。
【0017】
閾値署名スキームを、秘密共有分を確立するためのディーラーフリー(又はディーラーレス)プロトコルと組み合わせることができ、この場合、共有される秘密(秘密鍵)はいずれの当事者にも知られない(実際、どの時点でもメモリ内に明示的に存在する必要がない)。しかしながら、グループが、(まだ知られていないが、示唆されている共有秘密鍵に対応する)楕円曲線公開鍵を決定することは可能である。これは、ビットコイン出力を、完全に信頼できない方法で共有グループ公開鍵(及び対応するアドレス)の制御下に置くことができ、個々の当事者が秘密鍵を学習することなく、当事者の閾値が共同するときにのみ、トランザクションに対する署名を生成できることを意味する。
【0018】
楕円曲線デジタル署名アルゴリズム(ECDSA:Elliptic Curve Digital Signature Algorithm)の数学的形式の性質は、このタイプの署名にとってセキュアな閾値スキームを構築することは普通のことではないことを意味する。特に、有効な署名を生成するために必要とされる鍵共有分の数が、完全な秘密鍵を再構築するために必要とされる共有分の数と同じである、効率的かつセキュアな閾値最適スキームを作成することは不可能であることが証明されている。閾値最適ECDSAスキームを構築する第1の方法は非特許文献1で説明されたが、このスキームはかなりの欠点を有する。第1に、これは非常に非効率的である:署名生成は、Paillierの(更に準同型の)暗号化の実施と、一連のゼロ知識プルーフの作成及び検証の双方を必要とし:2-of-2署名では、6回の通信と、(当事者ごとに)最大10秒の計算時間を必要とする。第2に、秘密鍵は倍増的に(multiplicatively)共有される:これは、n-of-n鍵共有のみが可能であり、m<nのm-of-nスキームを実現することは、組合せ鍵共有構造を必要とし、各当事者が、複数の鍵共有分を保持するために必要とされる(各当事者がnm個の鍵共有分を必要とする)。加えて、信頼できるディーラーなしに、秘密鍵を倍増的に共有することは、(シャミアの秘密鍵共有スキームのように)鍵が多項式で共有される場合よりも更に複雑であり、計算コストが高い。
【0019】
より最近では、改善された(が、依然として比較的低い)効率の閾値最適ECDSAスキームが、非特許文献2及び完全準同型暗号システムを採用している非特許文献4で提案されている。この暗号プリミティブは、高度な複雑性を有し、比較的テストされていない仮定(relatively un-tested assumptions)に依拠する。例えば非特許文献5及び非特許文献6で説明されるように、他の最近の完全準同型暗号スキームは、成功した暗号解読(successful cryptanalysis)の対象となっており、実際上破られることにも留意すべきである。
【先行技術文献】
【非特許文献】
【0020】
【文献】S. Goldfeder, R. Gennaro, H. Kalodner, J. Bonneau, J. A. Kroll, E. W. Felten, and A. Narayanan - Securing Bitcoin wallets via a new DSA/ECDSA threshold signature scheme (2015)
【文献】R. Gennaro et al.. Threshold-optimal DSA/ECDSA signatures and an application to Bitcoin wallet security (2016), International Conference on Applied Cryptography and Network Security. ACNS 2016: Applied Cryptography and Network Security pp 156-174
【文献】J Poon; T Dryja; The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments (2016)
【文献】Boneh, Dan, Rosario Gennaro, and Steven Goldfeder. "Using Level-1 Homomorphic Encryption To Improve Threshold DSA Signatures For Bitcoin Wallet Security."
【文献】Bogos, Sonia, John Gaspoz, and Serge Vaudenay. "Cryptanalysis of a homomorphic encryption scheme." ArcticCrypt 2016. No. EPFL-CONF-220692. 2016
【文献】Hu, Yupu, and Fenghe Wang. "An Attack on a Fully Homomorphic Encryption Scheme." IACR Cryptology ePrint Archive 2012 (2012): 561
【発明の概要】
【発明が解決しようとする課題】
【0021】
本発明の好ましい実施形態は、既知のスキームの上記欠点の1つ以上を克服しようとする。
【課題を解決するための手段】
【0022】
本発明は、添付の特許請求の範囲で定義される方法及びシステムを提供する。
【0023】
デジタル資産へのアクセスを移転させる方法が提供されてよく、当該方法は:
複数の第2参加者の各々によって、第1参加者から第1ブロックチェーントランザクションを受け取るステップであって、第1参加者は、暗号システムの第1秘密-公開鍵ペアの第1秘密鍵を有し、各参加者は、暗号システムの第2秘密-公開鍵ペアの第2秘密鍵のそれぞれの共有分を有し、第1ブロックチェーントランザクションは第1秘密鍵で署名される、ステップと;
複数の第2参加者によって、第1ブロックチェーントランザクションが第1秘密鍵で署名されていることを検証するステップと;
第2秘密鍵のそれぞれの共有分を第1ブロックチェーントランザクションに適用して、第1秘密値(secret value)のそれぞれの共有分を生成するステップであって、第1秘密値は、第2秘密鍵で署名された第2ブロックチェーントランザクションであり、第1秘密値は、該第1秘密値の第1閾値数の共有分にはアクセス可能であり、第1秘密値の第1閾値数未満の共有分にはアクセス可能ではない(inaccessible)ステップと;
第1参加者及び複数の第2参加者からの第1秘密値の少なくとも第1閾値数の共有分を組み合わせて、第1秘密値を生成するステップと;
を含む。
【0024】
第2秘密鍵のそれぞれの共有分を第1ブロックチェーントランザクションに適用して、第2秘密鍵で署名された第2ブロックチェーントランザクションのそれぞれの共有分を生成し、署名された第2ブロックチェーントランザクションは、第1秘密値の第1閾値数の共有分にはアクセス可能であり、第1閾値数未満の共有分にはアクセス可能ではなく、第1参加者及び複数の第2参加者からの第1秘密値の少なくとも第1閾値数の共有分を組み合わせて、署名された第2ブロックチェーントランザクションを生成することにより、これは、第2参加者のうちの1人が非アクティブ又は非協力的になるべきである場合、トランザクションの署名を可能にするという利点を提供し、それにより、システムのセキュリティ及び信頼性を改善することができる。また、第1参加者からの第1ブロックチェーントランザクションの受け取りに応答して、第1秘密値の共有分を生成することにより、これは、第1秘密値の少なくとも3つの共有分が生成されるよう、第1秘密値のその共有分が自動的に生成されることを可能にするという更なる利点を提供し、それにより、2 of 3署名スキームのエミュレーションを可能にすることができる。
【0025】
複数の第2参加者の各々は、暗号システムのそれぞれの秘密鍵を有してよい。
【0026】
これは、秘密鍵に対応する公開鍵によって、秘密鍵での署名の検証を可能にするという利点を提供し、それによりシステムのセキュリティを強化する。
【0027】
方法は、第1参加者及び少なくとも1人の第2参加者の間で、第1参加者を所有(in possession)して第2秘密鍵の共有の共有分を分配するステップを更に含んでよい。
【0028】
これは、セキュリティを更に強化するという利点を提供する。
【0029】
方法は、第2参加者が非応答(unresponsive)になった場合、デジタル資産へのアクセスを、暗号システムの第3秘密鍵に移転させるステップを更に含んでよい。
【0030】
デジタル資産は、所定の時間の間、第3秘密鍵の制御下にとどまってよい。
【0031】
方法は、複数の参加者の間で、第2秘密鍵の共有分を分配するステップを更に含んでよい。
【0032】
デジタル資産へのアクセスを移転させる方法が提供されてよく、当該方法は:
第1参加者から複数の第2参加者に第1ブロックチェーントランザクションを送信するステップであって、第1参加者は、暗号システムの第1秘密-公開鍵ペアの第1秘密鍵を有し、各参加者は、暗号システムの第2秘密-公開鍵ペアの第2秘密鍵のそれぞれの共有分を有し、第1ブロックチェーントランザクションは、第1秘密鍵で署名される、ステップと;
複数の第2参加者から、第1秘密値のそれぞれの共有分を受け取るステップであって、第1秘密値は、第2秘密鍵で署名された第2ブロックチェーントランザクションであり、第1秘密値は、該第1秘密値の第1閾値数の共有分にアクセス可能であり、第1秘密値の第1閾値数未満の共有分にはアクセス可能ではなく、第2秘密鍵の各共有分は、第1ブロックチェーントランザクションが第1秘密鍵で署名されたことを、対応する第2参加者によって検証した後、第2ブロックチェーントランザクションに適用される、ステップと;
第1参加者及び複数の第2参加者からの第1秘密値の少なくとも第1閾値数の共有分を組み合わせて、第1秘密値を生成するステップと;
を含む。
【0033】
メッセージにデジタル署名する方法が提供されてよく、当該方法は:
第1秘密値の第1共有分を複数の参加者間で分配するステップであって、第1秘密値は、暗号システムの公開-秘密鍵ペアの秘密鍵であり、該秘密鍵は、第1閾値数の第1共有分によってアクセス可能であり、第1閾値数未満の第1共有分にはアクセス可能ではない、ステップと;
第2秘密値の第2共有分を複数の参加者間で分配するステップであって、第2秘密値は、デジタル署名を生成する際に使用するための短期鍵(ephemeral key)であり、該短期鍵は、第1閾値数の第2共有分によってアクセス可能であり、第1閾値数未満の第2共有分にはアクセス可能ではない、ステップと;
第3秘密値の第3共有分を複数の参加者間で分配するステップであって、各第3共有分は、第4秘密値のそれぞれの第4共有分を生成するためにメッセージに適用されるよう適合され、第4秘密値は、短期鍵を使用して秘密鍵で署名されたメッセージであり、第4秘密値は、第2閾値数の第4共有分によってアクセス可能であり、第2閾値数未満の第4共有分にはアクセス可能ではない、ステップと;
を含む。
【0034】
第3秘密値の第3共有分を複数の参加者間で分配し、各第3共有分は、第4秘密値のそれぞれの第4共有分を生成するためにメッセージに適用されるよう適合され、メッセージが、秘密鍵及び短期鍵で署名されており、第4秘密値は、第2閾値数の第4共有分によってアクセス可能であり、第2閾値数未満の第4共有分にはアクセス可能ではないことにより、これは、デジタル署名共有分のかなりの割合(substantial proportion)があらかじめ生成され、迅速な署名が必要とされるときに、メッセージに適用されることを可能にするという利点を提供する。これは、トランザクションの迅速な非インタラクティブな署名を可能にし、したがって、交換所での使用に適している。
【0035】
各参加者に分配された共有分は、各々の他の参加者にはアクセス可能ではなくてよい。
【0036】
共有分を各参加者に分配するステップは、参加者又は各参加者とのそれぞれの暗号化された通信チャネルを提供することを含んでよい。
【0037】
第1及び/又は第2共有分は、それぞれのシャミア秘密共有スキーム(Shamir secret sharing schemes)によって作成されてよい。
【0038】
複数の第1及び/又は第2共有分は、第1多項式関数(first polynomial function)のそれぞれの値であってよく、対応する秘密値は、第1閾値数の共有分から多項式関数を導出することによって決定され得る。
【0039】
少なくとも1つの第1及び/第2秘密値は、JRSS(joint random secret sharing)によって複数の参加者間で共有されてよい。
【0040】
少なくとも第3秘密値を共有することは、JZSS(joint zero secret sharing)によって生成されるマスキング共有分(masking shares)を共有することを含んでよい。
【0041】
暗号システムは楕円曲線暗号システムであってよく、各公開-秘密鍵ペアの公開鍵は、秘密鍵と楕円曲線ジェネレータ点(elliptic curve generator point)の乗算(multiplication)により、対応する秘密鍵に関連付けられる。
【0042】
本発明の更なる態様によると、上記で定義された方法を実行するためのコンピュータ実装システムが提供される。
【図面の簡単な説明】
【0043】
本発明の実施形態は、限定的意味ではなく単なる例として、添付の図面を参照して説明される。
【
図1】本発明を具現化するデジタル署名システムを示す図である。
【
図2A】
図1のプロセスで使用するためのデジタル署名の共有分を生成するためのシステムを示すである。
【
図2B】
図1のプロセスで使用するためのデジタル署名の共有分を生成するためのシステムを示すである。
【
図3】
図2のプロセスで生成された共有分からデジタル署名を生成するプロセスを示す図である。
【
図4】秘密鍵の共有分を分割するためのプロセスを示す図である。
【
図5】非応答性又は悪意のある参加者の場合にデジタル署名を実行するためのシステムを示す図である。
【発明を実施するための形態】
【0044】
システム概要
図1を参照すると、ブロックチェーントランザクション4の迅速な署名を実行するために本発明を具現化するシステム2は、閾値署名スキームの4つの当事者を有する。当事者は、クライアント6、交換所(exchange)8、信頼できる第三者(TTP:trusted third party)10及びエスクロー12である。各当事者は、それぞれ、それぞれの楕円曲線公開/秘密鍵ペア(y
c,x
c)、(y
Ex,x
Ex)、(y
T,x
T)、(y
Es,x
Es)を有する。先行技術の典型的な「2 of 3」エスクロー構成と比べると、本発明は、追加の当事者であるTTP10を特徴とする。以下で更に詳細に説明されるように、TTP10は、(不良分解能(fault resolution)の場合)エスクロー12を含まないすべての署名の生成に参加することを必要とされる。
【0045】
TTP10は、交換所8との高速(低レイテンシ)かつ信頼性のある接続を有することを必要とされ、TTP10はすべての他の当事者から物理的に分離されているべきである。
【0046】
暗号化と認証の双方を可能にするセキュアな通信チャネルが、クライアント6と交換所8との間、交換所8とTTP10との間、クライアント6とTTP10との間及び交換所8とエスクロー12との間で確立される。これらの通信チャネルは、国際特許出願WO2017/145016号で説明されている方法を使用して追加の通信なしに周期的に更新できる、共有秘密を確立する。
【0047】
当事者は、秘密鍵共有分xnを保持する(閾値秘密鍵xにおいてn=1,2,3,4);共有分は、完全な秘密鍵が単一の場所に存在することが決してないように、以下で更に詳細に説明される方法に従って分散的に(すなわち、信頼できるディーラーなしに)生成される。これらの共有分は(署名初期化とともに)、部分署名(又は署名共有分)sign(メッセージmにおいてn=1,2,3,4)(ビットコイン・トランザクションハッシュ)を生成するために使用されてよい。TTPは、交換所8からの認証された要求に応答して、任意のトランザクションに対する部分署名を提供することになる。「3 of 4」閾値スキームは、実際上、「2 of 3」マルチ署名をエミュレートすることになる。もう1つの可能性は、TTPが部分的に署名するトランザクションのタイプに対する制限が存在することである。例えばTTP10は、特定のアドレスに送信するトランザクションにのみ署名するべきである。この構成は、TTP10がトランザクションに関して何も知る必要がなく、したがって、「ブラインドでそれに署名(sign it blind)」できるという利点を有する。また、このスキームは、BitGoの「2 of 3」構造を最もよく模倣する。
【0048】
当事者2、3及び4は、閾値秘密鍵における彼らの共有分が、保護された「エンクレーブ(enclave)」内で生成されるように、信頼できるハードウェアを使用すると想定される。メッセージを、エンクレーブに送信することができ、メッセージに対する(部分)署名は、特定の条件に合致する場合に出力されてよいが、秘密鍵共有分はエンクレーブを離れることはない。このスキームでは、2つの秘密鍵共有分を所与として、閾値秘密鍵を再構築することができる。しかしながら、信頼できるハードウェアの使用により、攻撃は、両方のハードウェア部分が同じ世代(same generation)の鍵共有分を含むときにハードウェアの2つのセットへの長期の物理的アクセスを必要とするであろう。したがって、そのような攻撃は、実際問題として実現することが非常に難しいであろう。
【0049】
交換所の基本オペレーション
図1を参照すると、交換オペレーションに関連する閾値ウォレットの高レベル機能は以下のとおりである:
1.クライアント6は、ビットコインBを、閾値スキームによって生成された(ディーラーレス)公開鍵に関連付けられる口座(account)にディポジットする。
2.様々な取引が実行され、クライアント6に属するBの比率(proportion)を残す。
3.(クライアント6によって又は交換所8によって)決済(Settlement)が要求される。決済を要求しているのは交換所8であり、資金の正しい分配がトランザクションTで符号化されているとする。
4.T及びSig(T,x
Ex)が交換所8によってTTP10に送信される。
5.Sig(T,x
Ex)が検証された場合、TTP10は、Tに対するそれらの部分署名(sig
3で示される)を交換所8に送信する。TTP10は、T内に含まれる情報を知る必要はなく、実際、そうでなかった場合、セキュリティの観点からより良いであろう。これは、部分的ブラインド署名オペレーションを介して達成され得る。
6.一方、要求が本物と見なされ(Sig(T,x
Ex)が検証され)、それらがTのコンテンツに合意する場合、クライアント6はSig(T,x
C)、sig
1、Sig(sig
1,x
C)を交換所8に送信する。
7.署名が検証された場合、交換所8はsig
2、sig
1、sig
3を結合し、署名Sig(T,x)が検証されたことをチェックし、検証された場合、T、Sig(T,x)はブロックチェーンネットワークにブロードキャストされる。
【0050】
セキュアウォレットプロトコル
このセクションは、セキュアウォレットの作成及びその後の閾値署名オペレーションのためのプロトコルを説明する。プロトコルは、R. Gennaro, S. Jarecki, H. Krawczyk及びT. Rabinによる「Robust threshold DSS signatures」(In International Conference on the Theory and Applications of Cryptographic Techniques, 354-371 (1996))で詳細に説明されている高レベルなプリミティブに関して説明される。
【0051】
ディーラーフリー鍵生成
セキュアウォレットの作成は、(国際特許出願WO2017/145016で説明されるように)スキーム内の4参加者間のセキュアな通信チャネルの再初期化で開始される。
【0052】
交換所8は次いで、共有楕円曲線公開鍵のディーラーフリー生成を調整し、この場合、4参加者の各々が、(次数1の多項式における)対応する秘密鍵の共有分を保持する。秘密鍵を再構築するためにはこれらの4つの共有分のうちの2つで十分であるが、鍵共有分が信頼できる実行環境で保護される場合、これらの参加者のうちの2参加者の共謀では、このオペレーションは不可能である。トランザクションを許可する唯一の可能な方法は、4当事者のうちの3当事者に関与する閾値署名の生成によるものである。
【0053】
鍵生成は、JVRSS(Joint Verifiable Random Secret Sharing)プロトコルを実行し、Exp-Interpolateプロシージャを介して共有多項式及び対応する共有公開鍵yを作成することを含み、各当事者はその多項式における共有分(x
i)を有する。Exp-Interpolateプロシージャは、楕円曲線ジェネレータ点によって乗算される少なくとも閾値数の共有分から、すなわち、閾値数の共有分から共有秘密を回復するために使用される同様の技術(すなわち、ラグランジュ補間)を使用して、楕円曲線ジェネレータ点によって乗算される共有秘密の回復である。秘密共有分の無条件のセキュアな検証(Unconditionally secure verification)は、Pedersenのプロトコル[Pedersen 1991]を実行することによって保証される。このプロセスは
図2に示されている。鍵生成が検証可能に実行されると、クライアント(又は交換所)は、共有公開鍵(yについて、対応するビットコインアドレス)に資金を支払い、これは次いで、交換所(又はクライアント)によって確認される。パラメータrがw
0のx座標から計算されることに留意されたい。
【0054】
短期鍵共有
所与のトランザクションに対して迅速で非インタラクティブな署名生成を可能にするために、署名手順の前に、署名を構築するために必要な短期鍵(k)共有分及び秘密共有乗算(secret share multiplication)を生成することができる。これは、署名が要求されると、各当事者が必要とされるのは、(特定のトランザクションハッシュmを所与として)彼らの署名共有分を計算することだけであることを意味する。その後、その署名共有分を、誰でもブロードキャストして補間し、完全な署名を生成することができる。
【0055】
図2は、この「事前署名」プロシージャを(未知のランダム値を共有する)JRSS(Joint Random Secret Sharing)プロトコル及び(マスキングのために使用される、ランダム共有分でゼロを共有する)JZSS(Joint Zero Secret Sharing)プロトコルに関して示している。
図2に示されるオペレーションは、いずれの当事者も完全な短期鍵を学習することなく、rの値を短期鍵共有分から共同で計算するために実行される。
【0056】
本明細書で説明される共有鍵生成及び「事前署名」構成を並行して同時に実行することができ、これにより通信レイテンシを大いに節約することができる。
【0057】
署名生成
図3に示されるように、(共有公開鍵yの)有効な署名の生成は、3当事者の同意を必要とする(署名は、次数2(t=2)署名共有多項式における3点から補間される)。通常のオペレーションでは、共有分は、クライアント6、交換所8及びTTP10によって生成される。完全な署名補間(ラグランジュ)を任意の当事者によって実行できるが、本実施形態では、最終的なトランザクションをコンパイルしてネットワークにブロードキャストすることになる交換所8(又はクライアント6)によって実行される。
図3は、各当事者が署名共有分を計算し、次いでそれをブロードキャストすることを示している。この共有分は公開(public)とすることができる-それは、秘密鍵又は短期鍵共有分に関する情報又は(ゼロの)マスキング共有分c
iによる任意の他の識別情報を含まない。
図2に示される鍵及び署名共有分を分配するために使用される鍵共有スキームのより詳細な説明は、付録1に記載される。
【0058】
クライアント鍵管理
セキュアな資金に対するディーラーフリー共有鍵からのセキュリティの利点に加えて、クライアント鍵共有分を分割することによって、クライアントのセキュリティを更に強化することができる。このプロセスは
図4に示されている。JVRSS(Joint Verifiable Random Secret Sharing)プロトコルから確立されると、クライアント鍵共有分(x
1)それ自体を2つ又は3つのサブ共有分(sub-shares)に分割することができる。分割は、国際特許出願WO2017/145010で説明されるプロトコルに従って実行される。鍵共有分は分割されると、セキュアに削除される。サブ鍵共有分は、次いで異なるデバイスに送信され、トランザクション署名を許可するために、2因子認証(2FA:two-factor authentication)を可能にする。交換所がクライアントのサブ鍵共有分のうちの1つを格納することによって、更なるセキュリティ強化を達成することができ-したがって、(2FAを介して)クライアントと交換所の双方が、クライアントの部分署名を提供することに同意する必要がある。
【0059】
悪意ある/非応答性当事者の場合における解決策
非応答性クライアント
図5を参照すると、この場合、交換所8は、Tに対する閾値署名を構築するために、エスクロー12を必要としなければならない。状況はBitGoで起こるものと同じである。エスクロー12に参加するよう説得する手順は比較的遅く、複数のチェックを伴う可能性がある(例えば交換所8のセキュリティが危険にさらされている可能性を防ぐために)。追加のセキュリティのために、エスクロー12は、閾値署名の下で保護される特別な「保有口座」(回復アドレス:rec)に資金を移動させるトランザクションに対する部分署名のみを(最初に)提供するように構成されてよく、資金はそこで一定期間の間保持されなければならない。この口座の重要性は、閾値スキームの当事者に対してのみ知られ得る。この予防措置は、クライアント6が誤って非応答性であるとみなされた場合に、クライアント6に介入する時間を与える。
【0060】
悪意あるクライアント
また
図5を参照すると、悪意のあるクライアント6は、無効な署名共有分(すなわち、s
1)を提供することによって、有効な閾値署名の生成(したがって、資金の移動)を妨げるように動作する。3つの署名共有分を組み合わせて完全な署名を形成すると、(共有公開鍵での検証の失敗により)その署名が正しくないことがすぐに明らかになるであろう。この場合、最初のステップは、3つの署名共有分(s
1、s
2又はs
3)のうちのどれが無効であるかを識別する。これを反復的に行うことができる:交換所8、TTP10及びエスクロー12は、回復アドレスへのトランザクションに署名するよう試みることができ、これが失敗した場合、署名はクライアント6、TTP10及びエスクロー12から共有分を生成することができる(すなわち、交換所8の共有分は悪意がある)。あるいは、署名共有検証スキームを用いることができる。
【0061】
本発明は、「2 of 3」マルチ署名技術を用いるビットコイン交換によって用いられるセキュアウォレットサービスシステムが、多項式秘密共有を用いる閾値署名に基づくスキームによって効率的に置換される(そして改善される)ことを可能にする。また、本発明は、(例えば非特許文献1及び非特許文献2とは対照的に)高頻度で署名することを可能にするので、支払いチャネルを介した取引と互換性がある。
【0062】
また、本発明を、非応答性交換の可能性に対してロバストにすることもできる。TTPは、すべてのコミットメントトランザクションを見る(そして、これに対する部分署名を提供する)ので、TTPは常に現在のチャネル状態を知っており、これは、TTPがエスクロー及びクライアントと協力して、交換が非応答になった場合に、ソフト解決策の順序正しいシーケンス(orderly sequence)を提供することができ、したがって、上述の「障害モード」を回避することができる。
【0063】
また、本発明は、オンチェーントラザクション内に第1コミットメントトランザクションを組み込むことによって、第1コミットメントトランザクションを交換することにより、Segregated Witnessの必要性を回避する。エスクローは、これらのトランザクションのブロックチェーンをモニタし、適切な当事者と協力して、関連するトランザクションがタイムアウト前に観察されない場合に払い戻しを提供する。
【0064】
当事者のいずれかの利用可能性及びセキュリティ(したがって、システム全体として)は、(プライベート)「コングレス(Congress)」のメンバ間で閾値秘密鍵の秘密鍵及び/又は共有分を更に共有することによって強化され得ることに留意されたい。例えばエスクローは、必要なECTがブロックチェーン上で観察されない場合に払い戻しを開始してよい。この場合、ブロックの難しさを、コングレスのメンバに属しているTEE内部でチェックすることができ、チャネルに資金提供された後に特定のブロック数内でコミットメントトランザクションが観察されない場合及びそのような場合にのみ、Ghostchainをインスタンス化して、払い戻しトランザクションに対する(部分)署名を構築してよい。
【0065】
上述の実施形態は、本発明を限定するものではなく、例示するものであって、当業者は、添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく、多くの代替的な実施形態を設計することができるであろうことに留意されたい。特許請求の範囲において、括弧内に置かれたいずれの参照符号も、特許請求の範囲を限定するものとして解釈されるべきではない。「備えている(comprising)」及び「備える(comprises)」等の語は、いずれかの請求項又は明細書全体に列挙されるもの以外の要素又はステップの存在を除外しない。本明細書において、「備える(comprises)」は「含む又はから成る」を意味し、「備えている(comprising)」は「含んでいる又はから成っている」を意味する。ある要素の単数形の参照は、そのような要素の複数形の参照を除外せず、また、その逆もそうである。本発明は、いくつかの別個の要素を備えるハードウェアによって及び適切にプログラムされたコンピュータによって実装されてよい。いくつかの手段を列挙しているデバイスの請求項において、これらの手段のいくつかは、1つの同じハードウェアのアイテムによって具現化されてよい。特定の手段が相互に異なる従属請求項に記載されているという単なる事実は、それらの手段の組合せを有利に使用することができないことを示すものではない。
【0066】
付録1 - 鍵共有及び鍵共有生成の詳細な説明
アルゴリズム1 - 鍵生成
ドメインパラメータ(CURVE,カーディナリティn,ジェネレータG)
入力: NA
出力: 公開鍵Q
A
秘密鍵共有d
A(1),d
A(2),...,d
A(j)
(j)参加者からのkスライスの閾値について、鍵(したがって、ビットコイントランザクション)に署名するために、参加者(i)及び参加者(i)が秘密を交換する他の当事者である参加者(h)として指名された(j-1)参加者に関連付けられる構築鍵セグメントd
A(i)が構築される。
・スキームにおいて、jは参加者の総数であり、ここで、k≦j、よってh=j-1である。
・したがって、(k,j)が存在する-閾値共有スキーム。
アルゴリズム1についての方法は以下のとおりである:
1)(j)の各参加者P
(i)(ただし1≦i≦j)は、すべての他の参加者とECC公開鍵を交換する。このアドレスは、グループ識別アドレスであり、任意の他の目的のために使用される必要はない。
2)各参加者P
(i)は、すべての他の当事者には秘密の方法で、ランダムな係数を有する次数(k-1)の多項式f
i(x)を選択する。
この関数は、多項式自由項(polynomial free term)として選択される参加者の秘密
【数1】
の形式の第1秘密値の対象となる。この値は共有されない。
f
i(h)は、点(x=h)における値について参加者p
(i)によって選択された関数f
(x)の結果となるように定義され、参加者p
(i)についての基本方程式は、以下の関数として定義される:
【数2】
この方程式において、a
0は、各参加者P
(i)の秘密であり、共有されない。
したがって、各参加者p
(i)は、
【数3】
となるように、参加者の秘密として定義されている自由項
【数4】
を有する次数(k-1)の多項式として表される、秘密に保持される関数f
i(x)を有する。
3)各参加者p
(i)は、参加者P
(h)(∀h={1,...,(i-1),(i+1),...,j})への第1共有分f
i(h)を、上記のようにP
(h)の公開鍵を使用して暗号化し、P
(h)の値を交換して復号する。各参加者P
iは、例えば国際特許出願WO2017/145010に開示されている方法によって、各他の参加者P
jとのそれぞれのセキュアな暗号化された通信チャネルを設定する。
4)各参加者P
(i)は、以下の値をすべての参加者にブロードキャストする。
【数5】
5)各参加者P
(h≠1)は、受け取った共有分と各他の参加者から受け取ったものとの一貫性を検証する。
すなわち: Σh
Ka
K
(i)G=f
i(g)G
また、このf
i(h)Gは参加者の共有分と一貫している。
6)各参加者P
(h≠1)は、該参加者(P
(h≠1))によって所有され、受け取られた共有分が、他の受け取った共有分と一貫性があることを確認する:
【数6】
実際、このステップは、f
i(h)の暗号化されていないバージョンに対して実行される場合に、Ga
0
(i)を回復するために秘密値a
0
(i)を回復することになるオペレーションを、共有分f
i(h)の楕円曲線暗号化バージョン(すなわち、f
i(h)G)に対して実行することから成る。したがって、シャミア秘密鍵共有スキームの場合、係数b
hは、その対応する共有分から秘密を回復するために必要なラグランジュ補間係数を表す。
これが一貫していない場合、参加者はプロトコルを拒否して再開する。加えて、各参加者P
jは、自身の暗号化された通信チャネルによって参加者P
iと通信するので、どの参加者P
jが、一貫性のない共有分に関連付けられるかを識別することができる。
7)参加者p
(i)は、以下のように、自身の共有分d
A(i)を計算する:
【数7】
ここで、
【数8】
は、各参加者P
(h≠i)から受け取られた第2秘密値a
0に応じた第2共有分である。また、ここで、
【数9】
【数10】
また、ここで、Exp-Interpolate()オペレーションは、楕円曲線暗号化共有分から楕円曲線暗号化秘密を回復するオペレーションとして定義される。
リターン (d
A(i),Q
A)
参加者P(i)は次に、署名を計算する際に共有分を使用する。この役割は、署名を収集するプロセスのコーディネータとしての機能を果たす、任意の参加者又は当事者p
(c)によって実施され得る。当事者p
(c)は異なる可能性があり、トランザクションに署名をするために十分な共有を収集する各試行において同じ当事者である必要はない。
したがって、秘密鍵共有分
【数11】
は、他の参加者の共有分の知識なしに作成されている。
【0067】
アルゴリズム2-秘密鍵の更新
入力: d
A(i)と示される、秘密鍵d
Aの参加者P
iの共有分
出力: 参加者P
iの新たな秘密鍵共有分d
A(i)
アルゴリズム2を使用して、秘密鍵を更新し、かつプロトコルにランダム性を追加することができる。
1)各参加者は、その自由項としてゼロを条件とする次数(k-1)のランダム多項式を選択する。これは、参加者が、すべての他の参加者の選択された秘密がゼロであることを確かめなければならないが、アルゴリズムと類似する。
ゼロ共有分を生成する:
【数12】
2)d
A(i)’=d
A(i)+z
i
3)リターン:d
A(i)’
このアルゴリズムの結果は、元の秘密鍵に関連付けられる新たな鍵共有分である。このアルゴリズムのバリエーションにより、第1アルゴリズムのランダム性を高めることが可能であり、ビットコインアドレスの可能性を変更する必要なく、新たな鍵スライスをもたらす再共有エクササイズに従事することも可能である。このようにして、本発明は、基礎となる秘密鍵を変更することなく、グループが、秘密鍵共有分を追加的にマスクすることを可能にする。このプロセスを使用して、基礎となるビットコインアドレス及び秘密鍵を変更することなく、個々の鍵共有分の継続的な使用及び展開に関連付けられる潜在的な鍵漏洩を最小限にすることができる。
【0068】
アルゴリズム3-署名生成
ドメインパラメータ:CURVE,カーディナリティn,ジェネレータG)
入力: 署名すべきメッセージ e=H(m)
秘密鍵共有
【数13】
出力: 署名
【数14】
A)分散鍵生成
1)アルゴリズム1を使用して、短期鍵共有分を生成する:
【数15】
2)アルゴリズム1を使用して、マスク共有分を生成する:
α
i←Z
n
3)アルゴリズム2を使用して、マスク共有分を生成する:
【数16】
b及びcの共有分は、参加者によって秘密に保たれる。
B)署名生成
4)e=H(m) メッセージmのハッシュを検証する
5)ブロードキャスト
【数17】
6)
【数18】
ここで、オペレーション
【数19】
は、共有分から秘密を回復するオペレーションとして定義される。
7)
【数20】
8)(Rx,Ry)を計算する。ここで、
【数21】
9)r=r
x=R
x mod n
r=0の場合、再開する(すなわち、最初の分配から)
10)S
i=D
k(i)(e+D
A(i)r)+C
imod
nをブロードキャストする
11)S=Interpolate(S
i,...,S
n)mod n
s=0の場合、最初(A.1)からアルゴリズム3をやり直す
12)(r,s)を返す
13)ビットコインでは、(r,s)ペアでトランザクションを再構築して、標準のトランザクションを形成する。
【0069】