JP2023522748A - 秘密共有を伴う（ｅｃ）ｄｓａしきい値署名 - Google Patents

秘密共有を伴う（ｅｃ）ｄｓａしきい値署名 Download PDF

Info

Publication number
JP2023522748A
JP2023522748A JP2022564434A JP2022564434A JP2023522748A JP 2023522748 A JP2023522748 A JP 2023522748A JP 2022564434 A JP2022564434 A JP 2022564434A JP 2022564434 A JP2022564434 A JP 2022564434A JP 2023522748 A JP2023522748 A JP 2023522748A
Authority
JP
Japan
Prior art keywords
share
message
signature
participants
participant
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2022564434A
Other languages
English (en)
Inventor
ミカエラ・ペティット
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
nChain Holdings Ltd
Original Assignee
nChain Holdings Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by nChain Holdings Ltd filed Critical nChain Holdings Ltd
Publication of JP2023522748A publication Critical patent/JP2023522748A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3257—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using blind signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3252—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using DSA or related signature schemes, e.g. elliptic based signatures, ElGamal or Schnorr schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/04—Masking or blinding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Algebra (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

メッセージのデジタル署名のシェアを生成するコンピュータ実装方法であって、デジタル署名を生成するために参加者のグループのそれぞれの参加者からのしきい値数の異なる署名シェアが必要とされ、各参加者はそれぞれの秘密鍵シェアを有し、方法は、参加者のうちの第1の参加者によって実行され、第1のメッセージ非依存成分および第1のメッセージ依存成分を生成することであって、メッセージ非依存成分が第1の秘密鍵シェアに基づいて生成され、メッセージ依存成分がメッセージに基づいて生成される、生成することと、第1のメッセージ非依存成分をコーディネータにとって利用可能にさせることと、少なくともしきい値数の署名シェアに基づいて署名を生成するために第1の署名シェアをコーディネータにとって利用可能にさせることであって、第1の署名シェアが少なくともメッセージ依存成分を備える、利用可能にさせることとを備える。

Description

本開示は、メッセージのデジタル署名のシェアを生成する方法、および署名シェアを使用してメッセージのデジタル署名を生成する方法に関する。
公開鍵暗号とは、鍵のペア、すなわち、秘密鍵の所有者にしか知られていない秘密鍵と、対応する秘密鍵に基づいて生成され秘密鍵のセキュリティを損なうことなく配布され得る公開鍵とを使用するタイプの暗号システムである。
公開鍵暗号は、送信者が受信者の公開鍵(すなわち、受信者にしか知られていない秘密鍵に対応する公開鍵)を使用してメッセージを暗号化することを可能にする。暗号化されたメッセージは、次いで、受信者の秘密鍵のみを使用して解読され得る。
同様に、送信者は、たとえば、メッセージが送信者によって送られつつあることを証明するために、かつ/または送信者がメッセージに合意することを示すために、送信者自身の秘密鍵を使用してメッセージに署名することができる。署名者(すなわち、署名を生成する当事者)は、署名者の秘密鍵を使用してメッセージに対してデジタル署名を作成する。署名者の対応する公開鍵を有するどの人も、同じメッセージ、およびメッセージにおけるデジタル署名を使用して、署名が有効に作成されたかどうか、すなわち、署名が確かに署名者の秘密鍵を使用して作られたかどうかを検証することができる。
デジタル署名方式は、通常、3つの手順、すなわち、アルゴリズムを伴う。ランダムな秘密鍵および対応する公開鍵を生成するために、鍵生成アルゴリズムが使用される。メッセージおよび秘密鍵に基づいて署名を生成するために、署名アルゴリズムが使用される。対応する秘密鍵を使用し署名アルゴリズムに従って署名が生成されているかどうかを検証するために、公開鍵およびメッセージが与えられて検証アルゴリズムが使用される。
しきい値署名(threshold signature)方式は、グループの中のしきい値数の参加者が共有秘密鍵の個々のシェアを使用してメッセージに対して(または、メッセージの)デジタル署名を作成することを可能にする。ここで、デジタル署名は、署名されるべきメッセージに基づいて生成される署名である。そのような方式では、しきい値数の参加者がメッセージに対して署名を生成することに合意する場合にしか、署名は作成され得ない。もっと少数の参加者を使用して署名を生成しようとするいかなる試みも、有効な署名を生成しない。したがって、グループによる有効な署名(すなわち、メッセージおよび共有秘密鍵を使用して生成される署名)は、しきい値数の人々に署名を生成することを証明可能に合意させた。このことはまた、秘密鍵を用いて署名を捏造するために、任意の攻撃者がその秘密鍵のしきい値数のシェアを取得する必要があることを暗示する。
しきい値署名シェアの一般的な特徴とは、秘密鍵シェアのうちのいずれかが失われる場合、しきい値数のシェアが依然として利用可能であるという条件で、秘密鍵が依然として復元可能であり得ることである。
1つの特定のデジタル署名アルゴリズムは楕円曲線デジタル署名アルゴリズム(ECDSA:Elliptic Curve Digital Signature Algorithm)である。ECDSA署名にとって2つの一般的なしきい値方式がある。一方のしきい値ECDSA方式は最適でない方式であり、ここで、グループはt+1というしきい値を伴って集合的に共有秘密鍵を所有するが、署名を作成することは、2t+1というもっと大きいしきい値を必要とする。詳細な説明のために、Gennaro, Rら、「Robust threshold DSS signatures」、International Conference on the Theory and Applications of Cryptographic Techniques、シュプリンガー、ベルリン、ハイデルベルグ、1996年を参照されたい。この方式は、以下で「非最適Gennaro方式」と呼ばれる。
他方の一般的なしきい値ECDSA方式は最適な方式であり、ここで、最適とは、署名を作成するためのしきい値が共有秘密鍵のしきい値と同じであることを意味する。詳細な説明のために、Gennaro, RおよびGoldfeder, S.、「Fast multiparty threshold ECDSA with fast trustless setup」、Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security、2018年を参照されたい。この方式は、以下で「最適Gennaro方式」と呼ばれる。
WO2017145010A1
Gennaro, Rら、「Robust threshold DSS signatures」、International Conference on the Theory and Applications of Cryptographic Techniques、シュプリンガー、ベルリン、ハイデルベルグ、1996年 Gennaro, RおよびGoldfeder, S.、「Fast multiparty threshold ECDSA with fast trustless setup」、Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security、2018年
非最適Gennaro方式の利点は、計算と通信ラウンドの両方の観点から効率的であることである。欠点は、秘密鍵を作成するためのしきい値がデジタル署名を生成するためのしきい値よりも小さいことである。このことを伴う問題は、しきい値数の参加者が一体となって署名したことを確信できないことである。すなわち、秘密鍵を使用して署名が計算され得るので、署名を生成するためのしきい値よりも少数の参加者が、秘密鍵を使用して、かつしきい値署名を使用せずに、一体となってメッセージに署名することができる。たとえば、秘密鍵を生成するためのしきい値が2であってよく、署名を生成するためのしきい値が3であってよい。その場合、2人の人間が秘密鍵を、したがって、署名を生成することができ、したがって、しきい値署名を生成するために3人の人間が必要とされるという要件を回避する。
対照的に、最適Gennaro方式の利点は、秘密鍵および署名を生成するためのしきい値に格差がないことである。しかしながら、この方式では、計算および通信ラウンドがもっと大きく、署名の作成がもっと遅く、本方式は良好にスケーリングしない。
したがって、決定的に最適Gennaro方式のような最適なしきい値でありながら、非最適Gennaro方式の計算、記憶容量、および通信の優位性を有するしきい値ECDSA方式が望ましいことになる。
本明細書で開示する一態様によれば、メッセージのデジタル署名のシェアを生成するコンピュータ実装方法が提供され、デジタル署名を生成するために参加者のグループのそれぞれの参加者からのしきい値数の異なる署名シェアが必要とされ、各参加者はそれぞれの秘密鍵シェアを有し、方法は、参加者のうちの第1の参加者によって実行され、第1のメッセージ非依存成分および第1のメッセージ依存成分を生成することであって、メッセージ非依存成分が第1の秘密鍵シェアに基づいて生成され、メッセージ依存成分がメッセージに基づいて生成される、生成することと、第1のメッセージ非依存成分をコーディネータにとって利用可能にさせることと、少なくともしきい値数の署名シェアに基づいて署名を生成するために第1の署名シェアをコーディネータにとって利用可能にさせることであって、第1の署名シェアが少なくともメッセージ依存成分を備える、利用可能にさせることとを備える。
本明細書で開示する別の態様によれば、メッセージのデジタル署名を生成するコンピュータ実装方法が提供され、デジタル署名を生成するために参加者のグループのそれぞれの参加者からのしきい値数の異なる署名シェアが必要とされ、各参加者はそれぞれの秘密鍵シェアを有し、方法は、コーディネータによって実行され、少なくともしきい値数のそれぞれのメッセージ非依存成分を取得することであって、各それぞれのメッセージ非依存成分がそれぞれの秘密鍵シェアに基づいて生成される、取得することと、少なくともしきい値数のそれぞれの署名シェアを取得することであって、各それぞれの署名シェアが少なくともそれぞれのメッセージ依存成分に基づき、各それぞれのメッセージ依存成分がメッセージに基づいて生成される、取得することと、取得された署名シェアの各々および取得されたメッセージ非依存成分の各々に基づいてメッセージの署名を生成することとを備える。
本開示の実施形態の理解を支援するために、またそのような実施形態がどのように実行され得るのかを示すために、単に例として添付図面への参照が行われる。
本発明の実施形態による、メッセージの署名を生成するための例示的なシステムを概略的に示す図である。 本発明の実施形態による、メッセージの署名シェアを生成するための例示的な方法を概略的に示す図である。 例示的なブロックチェーントランザクションプロトコルを概略的に示す図である。
前置き
楕円曲線群
楕円曲線Eは、式
y2=x3+ax+b mod p
を満たし、ただし、a,b∈Zpであり、a、bは4a3+27b3≠0を満たす定数である。恒等元である無限遠点Oと一緒にこの式を満たす元(x,y)の集合となるように、この楕円曲線上の群が定義される。この群の中の元に対する群演算は、楕円曲線点加算と呼ばれ、+によって示される。この群はE(Zp)によって、またその次数はnによって示される。
この群演算は、・によって示される点乗算と呼ばれる、元に対する別の演算を定義するために使用され得る。点G∈E(Zp)およびスカラー
Figure 2023522748000002
に対して、それ自体にk回加算された点Gとなるように点k・Gが定義される。
楕円曲線暗号では、スカラーk∈Zn＼{0}となるように秘密鍵が定義され、ただし、Zn＼{0}は集合{1,...,n-1}に対する表記法であり、対応する公開鍵は楕円曲線上の点k・Gである。たとえば、いくつかのブロックチェーンプロトコルでは、secp256k1楕円曲線となるように楕円曲線が選ばれ、値a、b、およびpは、この曲線によって完全に指定される。この群の次数nは、これらの値が与えられて計算されており、これらの値はこの曲線の場合には素数であり、secp256k1規格はまた、この群の生成元として使用されることになる点Gを指定する。
楕円曲線デジタル署名アルゴリズム
秘密鍵aを用いて、メッセージmsgに対して署名を作成するために、以下のステップが行われる。
1. 任意のハッシュ関数であってよい、メッセージダイジェストe=hash(msg)を計算する。たとえば、いくつかの例では、hash(msg)=SHA256(SHA256(msg))であり、ただし、SHA256(■)はSHA-256ハッシュ関数である。代わりに、メッセージが1回だけ、または同じかもしくは異なるハッシュ関数を用いて2回よりも多くハッシュされてよいことに、留意されたい。
2. ランダム整数k∈{1,...,n-1}を選び、ただし、nは、楕円曲線、たとえば、secp256k1曲線の次数である。以下では、kはエフェメラル(ephemeral)秘密鍵と呼ばれる。
3. このエフェメラル秘密鍵(ephemeral private key)に対応するエフェメラル公開鍵k・G=(Rx,Ry)を計算する。
4. r=Rx mod nを計算する。r=0の場合、ステップ2に戻る。
5. エフェメラル鍵の乗法的逆元k-1 mod nを計算する。
6. s=k-1(e+ar) mod nを計算する。s=0の場合、ステップ2に戻る。
7. メッセージmsgに対する署名は(r,s)である。
エフェメラル鍵は秘密にされておかなければならず、そうでなければ、メッセージおよび署名が与えられると秘密鍵は計算され得る。追加として、署名が生成されるたびに、異なるエフェメラル鍵が使用されなければならない。このことが当てはまらない場合、2つの異なる署名およびそれらの対応するメッセージが与えられると秘密鍵aを導出することが可能である。
メッセージmsg、公開鍵P=a・G、および対応する署名(r,s)が与えられると、次いで、以下のステップを完了することによって署名を検証することができる。
1. メッセージダイジェストe=hash(msg)、たとえば、e=SHA256(SHA256(msg))を計算する。
2. nを法とするsの乗法的逆元s-1を計算する。
3. j1=es-1 mod nおよびj2=rs-1 mod nを計算する。
4. 点Q=j1・G+j2・Pを計算する。
5. Q=O、すなわち、無限遠点の場合、署名は無効である。
6. Q≠Oの場合、Q:=(Qx,Qy)とし、u=Qx mod nを計算する。u=rの場合、署名は有効である。
しきい値署名方式では、この秘密鍵aが、しきい値方式グループの中の参加者の間で配送される鍵シェアに分割される。
共同検証可能ランダム秘密共有(Joint Verifiable Random Secret Sharing)
本方式における参加者のうちの少なくとも(t+1)人によってのみ再生成され得る共同秘密を、N人の参加者が作成することを希望することを、想定する。共有秘密を作成するために、以下のステップが行われる。
1. 参加者は、参加者ごとの一意のラベルiに合意する。各参加者iは、(t+1)個の乱数
aij∈R Zn＼{0}、∀j=0,...,t
を生成し、ただし、∈Rは集合Zn＼{0}のランダムに生成された元を意味し、ここで、Zn＼{0}は集合{1,...,n-1}に対する表記法である。次いで、各参加者は、i=1,…,Nに対して、次数tの秘密多項式
fi(x)=ai0+ai1x+...+aitxt mod n
を有する。我々が今後mod n表記法を省略すること、および整数についてのすべての算術演算がnを法として行われることが想定されることに、留意されたい。
2. 各参加者iは、たとえば、参加者jのみとのセキュアな通信チャネルを使用して、値fi(j)を参加者jへ送る。
3. 各参加者iは、共有秘密多項式の自身の個人的な秘密シェアを
Figure 2023522748000003
として計算する。
共有される秘密シェアは形式(i,ai)を有する点であり、ただし、iは本方式における参加者ラベルである。ステップ1～3において説明したような、aの秘密シェアを作成するためのこの方法は、本明細書では参加者iに対してai=JVRSS(i)によって示される。「JVRSS」が、通常、「共同検証ランダム秘密共有」を表し、ステップ4および5を同じく含むことに留意されたい。しかしながら、本明細書全体にわたって、JVRSSは、少なくともステップ1～3を実行することを意味するものと理解され、ここで、ステップ4および5は随意のステップである。
共有される多項式を参加者が生成したからには、参加者は各々、すべての参加者に対する正確な情報を他の参加者が共有していること、および共有された同じ多項式をすべての参加者が有することを、検証することができる。このことは以下のやり方で行われる。
4. 各参加者iは、k=0,...,tに対して、難読化係数
aik・G
をすべての参加者にブロードキャストする。
5. 各参加者iは、fj(i)・Gを計算すること、および
Figure 2023522748000004
であることを検証することによって、各参加者jが多項式点fj(i)を正しく計算していることをチェックする。
この式が多項式ごとに成り立つことをすべての参加者が見出す場合、そのグループは、参加者が全員、共有された同じ多項式を作成していることを集合的に確信することができる。
共有秘密の再構成
共有された多項式の0次である共有秘密aを再構成することを参加者が希望することを想定する。形式
(1,a1),...,((t+1),at+1)
のこの多項式上で(t+1)個の点が与えられると、次いで、共有秘密aを見つけるために、「Lagrange補間」と呼ばれる一般式から導出される
Figure 2023522748000005
を計算する。
公開鍵計算
JVRSSのステップ4において共有された、i=1,...,Nに対するN個の0次秘密多項式係数公開鍵ai0・Gが与えられると、各参加者は、共有秘密aに対応する
Figure 2023522748000006
を使用して、共有された公開鍵Pを計算する。
共有秘密の加算
いかなるエンティティも個々の秘密を知ることなく、各秘密多項式が次数tを有する、N人の参加者のグループの間で共有される2つの共有秘密の加算を計算するために、以下のステップが行われる。
1. 第1の共有秘密aを生成し、ここで、参加者iのシェアは、(t+1)というしきい値を用いて、i=1,...,Nに対してai=JVRSS(i)によって与えられる。
2. 第2の共有秘密bを生成し、ここで、参加者iのシェアは、(t+1)というしきい値を用いて、bi=JVRSS(i)によって与えられる。
3. 各参加者iは、自身の加法的シェア
νi=ai+bi mod n
を計算する。
4. すべての参加者は、自身の加法的シェアνiをすべての他の参加者にブロードキャストする。
5. 各参加者は、シェアνiのうちの少なくとも(t+1)個にわたって補間して、
ν=interpolate(ν1,...,νt+1)=a+b
を計算する。
共有秘密の加算のためのこの方法は、参加者iに対してADDSS(i)によって示され、各参加者iがν=(a+b)を知る結果となる。
共有秘密の積
各秘密多項式が次数tを有する、N人の参加者のグループの間でその両方が共有される2つの共有秘密の積を計算するために、グループは以下のステップを行う。
1. 第1の共有秘密aを生成し、ここで、参加者iのシェアは、i=1,...,Nに対してai=JVRSS(i)によって与えられる。共有秘密多項式は次数tを有し、それを再作成するために(t+1)人の参加者が必要とされることを意味する。
2. 第2の共有秘密bを生成し、ここで、参加者iのシェアはbi=JVRSS(i)によって与えられ、共有秘密多項式は再び次数tを有する。
3. 各参加者は、
μi=aibi
を使用して、自身の乗法的シェアμiを計算する。
4. すべての参加者は、自身の乗法的シェアμiをすべての他の参加者にブロードキャストする。
5. 各参加者は、0においてシェアμiのうちの少なくとも(2t+1)個にわたって補間して、
μ=interpolate(μ1,...,μ2t+1)=ab
を計算する。
2つの共有秘密の積を計算するためのこの方法は、本明細書では参加者iに対してμ=ab=PROSS(i)によって示される。
共有秘密の逆元
共有秘密aの逆元を計算するために、以下のステップが行われる。
1. すべての参加者は共有秘密の積PROSS(i)を計算し、その結果はμ=ab mod nである。
2. 各参加者はμの剰余逆元を計算し、それは、
μ-1=(ab)-1 mod n
という結果になる。
3. 各参加者iは、
Figure 2023522748000007
を計算することによって、自身の逆秘密シェアを計算する。
共有秘密の逆元を計算するためのこの方法は、参加者iに対して、
Figure 2023522748000008
によって示される。
共有秘密鍵の生成および検証
N≧2t+1人の参加者の間の共有秘密鍵aを計算するために、それらのうちのt+1個が、署名を作成するために必要とされ、参加者は、上記で説明したように、t+1というしきい値および公開鍵計算を用いてJVRSSを実行する。その結果は、すべての参加者i=1,...,Nが秘密鍵シェアaiおよび対応する共有された公開鍵P=(a・G)を有することである。
エフェメラル鍵シェア生成
署名において必要とされるようなエフェメラル鍵シェアおよび対応するrを生成するために、しきい値(t+1)の共有秘密鍵aを有するサイズNのグループが、以下のステップを実行する。
1. 共有秘密の逆シェア
Figure 2023522748000009
を生成し、ここで、それを再作成するために(t+1)個のシェアが必要とされる。
2. 各参加者は、kiの検証において共有された難読化係数を使用して
Figure 2023522748000010
を計算し、次いで、
r=x mod n
を計算する。
3. 各参加者iは、
Figure 2023522748000011
を記憶する。
しきい値最適署名
図1は、しきい値最適署名方式、たとえば、しきい値最適ECDSA方式を実施するための、例示的なシステム100を示す。図示のように、システム100は、コーディネータ101、および参加者102のグループを含む、複数の当事者を備える。図1では3人の参加者102しか示されないが、一般に、システムが任意の数の参加者を備えてよいことが諒解されよう。さらに、図1では参加者102とは異なるものとしてコーディネータ101が示されるが、いくつかの実施形態では、コーディネータ101はまた、参加者102のうちの1人、たとえば、第1の参加者102aであってもよい。コーディネータ101および参加者102の各々は、それぞれの計算機器を操作する。
システム100のそれぞれの当事者(すなわち、コーディネータ101および参加者102)のそれぞれの計算機器の各々は、1つまたは複数のプロセッサ、たとえば、1つまたは複数の中央処理ユニット(CPU)、アクセラレータプロセッサ(GPU)、特定用途向けプロセッサ、および/またはフィールドプログラマブルゲートアレイ(FPGA)を備える、それぞれの処理装置を備える。それぞれの計算機器はまた、メモリ、すなわち、1つまたは複数の非一時的コンピュータ可読媒体の形態のコンピュータ可読ストレージを備えてよい。メモリは、1つまたは複数のメモリ媒体、たとえば、ハードディスクなどの磁気媒体、ソリッドステートドライブ(SSD)、フラッシュメモリ、もしくはEEPROMなどの電子媒体、および/または光ディスクドライブなどの光媒体を採用する、1つまたは複数のメモリユニットを備えてよい。それぞれの計算機器は、少なくとも1つのユーザ端末、たとえば、デスクトップコンピュータもしくはラップトップコンピュータ、タブレット、スマートフォン、またはスマートウォッチなどのウェアラブルデバイスを備えてよい。代替または追加として、それぞれの計算機器は、ユーザ端末を介してアクセスされるクラウドコンピューティングリソース(1つまたは複数のサイトにおいて実装された1つまたは複数の物理サーバデバイスのリソースを備えるクラウドコンピューティングリソース)などの、1つまたは複数の他のネットワーク化リソースを備えてよい。システム100の当事者によって実行されるものとして説明される任意の行為が、その当事者によって操作されるそれぞれの計算装置によって実行されてよいことが、諒解されよう。
コーディネータ101は、参加者102のグループのそれぞれの参加者によって生成されるしきい値数の署名シェアを使用して署名を開始する当事者である。すなわち、コーディネータ101は、署名されるべきメッセージに対して署名を生成する。再び、メッセージに対して署名を生成することが、署名が、署名されるべきメッセージに依存すること、または言い換えれば、署名が、署名されるべきメッセージの関数であることを意味するものと、理解されることに留意されたい。コーディネータ101はまた、署名および随意にメッセージをサードパーティ103へ送るか、またはそうでなければ署名を出力する、当事者であってよい。たとえば、サードパーティ103は、証明局、もしくは他の形態の当局、または別のユーザであってよい。他の例では、署名は、たとえば、データベースまたは他の文書の中に記録されてよい。いくつかの例では、署名は、公開されてよく、たとえば、ウェブサイトまたは世間一般にアクセス可能な他の媒体の上に記録されてよい。
コーディネータ101は、署名されるべきメッセージを参加者102へ送信してよい。メッセージは、参加者102のすべてへ、または参加者のサブセットへ、たとえば、しきい値数の参加者へ送信されてよい。図1の例では、参加者のグループは、3人の参加者102a、102b、102cを備える。コーディネータ101は、1人の参加者へメッセージを送信してよく、そうした参加者は、次いで、他の参加者のうちの1、一部、またはすべてにメッセージを転送する。
メッセージは、LAN接続もしくはWAN接続を使用してインターネットを介して、または代替の有線もしくはワイヤレスの通信手段を介して送信されてよい。メッセージは、たとえば、コーディネータ101と各参加者102との間のセキュアな通信チャネルを介して、各参加者102へ個別に送信されてよく、または、たとえば、電子メールもしくは他の手段を介して、全体としてグループへブロードキャストされてもよい。メッセージは、未加工の形態でまたは暗号化済みの形態で送信されてよい。たとえば、メッセージは、1回または複数回ハッシュされてよい。
参加者102のうちの1または複数は、代替手段を介して、すなわち、コーディネータ101からではなく、メッセージを取得し得る。たとえば、メッセージは、参加者102のうちの1人によって生成されてよく、またはそうでなければ、たとえば、世間一般に利用可能であってよい。1または複数の参加者102は、サードパーティ103からメッセージを受信することがある。メッセージを取得する参加者102は、(未加工または暗号化済みの形態をなす)メッセージを1または複数の他の参加者102へ送信してよい。たとえば、第1の参加者102は、第2の参加者102bおよび/または第3の参加者102cへメッセージを送信してよい。
コーディネータ101は、しきい値数の署名シェアを取得する(たとえば、受信する)。図1の例では、しきい値は2であり、第1の参加者102aおよび第2の参加者102bだけがそれぞれの署名シェアを生成することを決める。たとえば、署名シェアを生成する参加者102のうちの1または複数は、自身のそれぞれのシェアを、たとえば、セキュアな通信チャネルを介して、直接コーディネータ101へ送信してよい。代替として、参加者102のうちの1または複数は、自身のそれぞれのシェアをブロードキャストしてよく、かつ/または自身のシェアを世間一般に利用可能にしてよい。上記で述べたように、コーディネータ101はまた、参加者であってもよい。それらの実施形態では、コーディネータ101もそれぞれの署名シェアを生成してよい。その意味では、しきい値数の署名シェアのうちの少なくとも1つを取得することは、少なくとも1つの署名シェアを生成することを意味し、したがって、コーディネータ101は、署名シェアのしきい値数よりも少ない署名シェアしか受信する必要がない。
署名シェアを取得するために、コーディネータ101は、メッセージに対する署名シェアに対する要求を送信してよい。たとえば、コーディネータ101は、署名シェアに対する要求を、参加者102のグループの1、一部、またはすべてへ送信してよい。
少なくともしきい値数の署名シェアを取得していると、コーディネータ101は、取得されたシェアを使用して署名を生成する。コーディネータ101は、次いで、1つまたは複数の他のエンティティに署名をブロードキャストまたは送信してよい。追加または代替として、コーディネータは、署名を記憶してよく、かつ/または、たとえば、電子メールもしくは他の文書の中に、デジタル記録の一部として署名を記録してよい。
署名シェアsiを生成するための方法がここで説明される。方法は、第1の参加者102aの観点から説明されるが、署名シェアを生成する他の各参加者102が、そうした他の参加者102に固有のいくつかのデータを使用するとしても、均等な方法を使用してそうすることが諒解されよう。
各参加者102は、以下のデータアイテム、すなわち、それぞれの秘密鍵シェアai(すなわち、同じ秘密鍵のシェア)、それぞれのエフェメラル秘密鍵シェアki、および共通のエフェメラル公開鍵k・Gに基づいて生成される共有された共通の値rへの、アクセスを有する。共通のエフェメラル公開鍵は、エフェメラル秘密鍵に対応し、すなわち、エフェメラル秘密鍵に基づいて生成される。ここで、値または鍵は、各参加者がその同じ値または鍵へのアクセスを有するという意味で共通であってよい。規定されていない限り、第1の鍵に基づいて第2の鍵を生成することが、第1の鍵自体が知られていることを必ずしも暗示するとは限らないことに、留意されたい。これらのデータアイテムがどのように生成され得るのかという例が、以下で提供される。
第1の参加者102aは、署名されるべきメッセージを取得するか、または署名されるべきメッセージへのアクセスをすでに有する。メッセージは、その未加工の形態(たとえば、平文)をなすか、または暗号化済みもしくは別様に符号化済みの形態(たとえば、暗号文)をなしてよい。第1の参加者102aは、コーディネータから、かつ/または別の参加者102から、(いずれかの形態をなす)メッセージを取得し得る。代替として、第1の参加者102aは、署名されるべきメッセージを生成してよい。
第1の参加者102aは、第1の署名シェアs1を生成する。この文脈における「第1の」が、それぞれ、他の参加者および署名シェアから特定の参加者および特定の署名シェアを区別するための恣意的なラベルとして使用されるにすぎず、第1の参加者102aが署名シェアsiを生成すべき第1の参加者であること、または第1の署名シェアs1が署名シェアsiの順序付きリストの中で最初であることを、必ずしも暗示しないことに留意されたい。
いくつかの実施形態では、第1の署名シェアs1は、第1のメッセージ非依存成分(MIC:message-independent component)および第1のメッセージ依存成分(MDC:message-dependent component)に基づいて生成されてよく、すなわち、それらの関数であり、ここで、再び「第1の」はラベルとして使用されるにすぎない。MICは、メッセージから独立して生成される。すなわち、MICは署名されるべきメッセージの関数でなく(すなわち、MICはメッセージに基づいて生成されず)、MICを生成するためにメッセージの知識は必要とされない。対照的に、MDCは署名されるべきメッセージの関数であり、MDCを生成するためにメッセージの知識が必要とされる。
他の実施形態では、第1の署名は、第1のメッセージ非依存成分(MIC)の関数でなくてよい。これらの実施形態では、第1のメッセージ非依存成分が生成されるとともにコーディネータ101にとって利用可能にされ、たとえば、コーディネータ101へ送信されるかまたは1または複数の参加者102にブロードキャストされる。第1のメッセージ非依存成分(MIC)は、第1の署名シェアに先立って、かつ第1の署名シェアとは別個に、コーディネータと共有されてよい。
コーディネータ101は、少なくともしきい値数の参加者からそれぞれのメッセージ非依存成分(MIC)を取得してよく、(それぞれのメッセージ依存成分(MDC)の関数である)それぞれの署名シェアおよびそれぞれのメッセージ非依存成分(MIC)に基づいて署名を生成してよい。より詳細が以下で提供される。
MICがメッセージの知識を必要としないので、MICは事前計算され得る。言い換えれば、メッセージを取得する前にMICが生成され得る。したがって、各々が、異なるメッセージを署名するための異なるそれぞれの署名シェアs1'を生成する際の使用のための、複数の異なるMICが事前計算され得、ここで、プライム記号(')は、それが第1の署名シェアの異なるインスタンスであることを示す。
第1の署名シェアs1を生成していると、第1の参加者102aは、メッセージに対して署名sを生成するために第1の署名シェアs1をコーディネータ101にとって利用可能にする。第1の参加者102aがコーディネータ101である場合、第1の署名シェアs1をコーディネータ101にとって利用可能にすることは、署名sを生成するための関数に第1の署名シェアs1を出力することを、単に意味してよい。そうでない場合、第1の参加者102aは、第1の署名シェアs1をコーディネータ101へ、またはコーディネータ101に転送するために1または複数の他の参加者102へ送信してよく、または第1の署名シェアs1をブロードキャストしてもよく、あるいはこれらのオプションの組合せを使用してもよい。
上で述べたように、第1の署名シェアs1は、第1のMICおよび第1のMDCに基づいて生成され得る。第1の署名シェアが第1のMICの関数であるかどうかにかかわらず、第1のMICは、第1の秘密鍵シェアa1(すなわち、第1の参加者102aに知られている秘密鍵aのシェア)に基づいて生成される(すなわち、それの関数である)。第1のMICはまた、第1のエフェメラル秘密鍵シェアk1(すなわち、第1の参加者102aに知られているエフェメラル秘密鍵kのシェア)、およびエフェメラル秘密鍵kに対応するエフェメラル公開鍵k・Gに基づいて生成される共有された値rに基づいてもよい。第1のMDCは、(未加工または暗号化済みの形態をなす)メッセージに基づいて生成され(すなわち、それの関数であり)、同じく第1のエフェメラル秘密鍵シェアk1に基づいて生成され得る。MICおよびMDCの変形形態が以下で提供される。
好ましくは、第1の秘密鍵シェアa1は、共同秘密共有方式を使用して、たとえば、上記で説明したJVRSS技法を使用して、計算されてよい。たとえば、第1の参加者102aは、1というインデックスを有してよく、参加者1に対してa1=JVRSS(1)を使用して第1の秘密鍵シェアを生成してよく、ここで、秘密鍵はaによって示される。各参加者は、それぞれの秘密鍵シェアaiを生成してよい。たとえば、第2の参加者102bは、参加者2に対してa2=JVRSS(2)を使用して第2の秘密鍵シェアを生成してよく、以下同様である。
共同秘密共有方式を使用して第1の秘密鍵シェアa1を生成することは、数の集合a1j∈R Zn＼{0}、∀j=0,...,tを生成し、次いで、第1の多項式f1(x)=a10+a11x+...+a1txt mod nを生成することを備えてよく、ここで、数の集合は多項式の係数である。他の参加者102の各々は、それぞれの数の集合を使用してそれぞれの多項式を生成する。たとえば、第2の参加者102bは、第2の多項式f2(x)=a20+a21x+...+a2txt mod nを生成する。参加者102は、次いで、そうした他の参加者のインデックスにおいて評価された、自身のそれぞれの関数の値を他の各参加者へ送信する。たとえば、第1の参加者102aは、第2の参加者102bに対してf1(2)を評価し、次いで、その値を第2の参加者102bへ送信し、第3の参加者102cに対してf1(3)を評価し、次いで、その値を第3の参加者102cへ送信し、以下同様である。第1の参加者102aは、他の参加者102によって第1の参加者のインデックスの関数として生成された、それぞれの値を取得する。その値は、インターネットを介して、または他の手段を介して、送信されてよい。その値は、参加者のそれぞれのペアの間のそれぞれのセキュアな通信チャネルを介して送信されてよい。直接送信するのではなく、1または複数の参加者102(たとえば、第1の参加者102a)が、自身のそれぞれの値をブロードキャストしてよい。少なくともしきい値数の参加者から少なくともしきい値数の値を取得していると、第1の参加者102aは、第1の値、および取得された他の各データ値、たとえば、f2(1)、f3(1)などに基づいて、第1の秘密鍵シェアを生成する。
第1の参加者は、難読化係数の集合に基づいて、対応する公開鍵a・Gを計算してよく、ここで、係数は、各参加者102のそれぞれの秘密鍵シェアaiを生成するために使用される。すなわち、エフェメラル秘密鍵シェアkiを生成するとき、各参加者102は、難読化係数aij・Gを他の各参加者102と共有し得る。係数は、選ばれた楕円曲線上の共通の生成元点Gによって難読化される。これらの難読化係数は、参加者102の間で直接送信されてよく、またはグループにブロードキャストされてもよい。たとえば、第1の参加者102aは、難読化係数a10・G、a11・G、a12・Gなどをブロードキャストしてよい。秘密鍵に対応する公開鍵が、次いで、
Figure 2023522748000012
として計算され得る。
秘密鍵シェアaiが、代替方法を使用して、すなわち、上記で説明したJVRSS方法を使用せずに、生成されてよいことに留意されたい。各参加者はそれぞれの署名シェアsiを生成するために秘密鍵aのシェアを必要とするが、秘密鍵シェアを生成するための特定の方法は、特定のシナリオ、たとえば、参加者のうちの数人が信頼され得るか、参加者の全員が信頼され得るか、それとも参加者のだれも信頼され得ないか、または信頼されるディーラーが鍵シェアを配送するために利用可能であるかどうかなどに適するように選ばれてよい。秘密鍵のシェアを生成するための方法は、本質的に、当技術分野で知られている。同様に、秘密鍵(または、他のそのようなデータ)のシェアを配送するための方法は、本質的に、当技術分野で知られている。そうはいっても、秘密鍵シェアaiはいくつかの方法で生成され得る。たとえば、Shamirの秘密共有方式を使用して、たとえば、秘密鍵シェアaiのうちの1つ、一部、または全部を生成および配送するために、ディーラー(たとえば、コーディネータ)が使用され得る。秘密鍵シェアaiを生成および配送するために使用され得るこのような1つの方式が、WO2017145010A1の中で説明されている。
同様に、以下で説明する秘密鍵シェア、たとえば、エフェメラル秘密鍵シェアki、第1のブラインディング値鍵シェア(blinding value key share)αi、および/または第2のブラインディング値鍵シェアβiのうちの一部または全部を生成するとき、JVRSSの代替形態が使用され得る。
第1のエフェメラル秘密鍵シェアk1は、共同秘密共有方式を使用して、たとえば、上記で説明したJVRSS技法を使用して、計算され得る。たとえば、第1の参加者102aは、1というインデックスを有してよく、参加者1に対してk1=JVRSS(1)を使用して第1のエフェメラル秘密鍵シェアを生成してよく、ここで、エフェメラル秘密鍵はkによって示される。各参加者102は、それぞれのエフェメラル秘密鍵シェアkiを生成し得る。たとえば、第2の参加者102bは、参加者2に対してk2=JVRSS(2)を使用して第2のエフェメラル秘密鍵シェアを生成してよく、以下同様である。
共同秘密共有方式を使用して第1のエフェメラル秘密鍵k1シェアを生成することは、エフェメラル秘密鍵シェアk1を生成するために使用される乱数が、秘密鍵シェアa1を生成するために使用される乱数と比較して異なる数であることを除いて、第1の秘密鍵シェアa1を生成するための、上記で説明した同じステップを備える。
同じ秘密鍵a、および秘密鍵シェアaiが署名ごとに使用されるが、エフェメラル秘密鍵kおよびエフェメラル秘密鍵シェアkiが署名ごとに変化することに留意されたい。
共有された値rは、エフェメラル秘密鍵kに対応するエフェメラル公開鍵k・Gに基づいて生成される。エフェメラル公開鍵(x,y)は、通常、x成分およびy成分と呼ばれる、2つの成分を備える。共有された値rは、エフェメラル公開鍵のx成分の関数、たとえば、r=x mod nであってよい。
エフェメラル公開鍵k・Gは、難読化係数の集合に基づいて生成されてよく、係数は、各参加者102のそれぞれのエフェメラル秘密鍵シェアkiを生成するために使用された。すなわち、エフェメラル秘密鍵シェアkiを生成するとき、各参加者102は、難読化係数kij・Gを他の各参加者102と共有する。係数は、選ばれた楕円曲線上の共通の生成元点Gによって難読化される。これらの難読化係数は、参加者102の間で直接送信されてよく、またはグループにブロードキャストされてもよい。たとえば、第1の参加者102aは、難読化係数k10・G、k11・G、k12・Gなどをブロードキャストしてよい。エフェメラル公開鍵が、次いで、
Figure 2023522748000013
として計算され得る。
いくつかの実施形態では、第1のMICは、第1のエフェメラル秘密鍵シェアk1に対応する第1の逆シェア
Figure 2023522748000014
に基づいて生成される。すなわち、第1の逆シェア
Figure 2023522748000015
は、第1のエフェメラル秘密鍵シェアk1の関数である。
第1の逆シェア
Figure 2023522748000016
は、たとえば、参加者1に対して
Figure 2023522748000017
を計算することによって生成される、共有秘密の逆元であってよい。上記で述べたように、共有秘密の逆元を計算することは、共有秘密の積を計算することを備える。第1の参加者102aは、第1のエフェメラル秘密鍵kと第1のブラインディング鍵αとの積として中間値μを生成する。たとえば、中間値は、参加者1に対してμ=kα=PROSS(1)として計算されてよく、その結果はμ=kα mod nである。
このことは、各参加者102が乗法的シェアμi=kiαiを生成することを伴うことがあり、ただし、αiは第1のブラインディング鍵αのシェアである。各参加者102は、共同秘密共有方式を使用して、たとえば、上記で説明したJVRSS技法を使用して、第1のブラインディング鍵αの自身のそれぞれのシェアαiを計算してよい。たとえば、第1の参加者102aは、1というインデックスを有してよく、参加者1に対してα1=JVRSS(1)を使用して第1のブラインディング鍵のシェアを生成してよい。各参加者は、(たとえば、直接の送信またはブロードキャストすることを介して)自身のそれぞれの乗法的シェアμiを共有し、次いで、たとえば、補間によって、乗法的シェアμiの各々に基づいて中間値μを生成する。第1の逆シェア
Figure 2023522748000018
は、中間値μの逆元を計算することによって生成され得る。たとえば、第1の参加者102aは、μの剰余逆元を計算してよく、それは、
μ-1=(kα)-1 mod n
という結果になる。
第1の参加者102aは、次いで、たとえば、
Figure 2023522748000019
を計算することによって、中間値の剰余逆元μ-1および自身のそれぞれの第1のブラインディング鍵シェアα1に基づいて、第1の逆シェア
Figure 2023522748000020
を計算してよい。
ブラインディング鍵シェアαiの使用が随意であり、上記のステップから省略されてよいことに留意されたい。
随意に、MICが、第2のブラインディング鍵βのシェアに基づいて生成され得る(すなわち、それの関数であり得る)。すなわち、MICはまた、以前に述べたデータアイテムに加えて第2のブラインディング鍵βの第1のシェアβ1に基づく。第2のブラインディング鍵の第1のシェアは、共同秘密共有方式を使用して、たとえば、上記で説明したJVRSS技法を使用して、計算され得る。たとえば、第1の参加者102aは、1というインデックスを有してよく、参加者1に対してβ1=JVRSS(1)を使用して第2のブラインディング鍵の第1のシェアを生成してよく、ここで、第2のブラインディング鍵はβによって示される。
MICは第1の事前署名シェアσ1に基づいて生成されてよく、第1の事前署名シェアσ1は、第1の中間シェアλ1、および少なくともしきい値数の参加者102から取得されるそれぞれの中間シェアλiの関数である。すなわち、参加者102の各々は、それぞれの中間シェアλiを生成してよく、それらの中間シェアλiを他の参加者102へ送信および/またはブロードキャストしてよい。第1の参加者102aは、中間シェアλiを収集して、たとえば、中間シェアλiの補間によって、共通の中間値λを生成し得る。第1の参加者102a(および随意に、他の参加者102)は、各々が、異なる署名シェアs1'の生成における使用のための、複数の事前署名シェアσ1'を生成し得る。
第1の中間シェアλ1は、第1の秘密鍵シェアa1および第1の逆シェア
Figure 2023522748000021
の関数であってよい。その場合、少なくともしきい値数の参加者102の各々は、自身のそれぞれの秘密鍵aiシェアおよび自身のそれぞれの逆シェア
Figure 2023522748000022
の関数である、それぞれの中間シェアλiを生成および共有する。
代替として、第1の中間シェアλ1は、第1の秘密鍵シェアa1および第1のブラインディング鍵α1の第1のシェアの関数であってよい。その場合、少なくともしきい値数の参加者102の各々は、自身のそれぞれの秘密鍵シェアaiおよび第1のブラインディング鍵α1の自身のそれぞれのシェアの関数である、それぞれの中間シェアλiを生成および共有する。
いくつかの実施形態では、第1の事前署名シェアσ1も、第2のブラインディング鍵β1の第1のシェアに基づいて生成され得る。たとえば、第1の中間シェアλ1は、第2のブラインディング鍵β1の第1のシェアの関数であってよい。追加または代替の実施形態では、第1の中間シェアλ1はまた、共通の値rの関数であってよい。
図2は、本発明の実施形態による、メッセージに対して署名を生成するための例示的な方法200を示す。ステップS201～S208は、この例では、(第1の参加者102aを含む)しきい値数の参加者102の各々によって実行される。ステップS209は、コーディネータ101によって実行され、コーディネータ101も、ステップS201～S208を実行する参加者のうちの1つであってよい。ステップのうちのいくつかが、省略されてよく、または異なる順序で実行されてよいことが、諒解されよう。
例示的な方法200は、N≧2t+1人の参加者のグループの中のしきい値(t+1)の共有秘密の作成を可能にし、ここで、署名するしきい値も(t+1)である。
セットアップ
ステップS201において、各参加者102は、共有秘密鍵シェアおよび対応する公開鍵を計算する。たとえば、各参加者102は、JVRSSおよび前置きの中で与えられた公開鍵の計算を使用して、共有秘密鍵および対応する公開鍵を計算してよい。この点において、各参加者iは、秘密鍵シェアおよび公開鍵(ai,P)を有し、ただし、Pは、共有秘密鍵に対応する公開鍵に対する表記法である。共有秘密鍵は、(t+1)というしきい値を有する。
事前計算
ステップS202において、各参加者102は、共有されるエフェメラル鍵シェアおよび対応する公開鍵を計算する。たとえば、各参加者102は、JVRSSおよび前置きの中で与えられた公開鍵の計算を使用して、共有されるエフェメラル鍵を計算してよい。各参加者102は、次いで、エフェメラル秘密鍵に基づいて逆シェアを計算してよい。このことは、(t+1)というしきい値を用いて、各参加者が逆シェア
Figure 2023522748000023
を有する結果となる。
ステップS203において、各参加者102は、共有される2つの異なるブラインディング鍵シェアを作成する。たとえば、各参加者102は、参加者iがシェアαi=JVRSS(i)およびβi=JVRSS(i)を有するように2つの共有秘密を作成してよく、各共有秘密はしきい値(t+1)を有する。いくつかの例では、共有秘密のすべてが、同じしきい値を有する必要があるとは限らないことに、留意されたい。
ステップS204において、各参加者102は、中間シェアを計算し、自身の中間シェアを他の参加者にブロードキャストする。たとえば、各参加者iは、中間シェア
Figure 2023522748000024
を計算してよい。この値は、(2t+1)というしきい値を有する。
ステップS205において、各参加者102は、少なくとも中間シェアに基づいて中間値を計算する。たとえば、各参加者102は、(2t+1)個のシェアにわたる補間λ=interpolate(λ1,...,λ2t+1)=k-1a+βを使用して、中間値を計算してよい。
ステップS206において、各参加者102は事前署名シェアを計算する。たとえば、各参加者iは、自身の事前署名シェアσi=λ-βi=(k-1a+β)-βiを計算してよい。各参加者102は、
Figure 2023522748000025
、ならびに秘密鍵シェアおよび対応する公開鍵(ai,P)を記憶してよい。
異なるエフェメラル鍵が署名ごとに使用されるので、複数のエフェメラル鍵が一度にセットアップされ得ること、すなわち、ステップS202～S206が、事前計算の間に複数のエフェメラル鍵を作成するために反復され得るとともに後で使用できるように記憶され得ることに、留意されたい。これらは、通信の追加のラウンドがないように同時に実行され得る。好ましくは、異なる値のαおよびβが署名ごとに使用されるべきであることに留意されたい。
署名生成
メッセージmsgに署名するために、少なくとも(t+1)人の参加者がステップS207およびS208を実行しなければならない。
ステップS207において、少なくともしきい値数の参加者102が、署名されるべきメッセージを取得し、メッセージダイジェストを計算する。たとえば、コーディネータ101は、メッセージmsgに対して署名シェアを作成するための要求を(t+1)人の参加者へ送ってよい。各参加者iは、メッセージダイジェストe=hash(msg)を計算してよい。いくつかの例では、このハッシュ関数は、二重のSHA-256ハッシュ関数である。代替のハッシュ関数が使用されてよい。
ステップS208において、少なくともしきい値数の参加者102は、署名シェアを計算し、それをコーディネータ101へ送る。たとえば、各参加者iは、自身の署名シェア
Figure 2023522748000026
を計算してよく、次いで、自身の署名シェア(r,si)をコーディネータへ送ってよい。値rがすべての参加者によって送られ得るとは限らないことに留意されたい。
ステップS209において、コーディネータ101が署名を計算する。たとえば、コーディネータ101は、s=interpolate(s1,...,st+1)=k-1(e+ar)を、かつ最後に署名(r,s)を計算してよい。
署名シェアのメッセージ非依存成分を事前計算するためのいくつかの代替形態がある。これらは、変形形態の2つのセット、すなわち、計算の中にrを含めるべき場合と(kα)-1を含めるべき場合とに、広く分割され得る。これらは、互いから独立して選択することができ、そのため、上記の方法200の8つの変形形態がある。
1つの修正形態は、ステップS206の間に、
Figure 2023522748000027
を記憶することであり、事前署名シェアの中にrが含められることを意味する。
別の修正形態は、rを伴う乗算も中間シェアの計算の間に、もっと前に来ることができることである。ステップS204において、
Figure 2023522748000028
を代わりに定義することによって、次いで、ステップS206において、σi=λ-βi=(rk-1a+β)-βiとなり、署名シェアの計算は
Figure 2023522748000029
となる。
別の修正形態は、λi=αiai+βiを代わりに計算することであり、その結果、λ=(kα)-1(αa+β)かつσi=λ-(kα)-1βiとなる。代替の点においてrを含める2つの変形形態は、このことと組み合わせて行うことができる。各参加者は、事前計算のステップS202において計算されるようなkαの知識を有する。追加として、すべての参加者102は、自身のλiシェアをブロードキャストする。そのため、各参加者102は、(少なくとも)2t+1個のシェアおよび値kαの知識を有する。参加者は、次いで、
λ=(kα)-1×interpolate(λ1,...,λ2t+1)
を計算することができる。
別の修正形態は、λ=(αa+β)としての中間値およびσi=λ-βiとしての事前署名シェアを、代わりに計算することである。最後に、署名シェアは、次いで、
Figure 2023522748000030
であることになる。計算の中にrを含めるべき場合の2つの変形形態も、このことと組み合わせて行うことができる。各参加者102は、
Figure 2023522748000031
の計算からkαの知識を有する。参加者は、次いで、これを用いて(kα)-1 mod nを計算することができ、次いで、それをsiの計算の中に含めることができる。
要約すれば、各参加者102は、4つの秘密シェア、すなわち、ai、ki、αi、βiを生成し得る。例示的な方法200では、2つの積、すなわち、kα、および署名における使用のためのk-1aが、計算される必要があり、kαは、次いで、
Figure 2023522748000032
を計算するために使用され(これらのシェアにわたる補間は、αが消えるとk-1を与える)、k-1aは、第1の積を使用し、そのため、シェアが拡張される場合、計算されたものは
Figure 2023522748000033
を与える。kαおよびαiから作られる、
Figure 2023522748000034
シェアを伴ういかなる計算も、最初にαi自体しか伴わない計算を行い、次いで、必要な場合に(kα)-1で乗算することによって、行うことができる。
上記の方式の1つのバージョンは、メッセージ非依存成分(MIC)およびメッセージ依存成分(MDC)からなるシェアを使用して署名が計算されると言うことによって要約することができ、ここで、MICは事前署名シェアσiに基づいてよく、MDCはメッセージeに基づく。
均等な方式は、たとえば、MDCだけから作られる署名シェアの補間の後、上記のようにMICを計算し、次いで、これを署名シェアと一緒に署名の中に組み込むことを備える。はっきりと、本方式は事前計算のステップS206まで同じであってよく、ここで、中間シェアはr値を含み、すなわち、
Figure 2023522748000035
となり、その結果、補間の後、これはλ=k-1ar+βとなる。
このステージにおいて、参加者は、
Figure 2023522748000036
の知識を有し、これを秘密鍵シェアおよび対応する公開鍵(ai,P)と一緒に記憶する。
次いで、メッセージダイジェストe=hash(m)を作成するためにハッシュされる、所与のメッセージmに対して自身の署名シェアを生成するために、参加者は、
Figure 2023522748000037
を計算し、これをコーディネータへ送る。コーディネータは、次いで、
s=interpolate(s1,...,st+1)+λ
=k-1e+k-1ar
を計算し、β項が消えるので、期待される署名シェアをもたらす。このプロトコルの類似の変形形態が、(kα)-1およびrが計算の中に含められる場合を説明する、上記のように行われ得る。
メッセージ非依存成分を計算するための以下の変形形態が実施され得る。
i) 次のように計算する。
λ=k-1a+β
次いで、ここで署名シェアは次の通りである。
Figure 2023522748000038
そして、署名が次のように生成される。
s=int(s1,...,st+1)+rλ
ii) 次のように計算する。
λ=αar+β
次いで、ここで署名シェアは次の通りである。
si=αie-βi
そして、署名が次のように生成される。
s=(kα)-1(int(s1,...,st+1)+λ)
iii) 次のように計算する。
λ=αa+β
次いで、ここで署名シェアは次の通りである。
Figure 2023522748000039
そして、署名が次のように生成される。
s=(kα)-1(int(s1,...,st+1)+rλ)
iv) 次のように計算する。
λ=αar+β
次いで、ここで署名シェアは次の通りである。
Figure 2023522748000040
そして、署名が次のように生成される。
s=(int(s1,...,st+1)+(kα)-1λ)
v) 次のように計算する。
λ=αa+β
次いで、ここで署名シェアは次の通りである。
Figure 2023522748000041
そして、署名が次のように生成される。
s=(int(s1,...,st+1)+r(kα)-1λ)
方法200と以前の方式との間の1つの差異は、署名の中のk-1a項の計算が事前計算段階の中に移動され得ることである。このことの結果は、署名生成が、秘密鍵計算と同じしきい値を有し、そのため、今やしきい値最適方式であることである。正確な署名がどのように見つけられるのかを理解するために、署名シェアにわたる補間が、
s=k-1e+r(k-1a+β-β)
=k-1e+r(k-1a)
=k-1(e+ar)
という結果になり、それが厳密に、必要とされるような署名であることに留意されたい。
秘密のしきい値が異なってよいことに留意されたい。すなわち、署名生成方式を実行するために、a、k、α、β自体のしきい値は、必ずしも同じであることを必要とするとは限らない。たとえば、6人のグループがあり、署名および/または秘密鍵を作成するために3人が必要とされる場合、kのしきい値が4であり他の共有秘密のしきい値が3であって、彼らは技術的にその計算を行うことができ、彼らは依然としてしきい値最適方式を有する。
ブラインディング秘密βが使用されない場合、以下の方法でエフェメラル鍵を、したがって、共有秘密鍵を計算することが可能であり得ることに、留意されたい。参加者が単に(k-1a)を使用すること、ならびに参加者がr、e、およびsも知っていることを想定する。方式におけるどの人も、
(s-(k-1a)r)e-1=k-1
を計算することができる。
この結果は、次いで、
(k-1)-1(k-1a)=a
を計算するために使用され得、それは共有秘密鍵である。
計算の中にβを含めることによって、この計算は行うことができない。値(k-1a+β)は、個々の秘密についての情報も結果k-1aも漏らさない。秘密鍵aを明らかにすることになる任意の情報を得るために、秘密鍵のしきい値と同じ数である少なくとも(t+1)人の参加者が協力しなければならず、そのため、この中間値λを計算することによってセキュリティは下がらない。
以前のしきい値最適署名計算を用いて解決すべき問題は、2つの共有秘密の積を計算しなければならないことであり、ここで、秘密は、グループの中のすべての参加者の個々の秘密の合計
Figure 2023522748000042
である。
署名において、秘密鍵aが共有秘密である場合、必然的にkも同様でなければならない(さもないと、kを知るどの人によってもaが計算され得る)。署名の中の第2の項は、そのとき、2つの共有秘密の乗算であり、これは、最適性を達成することを困難にする部分である。Gennaroらによる非最適方式、および上記で説明した例示的な方法200では、これらの秘密は各々、次数tの多項式の0次であり、多項式を一緒に乗算することは、乗算の結果を計算するために2t+1個というしきい値のシェアが必要とされる結果となる。この方式における公正を保証するために、大部分の通信はブロードキャストすることができ、簡単な等価性がチェックされ得る。追加として、ある参加者が署名の計算から離脱する場合、別の参加者が寄与することは容易である。
Gennaroらによるしきい値最適方式では、2t+1というこのしきい値は、秘密の積の中の個々の項を個別に計算することによって回避される。すなわち、参加者の各ペアi、jは、i、jごとに個々の項ai0kj0を計算してこれらの結果を合計する。署名する間にエフェメラル鍵kが作成され、次いで、個々の秘密寄与のこれらの積がPallier暗号化を使用して計算される。このことは、各参加者がすべての他の署名者と個別に通信しなければならないことを必要とする。この事例における公正を保証するために、実行されなければならない複数のゼロ知識証明がある。この事例において、参加者が署名の計算から離脱する場合、署名アルゴリズムは再開始されなければならない。
言い換えれば、各秘密は個々の秘密の合計であり、2つの秘密の乗算は、
a10b10+a20b10+...bn0an0
などのように延びて拡張され得る、個々の項の2つの合計の乗算である。
Gennaro方式は、これらの項を個別に計算する。すなわち、参加者1は、参加者2とともにa20b10を計算しなければならず、同じく参加者3とともにa30b10を計算しなければならず、以下同様である。これらは、次いで、すべてが一緒に合計される。これらの個々の計算は、計算コストが高いゼロ知識証明を伴う。そのため、本方式において多くの人間がいるとすぐに、本方式は非効率になる。このことはまた、署名する段階においてすべてが行われ、そのため、署名を計算するための、計算コストが高い方法である。
3人の参加者を伴う簡単な事例では、通信のラウンドは2つの方式(すなわち、Gennaroらによる最適しきい値方式、および例示的な方法200)の間でほぼ同等であるが、Gennaro方式はより多くを有し、これは主な効率節約がある場所ではない。節約は、計算および通信されるデータのボリュームにある。Gennaroの方式は、例示的な方法200では存在しない複数のゼロ知識証明(ZKP:zero-knowledge proof)を含まなければならない。
以下は、Gennaroらによる最適しきい値方式を使用して実施される、3人のうちの2人の方式と、例示的な方法200とを比較する。Gennaroの方式では、署名する前のJVRSS、およびPallierの暗号化のために作成すべき追加の暗号化鍵がある。次いで、作成すべき7つのZKP、および署名計算において検証すべき7つのZKPがある。これらのZKPは同時に送ることができず、そのため、署名する段階において通信の複数のラウンドがある。追加として、いくつかのステップの中で、各参加者は、署名する段階においてすべての他の参加者と個別に通信しなければならず、そのことは非効率である。このことは、それらの参加者が全員同時にオンラインでなければならないことを意味する。対照的に、本発明は、他の参加者がオンラインであることを伴わずに所与の参加者が署名シェアを計算することを可能にする。
一方、上記で説明した本方式では、事前署名する段階において4つのJVRSS計算があり、いかなる点においてもZKPがない。JVRSS計算は同時に行うことができ、そのため、通信は1つのJVRSSと同じである。署名する段階では、要求応答型の通信しかなく、すべての情報はグループにブロードキャストされ得る。
2つの方式の記憶容量の間を比較するために、上記の方式ではエフェメラル鍵がセットアップステージとともに計算されることに留意されたい。このことは、Gennaroの方式と比較したとき、必要とされるもっと多くの記憶容量があることを意味する。上記で説明した方式の場合、たとえば、32バイトの記憶空間が各々必要とされて、署名を作成することに対応する、記憶されるべき3つの追加の値がある。計算および通信における効率節約、ならびに最適性達成を考えると、このことは最小限である。
要約するために、Gennaroの方式は、セットアップおよび事前計算の後に必要とされる記憶容量を減らすが、署名計算中の計算および通信を増やす。このことは、Gennaroの方式において計算のうちのそれ以上を、事前署名することに移動させることが非効率であることに起因する。特に不等式N≧2t+1が許容できる場合、本発明の方式はGennaroの最適方式よりも効率的である。
例示的な使用事例
概して、本発明は任意のメッセージに対して署名を生成するために使用され得る。特定の例示的な使用事例として、メッセージはブロックチェーントランザクションの一部または全部であってよい。すなわち、署名は、ブロックチェーントランザクションの1つもしくは複数の入力および/または1つもしくは複数の出力に署名するために使用され得る。
図3は、ブロックチェーンプロトコルの一部としての使用のための例示的なトランザクションプロトコルを示す。例示的なブロックチェーンプロトコルは、文献の中で十分に立証されるが、ここでは完全のために例示的なプロトコルトランザクションの説明が提供される。これは、UTXOベースのプロトコルの一例である。トランザクション152(「Tx」と短縮される)は、ブロックチェーンの基本的なデータ構造である(ブロックチェーンの各ブロックが1つまたは複数のトランザクション152を備える)。以下は、出力ベースまたは「UTXO」ベースのプロトコルへの参照によって説明される。ただし、これはすべての可能な実施形態にとって限定的でない。
UTXOベースのモデルでは、各トランザクション(「Tx」)152は、1つまたは複数の入力202および1つまたは複数の出力203を備える、データ構造を備える。各出力203は、(UTXOがすでに償還されていない場合)別の新たなトランザクションの入力202のためのソースとして使用され得る、未消費のトランザクション出力(UTXO)を備えてよい。UTXOは、デジタルトークンの金額を指定する、たとえば、デジタル資産の金額を表す、値を含む。これは、(配送される)台帳上のトークンのセット数を表す。UTXOはまた、他の情報の中でも、UTXOがそこから来たトランザクションのトランザクションIDを含んでよい。トランザクションデータ構造はまた、ヘッダ201を備えてよく、ヘッダ201は、入力フィールド202および出力フィールド203のサイズのインジケータを備えてよい。ヘッダ201はまた、トランザクションのIDを含んでよい。実施形態では、トランザクションIDは、(トランザクションID自体を除外した)トランザクションデータのハッシュであり、マイナーへサブミットされる未加工トランザクション152のヘッダ201の中に記憶される。
第1のユーザと言う、たとえば、アリス(Alice)は、当該の、ある金額のデジタルトークンを第2のユーザ、たとえば、ボブ(Bob)に転送するトランザクション152jを作成することを希望する。図3では、アリスの新たなトランザクション152jは「Tx1」とラベル付けされる。それは、シーケンスの中の先行するトランザクション152iの出力203の中でアリスに対してロックされている金額のデジタルトークンを取り除き、このうちの少なくともいくつかをボブに転送する。先行するトランザクション152iは、図3の中で「Tx0」とラベル付けされる。Tx0およびTx1は恣意的なラベルにすぎない。それらは、必ずしもTx0がブロックチェーンの中の最初のトランザクションであることも、Tx1がプールの中のすぐ次のトランザクションであることも意味するとは限らない。Tx1は、アリスに対してロックされた未消費の出力203を依然として有する任意の先行する(すなわち、祖先(antecedent))トランザクションを後方に指し示すことができる。
アリスが彼女の新たなトランザクションTx1を作成する時間において、または少なくとも彼女がそれをネットワーク106へ送る時間までに、先行するトランザクションTx0は、すでに有効にされていることがあり、ブロックチェーンの中に含まれていることがある。それは、その時間においてブロックのうちの1つの中にすでに含まれていることがあるか、または依然としてプール154の中で待っていることがあり、その場合、それは間もなく新たなブロックの中に含められる。代替として、Tx0およびTx1は、一緒に作成され得るとともにブロックチェーンネットワークへ送ることができ、またはTx0は、ノードプロトコルが「孤児(orphan)」トランザクションをバッファリングすることを可能にする場合、Tx1の後でさえ送ることができる。トランザクションのシーケンスの文脈において本明細書で使用する「先行する」および「後続の」という用語は、トランザクションの中で指定されるトランザクションポインタによって定義されるような、シーケンスの中でのトランザクションの順序(どのトランザクションが、他のどのトランザクションを後方に指し示すのかなど)を指す。それらは、「先任者(predecessor)」および「後任者(successor)」、もしくは「祖先」および「子孫(descendant)」、「親(parent)」および「子(child)」、またはそのようなものと等しく置き換えられ得る。そのことは、必ずしもそれらが作成されるか、ネットワークへ送られるか、または任意の所与のノードに到着する順序を暗示するとは限らない。とはいえ、先行するトランザクション(祖先トランザクションまたは「親」)を指し示す後続のトランザクション(子孫トランザクションまたは「子」)は、親トランザクションが有効にされるまで、また親トランザクションが有効にされない限り、有効にされない。その親の前にノードに到着する子は孤児と見なされる。孤児は、ノードプロトコルおよび/またはマイナー挙動に応じて、廃棄されてよく、または親を待つためのいくらかの時間の間、バッファリングされてもよい。
先行するトランザクションTx0の1つまたは複数の出力203のうちの1つは、ここではUTXO0とラベル付けされた特定のUTXOを備える。各UTXOは、UTXOによって表されるデジタルトークンの金額を指定する値、および後続のトランザクションが有効にされるために、したがって、UTXOが首尾よく償還されるために、後続のトランザクションの入力202の中のロック解除スクリプトによって満たされなければならない条件を定義するロックスクリプトを備える。通常、ロックスクリプトは特定の当事者(ロックスクリプトがその中に含まれるトランザクションの受益者)に対してその金額をロックする。すなわち、ロックスクリプトは、通常、後続のトランザクションの入力の中のロック解除スクリプトが、先行するトランザクションがその人に対してロックされる当事者の暗号署名を備える条件を備える、ロック解除条件を定義する。
ロックスクリプト(別名scriptPubKey)は、ノードプロトコルによって認識されるドメイン固有の言語で書かれたコードの断片である。そのような言語の特定の例は「Script」(大文字のS)と呼ばれる。ロックスクリプトは、トランザクション出力203を消費するためにどんな情報が必要とされるのか、たとえば、アリスの署名の要件を指定する。ロック解除スクリプトは、トランザクションの出力の中に現れる。ロック解除スクリプト(別名scriptSig)は、ロックスクリプト基準を満たすために必要とされる情報を提供する、ドメイン固有の言語で書かれたコードの断片である。たとえば、それはボブの署名を含んでよい。ロック解除スクリプトは、トランザクションの入力202の中に現れる。
そのため、図示した例では、Tx0の出力203の中のUTXO0はロックスクリプト[Checksig PA]を備え、ロックスクリプト[Checksig PA]は、UTXO0が償還されるために(厳密には、UTXO0を償還しようと試みる後続のトランザクションが有効となるために)アリスの署名Sig PAを必要とする。[Checksig PA]は、アリスの公開秘密鍵ペアからの公開鍵PAを含む。Tx1の入力202は、(たとえば、実施形態ではトランザクションTx0全体のハッシュである、そのトランザクションID、すなわち、TxID0によって)Tx1を後方に指し示す、ポインタを備える。Tx1の入力202は、Tx0の任意の他の可能な出力の間でそれを識別するための、Tx0内でUTXO0を識別するインデックスを備える。Tx1の入力202はロック解除スクリプト<Sig PA>をさらに備え、ロック解除スクリプト<Sig PA>は、アリスが鍵ペアからの彼女の秘密鍵をデータの既定の部分(暗号における「メッセージ」と呼ばれることがある)に適用することによって作成された、アリスの暗号署名を備える。有効な署名を提供するためにアリスによってどんなデータ(または「メッセージ」)が署名される必要があるのかは、ロックスクリプトによって、もしくはノードプロトコルによって、またはこれらの組合せによって定義され得る。
新たなトランザクションTx1がノードに到着すると、そのノードはノードプロトコルを適用する。これは、ロックスクリプトとロック解除スクリプトとを一緒に実行させて、ロックスクリプトの中で定義される条件をロック解除スクリプトが満たすかどうかをチェックすることを備える(ここで、この条件は1つまたは複数の基準を備えてよい)。実施形態では、このことは2つのスクリプトを連結すること、すなわち、
<Sig PA> <PA> || [Checksig PA]
を伴い、ただし、「||」は連結を表し、「<...>」はスタック上でのデータの場所を意味し、「[...]」はロック解除スクリプト(この例では、スタックベース言語)によって備えられた関数である。等価的に、スクリプトは、スクリプトを連結するのではなく、共通のスタックを用いて次々に実行されてよい。どちらにしても、一緒に実行されると、スクリプトは、Tx0の出力の中のロックスクリプトの中に含まれるようなアリスの公開鍵PAを使用して、Tx1の入力の中のロックスクリプトが、データの期待される部分に署名するアリスの署名を含むことを認証する。データ自体の期待される部分(「メッセージ」)はまた、この認証を実行するためにTx0の中に含まれる必要がある。実施形態では、署名されたデータはTx0の全体を備える(そのため、すでに本質的に存在しているような、普通文の中のデータの署名された部分を指定する別個の要素が含まれる必要がある)。
公開秘密暗号による認証の詳細は、当業者になじみがあろう。基本的に、アリスが彼女の秘密鍵を用いてメッセージを暗号化することによってメッセージを署名している場合、アリスの公開鍵および普通文の中のメッセージ(非暗号化メッセージ)が与えられると、ブロックチェーンネットワークのノードなどの別のエンティティは、暗号化されたバージョンのメッセージがアリスによって署名されていなければならないことを認証することが可能である。署名することは、通常、メッセージをハッシュすること、ハッシュに署名すること、およびこれを普通文バージョンのメッセージ上に署名としてタグ付けすることを備え、したがって、公開鍵の任意の保持者が署名を認証することを可能にする。したがって、データの特定の断片もしくはトランザクションの一部またはそのようなものに署名することへの、本明細書における任意の参照が、実施形態では、そうしたデータの断片またはトランザクションの一部のハッシュに署名することを意味することができることに、留意されたい。
Tx1の中のロック解除スクリプトがTx0のロックスクリプトの中で指定される1つまたは複数の条件を満たす場合(そのため、図示の例では、アリスの署名がTx1の中で提供され認証される場合)、ブロックチェーンノードはTx1を有効と見なす。それがマイニングノードである場合、このことは、マイニングノードが、プルーフオブワークを待っているトランザクションのプールにTx1を追加することを意味する。それが転送ノードである場合、転送ノードは、ブロックチェーンネットワークの中の1つまたは複数の他のノードにトランザクションTx1を転送し、その結果、トランザクションTx1はネットワーク全体にわたって伝搬される。Tx1が有効にされておりブロックチェーンの中に含まれていると、このことはTx0からのUTXO0を消費済みとして定義する。それが未消費のトランザクション出力203を消費する場合のみ、Tx1が有効であり得ることに留意されたい。それが、すでに別のトランザクションによって消費されている出力を消費することを試みる場合、すべての他の条件が満たされる場合でもTx1は無効である。したがって、ノード104はまた、先行するトランザクションTx0の中の参照されるUTXOがすでに消費されている(別の有効なトランザクションへの有効な入力をすでに形成している)かどうかをチェックする必要がある。このことは、トランザクション上で定義済みの順序を強いることがなぜブロックチェーン150にとって重要であるのかという1つの理由である。実際には、所与のノード104は、どのトランザクションの中のどのUTXO203が消費されているのかをマークする別個のデータベースを保持してよいが、最終的には、UTXOが消費されているかどうかを定義するものは、それがブロックチェーンの中で別の有効なトランザクションへの有効な入力をすでに形成しているかどうかである。
所与のトランザクションのすべての出力203の中で指定される総額が、そのすべての入力202によって指し示される総額よりも大きい場合、このことは、大部分のトランザクションモデルにおける無効性に対する別の基準である。したがって、そのようなトランザクションは伝搬されず、ブロックの中にマイニングもされない。
スクリプトコードが、しばしば、概略的に表される(すなわち、正確な言語でない)ことに留意されたい。たとえば、[Checksig PA] = OP_DUP OP_HASH160 <H(PA)> OP_EQUALVERIFY OP_CHECKSIGを意味するために[Checksig PA]と書いてよい。「OP_...」は、Script言語の特定のオペコードを指す。OP_CHECKSIG(「Checksig」とも呼ばれる)は、2つの入力(署名および公開鍵)をとり楕円曲線デジタル署名アルゴリズム(ECDSA)を使用して署名の有効性を検証する、Scriptオペコードである。実行時において、署名(「sig」)のいかなる出現もスクリプトから除去されるが、ハッシュパズルなどの追加の要件が、「sig」入力によって検証されるトランザクションの中に残る。別の例として、OP_RETURNは、メタデータをトランザクション内に記憶でき、それによって、ブロックチェーンの中にメタデータを不変に記録できる、トランザクションの消費不可能な出力を作成するための、Script言語のオペコードである。たとえば、メタデータは、ブロックチェーンの中に記憶することが望まれる文書を備えることができる。
署名PAはデジタル署名である。実施形態では、これは楕円曲線secp256k1を使用するECDSAに基づく。デジタル署名は、データの特定の断片に署名する。実施形態では、所与のトランザクションに対して、署名は、トランザクション入力の一部、およびトランザクション出力の全部または一部に署名する。それが署名する出力の特定の部分は、SIGHASHフラグに依存する。SIGHASHフラグは、どの出力が署名されるのか(したがって、署名する時間において固定されるのか)を選択するための、署名の末尾に含まれる4バイトコードである。
ロックスクリプトが、それぞれのトランザクションがその人に対してロックされる当事者の公開鍵を備えるという事実を参照すると、ロックスクリプトは「scriptPubKey」と呼ばれることがある。ロック解除スクリプトが、対応する署名を供給するという事実を参照すると、ロック解除スクリプトは「scriptSig」と呼ばれることがある。しかしながら、より一般的には、UTXOが償還されるための条件が署名を認証することを備えることは、ブロックチェーンのすべての適用例において必須であるとは限らない。より一般的には、スクリプト言語は、任意の1つまたは複数の条件を定義するために使用され得る。したがって、「ロックスクリプト」および「ロック解除スクリプト」という、より一般的な用語が好ましい場合がある。
本発明のいくつかの実施形態によれば、コーディネータ101によって生成される署名が、ブロックチェーントランザクションに署名するために使用され得る。たとえば、生成される署名は、少なくとも部分的には、ブロックチェーントランザクションの出力をロック解除するために使用され得る。特定の例として、以前のトランザクションの出力は、公開鍵のハッシュに対してロックされるペイツーパブリックキーハッシュ(P2PKH:pay-to-public-key-hash)出力であってよい。ロック解除されるために、P2PKH出力を参照するもっと後のトランザクションの入力は、(ハッシュされていない)公開鍵、および公開鍵に対応する秘密鍵に基づいて生成された署名を含む必要がある。
スクリプトの中で表されると、「ロックスクリプト」および「ロック解除スクリプト」は以下の形式をとってよい。
Locking script = OP_DUP OP_HASH160 <Public KeyHash> OP_EQUAL OP_CHECKSIG
Unlocking script = <Signature> <Public Key>
説明した上記の実施形態を参照すると、<Public Key>はP=a・Gと同等と見なされてよく、<Signature>はしきい値署名sを備え、ここで、以前のトランザクションは署名されるべきメッセージである。上で述べたように、ECDSA署名が形式(r,s)をなすことに留意されたい。
説明した署名生成方法が、いかなる特定の使用事例にも限定されず、一般に、任意のメッセージに基づいて署名を生成するために使用されてよいことに、留意されたい。ブロックチェーントランザクションの全部または一部に署名することは、1つの例示的な例にすぎない。説明した方法は、たとえば、法律文書(たとえば、遺言書、捺印証書、または他の契約書)、1または複数の当事者間の書簡、(たとえば、証明局によって発行される)デジタル証明書、医療処方箋、銀行振替または金融証書、抵当権またはローンの申請などに署名し、かつ/またはそれらを認証するために、使用され得る。
特定の例として、参加者のグループ(たとえば、合計5人の参加者)が、会社の役員会を形成してよい。その会社の投票事項は、役員会の過半数(すなわち、少なくとも3人の参加者)が特定の投票に合意することを必要とする場合がある。役員会は、少なくとも3人の役員会メンバーが特定の成果に賛成して投票することに合意したことを証明するために、説明した署名生成方法を使用してよい。この例では、署名生成方式のしきい値は3である。すなわち、コーディネータが首尾よく署名を生成するために、役員会メンバーのうちの少なくとも3人がそれぞれの署名シェアを提供しなければならない。署名が首尾よく生成される場合、少なくともしきい値数(すなわち、3人)の役員会メンバーが、その成果に賛成して投票することに合意しているにちがいない。したがって、署名の成功した生成は投票の記録として働き、役員会の過半数が投票したことを特定の方法で証明する。
本発明にとっての別の使用事例は、デジタル証明書、たとえば、X.509規格によって発行されるデジタル証明書の分野にある。デジタル証明書は、いくつかのデータにわたって署名する署名を含む。データは、一般に、任意のデータであり得るが、デジタル証明書の中に含まれるデータの特定の一例が公開鍵である。デジタル証明書の中の公開鍵は、しばしば、「認定公開鍵」と呼ばれる。デジタル証明書の発行者(「証明局」)は、公開鍵の所有者に対して1つまたは複数のチェック(たとえばノーユアカスタマーチェック(know-your-customer check))を実行してよく、チェックが成功している場合、証明局は認定公開鍵を含むデジタル証明書を発行する。ユーザは、たとえば、認定公開鍵に対応する秘密鍵を用いてメッセージに署名することによって、認定公開鍵を使用して、その人はその人がその人であるという人であること(they are who they say they are)を証明することができる。
証明局のための1つの特定の使用は、インターネット上でのセキュアなブラウジングのためにHTTPSにおいて使用される証明書に署名することである。別の一般の使用は、電子的に文書に署名する際の使用のために、中央政府によって身分証明書を発行するときである。証明局は、秘密鍵を使用して公開鍵(または、証明されるべき任意の他のデータ)に署名する。このことは単一の障害点を持ち込む。すなわち、悪意のある当事者が、デジタル証明書を発行するために証明局によって使用された秘密鍵へのアクセスを得ることができる場合、悪意のある当事者は、次いで、詐欺的な証明書を発行することができる。証明局がターゲットにされる特定の例は、DigiNotar、すなわち、オランダの証明局である。DigiNotarによって使用される秘密鍵は、2011年に脅かされ詐欺的な証明書を発行するために使用された。攻撃者はデータの単一の断片、すなわち、秘密鍵を取得することしか必要としなかったので、この攻撃が可能であった。しかしながら、証明局(DigiNotar)が本発明によるしきい値署名方式を使用した場合、この攻撃は可能でなくなった(または、少なくとももっと困難にされた)ことになる。証明書を発行するために、攻撃者は、署名を生成するために必要とされる、しきい値数の鍵シェア(または、署名シェア)を獲得しなければならない。
上記の実施形態が単に例として説明されていることが諒解されよう。より一般的には、以下の声明のうちの任意の1つまたは複数による方法、装置、またはプログラムが提供され得る。
声明1. メッセージのデジタル署名のシェアを生成するコンピュータ実装方法であって、デジタル署名を生成するために参加者のグループのそれぞれの参加者からのしきい値数の異なる署名シェアが必要とされ、各参加者はそれぞれの秘密鍵シェアを有し、方法は、参加者のうちの第1の参加者によって実行され、
第1のメッセージ非依存成分および第1のメッセージ依存成分を生成することであって、メッセージ非依存成分が第1の秘密鍵シェアに基づいて生成され、メッセージ依存成分がメッセージに基づいて生成される、生成することと、
第1のメッセージ非依存成分をコーディネータにとって利用可能にさせることと、
少なくともしきい値数の署名シェアに基づいて署名を生成するために第1の署名シェアをコーディネータにとって利用可能にさせることであって、第1の署名シェアが少なくともメッセージ依存成分を備える、利用可能にさせることとを備える。
たとえば、第1の署名シェアの前に、さらには第1のメッセージ依存成分が生成される前に、第1のメッセージ非依存成分がコーディネータへ送られてよい。
声明2. 声明1の方法であって、メッセージを取得する前にメッセージ非依存成分が生成される。
言い換えれば、メッセージ非依存成分は事前計算されてよい。すなわち、メッセージ非依存成分は、メッセージを取得すること(たとえば、受信すること)に先立って生成され得る。次いで、メッセージが取得されていると、メッセージ依存成分が生成され得、したがって、署名シェアが生成されることを可能にする。
声明3. 声明1または声明2の方法であって、第1の署名シェアはメッセージ非依存成分を備える。
すなわち、少なくともいくつかの実施形態では、第1の署名シェアはメッセージ非依存成分を含まない。
声明4. 声明1～声明3のうちのいずれかの方法であって、第1の秘密鍵のシェアを生成するための共同秘密共有方式を使用して第1の秘密鍵シェアが生成される。
声明5. 声明4の方法であって、共同秘密共有方式を使用して第1の秘密鍵シェアを生成することは、
第1のデータアイテムを生成することであって、第1のデータアイテムが第1の多項式である、生成することと、
少なくともしきい値数の参加者からそれぞれのデータアイテムを取得することであって、各それぞれのデータアイテムが、それぞれの参加者によって生成されたそれぞれの多項式である、取得することと、
第1のデータアイテムおよびそれぞれのデータアイテムの各々に基づいて第1の秘密鍵シェアを生成することとを備える。
声明6. 声明5の方法であって、それぞれのデータアイテムを取得することは、第1の参加者とそれぞれの参加者の各々との間のそれぞれの通信チャネルを介してそれぞれのデータアイテムを取得することを備える。
好ましくは、各通信チャネルはセキュアな通信チャネルである。
声明7. 声明4または声明5の方法であって、第1の多項式のそれぞれのインスタンスを少なくともしきい値数の参加者の各々へ送信することを備え、第1の多項式のそれぞれのインスタンスはそれぞれの参加者に基づく。
たとえば、それぞれのインスタンスはそれぞれの通信チャネルを介して送信されてよい。
いくつかの例では、共同秘密共有方式は、
生成元値を用いて難読化された第1の多項式の係数のそれぞれの集合を、少なくともしきい値数の参加者の各々と共有することと、
各それぞれの参加者によって生成されたそれぞれの多項式の係数のそれぞれの集合を取得することであって、係数のそれぞれの集合が生成元値を用いて難読化される、取得することと、
それぞれの参加者ごとに、
生成元値を用いて難読化され、その参加者から取得された、それぞれのデータアイテムに基づいて第1の候補値を決定すること、
そのそれぞれの参加者から取得された難読化係数のそれぞれの集合に基づいて第2の候補値を決定すること、および
第1の候補値が第2の候補値に対応することを検証することによって、
それぞれの参加者が自身のそれぞれの秘密鍵シェアを正しく生成していることを検証することとをさらに備える、
共同検証可能秘密共有方式であってよい。
声明8. 前述のいずれかの声明の方法であって、各参加者は、それぞれのエフェメラル秘密鍵シェアを有し、第1のメッセージ非依存成分および/または第1のメッセージ依存成分は第1のエフェメラル秘密鍵シェアに基づく。
声明9. 声明8の方法であって、各参加者は、エフェメラル秘密鍵に対応するエフェメラル公開鍵に基づくそれぞれの共有された値を有し、第1のメッセージ非依存成分は、共有された値に基づく。
声明10. 前述のいずれかの声明の方法であって、エフェメラル秘密鍵のシェアを生成するための共同秘密共有方式を使用して第1のエフェメラル秘密鍵シェアが生成される。
声明11. 前述のいずれかの声明の方法であって、第1のメッセージ非依存成分は、第1のエフェメラル秘密鍵シェアに対応する逆元に基づいて生成される。
声明12. 声明11の方法であって、第1のエフェメラル秘密鍵シェアの逆元を生成することは、
エフェメラル秘密鍵および第1のブラインディング鍵に基づいて中間値を生成することと、
中間値の逆元および第1のブラインディング鍵の第1のブラインディング鍵シェアに基づいて第1のエフェメラル秘密鍵シェアの逆元を生成することとを備える。
中間値は、エフェメラル秘密鍵と第1のブラインディング鍵との積である。
声明13. 声明12の方法であって、第1のブラインディング鍵のシェアを生成するための共同秘密共有方式を使用して第1のブラインディング鍵シェアが生成される。
声明14. 声明12または声明13の方法であって、中間値は、
第1のエフェメラル秘密鍵シェアおよびブラインディング鍵シェアに基づいて第1の乗法的鍵シェアを生成することと、
少なくともしきい値数の参加者からそれぞれの乗法的鍵シェアを取得することと、
第1の乗法的鍵シェアおよびそれぞれの乗法的鍵シェアの各々に基づいて中間値を生成することとによって生成される。
いくつかの例では、乗法的鍵シェアを生成するために必要とされる参加者のしきい値数が、秘密鍵シェアを生成するために必要とされる参加者のしきい値数とは異なることに、留意されたい。たとえば、秘密鍵はしきい値t+1を有し、乗法的鍵シェアが2t+1を必要とする。
声明15. 声明14の方法であって、第1の乗法的鍵シェアを少なくともしきい値数の参加者の各々へ送信することを備える。
声明16. 前述のいずれかの声明の方法であって、メッセージ非依存成分は第2のブラインディング鍵の第2のブラインディング鍵シェアに基づいて生成される。
声明17. 声明16の方法であって、第2のブラインディング鍵のシェアを生成するための共同秘密共有方式を使用して第2のブラインディング鍵シェアが生成される。
声明18. 声明11またはそれに従属するいずれかの声明の方法であって、第1のメッセージ非依存成分は第1の事前署名シェアに基づいて生成され、第1の事前署名シェアは、
第1の中間シェアであって、第1の秘密鍵シェア、および第1のエフェメラル秘密鍵シェアに対応する逆元に基づいて生成される、第1の中間シェア、ならびに
少なくともしきい値数の参加者から取得されたそれぞれの中間シェアに基づいて生成される。
声明19. 声明1～17のうちのいずれかに従属するときの声明11の方法であって、第1のメッセージ非依存成分は第1の事前署名シェアに基づいて生成され、第1の事前署名シェアは、
第1の中間シェアであって、第1の秘密鍵シェアおよび第1のブラインディング鍵シェアに基づいて生成される、第1の中間シェア、
少なくともしきい値数の参加者から取得されたそれぞれの中間シェアに基づいて生成される。
声明20. 声明19の方法であって、第1の事前署名シェアは、第1のエフェメラル秘密鍵シェアに対応する逆元に基づいて生成される。
声明21. 声明18～20のうちのいずれかの方法であって、第1の中間シェアは、第2のブラインディング鍵シェアに基づいて生成される。
声明22. 声明18～21のうちのいずれかの方法であって、第1の事前署名シェアは、共有された値に基づいて生成される。
声明23. 声明22の方法であって、第1の中間シェアは、共有された値に基づいて生成される。
声明24. 声明18もしくは声明19のいずれかまたはそれに従属するいずれかの声明の方法であって、第1の中間シェアを少なくともしきい値数の参加者へ送信することを備える。
声明25. 前述のいずれかの声明の方法であって、メッセージ非依存成分の複数の異なるインスタンスを生成することを備える。
声明26. 前述のいずれかの声明の方法であって、第1のエフェメラル秘密鍵シェアの複数の異なるインスタンスを生成することを備える。
声明27. 声明25または声明26の方法であって、第1のブラインディング鍵シェアおよび/または第2のブラインディング鍵シェアの複数の異なるインスタンスを生成することを備える。
声明28. 声明18もしくは声明19のいずれかまたはそれに従属するいずれかの声明の方法であって、第1の事前署名シェアの複数の異なるインスタンスを生成することを備える。
声明29. 前述のいずれかの声明の方法であって、コーディネータからメッセージを取得することを備える。
声明30. 声明1～28のうちのいずれかの方法であって、メッセージを生成することを備える。
声明31. 前述のいずれかの声明の方法であって、メッセージは第2のメッセージのハッシュである。
声明32. 前述のいずれかの声明の方法であって、第1の署名シェアをコーディネータにとって前記利用可能にさせることは、
第1の署名シェアをコーディネータへ送信すること、
しきい値数の参加者のうちの1または複数へ第1の署名シェアをブロードキャストすることのうちの少なくとも1つを備える。
声明33. 前述のいずれかの声明の方法であって、第1のメッセージ非依存成分をコーディネータにとって前記利用可能にさせることは、
第1のメッセージ非依存成分をコーディネータへ送信すること、
しきい値数の参加者のうちの1または複数へ第1のメッセージ非依存成分をブロードキャストすることのうちの少なくとも1つを備える。
声明34. メッセージのデジタル署名を生成するコンピュータ実装方法であって、デジタル署名を生成するために参加者のグループのそれぞれの参加者からのしきい値数の異なる署名シェアが必要とされ、各参加者はそれぞれの秘密鍵シェアを有し、方法は、コーディネータによって実行され、
少なくともしきい値数のそれぞれのメッセージ非依存成分を取得することであって、各それぞれのメッセージ非依存成分がそれぞれの秘密鍵シェアに基づいて生成される、取得することと、
少なくともしきい値数のそれぞれの署名シェアを取得することであって、各それぞれの署名シェアが少なくともそれぞれのメッセージ依存成分に基づき、各それぞれのメッセージ依存成分がメッセージに基づいて生成される、取得することと、
取得された署名シェアの各々および取得されたメッセージ非依存成分の各々に基づいてメッセージの署名を生成することとを備える。
それぞれのメッセージ非依存成分は、それぞれの署名シェアの一部を形成し得る。
署名を生成することは、署名シェアを補間することを備えてよい。
いくつかの事例では、署名がECDSA署名の成分であってよいことに留意されたい。
声明35. 声明34の方法であって、各それぞれの署名シェアはそれぞれのメッセージ非依存成分に基づく。
声明36. 声明34の方法であって、
取得されたメッセージ非依存成分の各々に基づいて共通メッセージ非依存成分を生成することと、
共通メッセージ非依存成分に基づいて署名を生成することとを備える。
声明37. 声明34～36のうちのいずれかの方法であって、各参加者は、それぞれのエフェメラル秘密鍵シェアを有し、各それぞれのメッセージ非依存成分および/またはメッセージ依存成分はそれぞれのエフェメラル秘密鍵シェアに基づく。
声明38. 声明37の方法であって、各参加者は、エフェメラル秘密鍵に対応するエフェメラル公開鍵に基づく共有された値を有し、各それぞれのメッセージ非依存成分は、共有された値に基づく。
声明39. 声明34～声明38のうちのいずれかの方法であって、しきい値数の参加者の中の参加者のうちの1、一部、またはすべてにメッセージを送信することを備える。
声明40. 声明34～声明39のうちのいずれかの方法であって、それぞれの署名シェアに対する要求を少なくともしきい値数の参加者へ送信することを備える。
声明41. 声明34～声明40のうちのいずれかの方法であって、取得された署名シェアのうちの1つを生成することを備える。
声明42. 声明34～41のうちのいずれかの方法であって、署名を出力することを備える。
声明43. 声明42の方法であって、署名を出力することは、
署名を1または複数の当事者へ送信すること、および/または
デジタル媒体上に署名を記録すること、および/または
署名を公開させることを備える。
声明44. 前述のいずれかの声明の方法であって、メッセージはブロックチェーントランザクションの少なくとも一部を備える。
メッセージは、代わりに、文書(たとえば、法律文書)、デジタル証明書、医療処方箋、または金融証書の少なくとも一部のうちの1つを備えてもよい。
声明45. 前述のいずれかの声明の方法であって、参加者のしきい値数は、参加者のグループの中の参加者の総数よりも少ない。
声明46. コンピュータ機器であって、
1つまたは複数のメモリユニットを備えるメモリと、
1つまたは複数の処理ユニットを備える処理装置とを備え、メモリは、処理装置上で実行するように構成されたコードを記憶し、コードは、処理装置上で実行するとき声明1～45のうちのいずれかの方法を実行するように構成される。
声明47. コンピュータ可読ストレージ上で具現され、かつ声明46のコンピュータ機器上で実行するとき声明1～45のうちのいずれかの方法を実行するように構成される、コンピュータプログラム。
本明細書で開示する別の態様によれば、第1の参加者およびコーディネータのアクションを備える方法が提供され得る。
本明細書で開示する別の態様によれば、第1の参加者およびコーディネータのコンピュータ機器を備えるシステムが提供され得る。
本明細書における開示が与えられると、開示する技法の他の変形形態または使用事例が当業者に明らかになり得る。本開示の範囲は、説明した実施形態ではなく添付の特許請求の範囲のみによって限定される。
100 システム
101 コーディネータ
102 参加者
103 サードパーティ
152 トランザクション
201 ヘッダ
202 入力、入力フィールド
203 出力、出力フィールド

Claims (45)

  1. メッセージのデジタル署名のシェアを生成するコンピュータ実装方法であって、前記デジタル署名を生成するために参加者のグループのそれぞれの参加者からのしきい値数の異なる署名シェアが必要とされ、各参加者がそれぞれの秘密鍵シェアを有し、
    前記コンピュータ実装方法が、前記参加者のうちの第1の参加者によって実行され、
    第1のメッセージ非依存成分および第1のメッセージ依存成分を生成するステップであって、
    前記メッセージ非依存成分が第1の秘密鍵シェアに基づいて生成され、
    前記メッセージ依存成分が前記メッセージに基づいて生成され、
    各参加者がそれぞれのエフェメラル秘密鍵シェアを有し、
    前記第1のメッセージ非依存成分および/または前記第1のメッセージ依存成分が第1のエフェメラル秘密鍵シェアに基づく、ステップと、
    前記第1のメッセージ非依存成分をコーディネータにとって利用可能にさせるステップと、
    少なくとも前記しきい値数の署名シェアに基づいて前記デジタル署名を生成するために第1の署名シェアを前記コーディネータにとって利用可能にさせるステップであって、
    前記第1の署名シェアが少なくとも前記メッセージ依存成分を備える、ステップと
    を備える、コンピュータ実装方法。
  2. 前記メッセージ非依存成分が、前記メッセージを取得する前に生成される、請求項1に記載の方法。
  3. 前記第1の署名シェアが前記メッセージ非依存成分を備える、請求項1または2に記載の方法。
  4. 前記第1の秘密鍵シェアが、第1の秘密鍵のシェアを生成するための共同秘密共有方式を使用して生成される、請求項1から3のいずれか一項に記載の方法。
  5. 前記共同秘密共有方式を使用して前記第1の秘密鍵シェアを生成することが、
    第1のデータアイテムを生成するステップであって、前記第1のデータアイテムが第1の多項式である、ステップと、
    少なくとも前記しきい値数の参加者からそれぞれのデータアイテムを取得するステップであって、各それぞれのデータアイテムが、それぞれの参加者によって生成されたそれぞれの多項式である、ステップと、
    前記第1のデータアイテムおよび前記それぞれのデータアイテムの各々に基づいて前記第1の秘密鍵シェアを生成するステップと
    を備える、請求項4に記載の方法。
  6. 前記それぞれのデータアイテムを取得するステップが、
    前記第1の参加者と前記それぞれの参加者の各々との間のそれぞれの通信チャネルを介して前記それぞれのデータアイテムを取得するステップを備える、請求項5に記載の方法。
  7. 前記第1の多項式のそれぞれのインスタンスを少なくとも前記しきい値数の参加者の各々へ送信するステップを備え、
    前記第1の多項式の前記それぞれのインスタンスがそれぞれの参加者に基づく、請求項5に記載の方法。
  8. 各参加者が、前記エフェメラル秘密鍵に対応するエフェメラル公開鍵に基づくそれぞれの共有された値を有し、
    前記第1のメッセージ非依存成分が、前記共有された値に基づく、請求項7に記載の方法。
  9. 前記第1のエフェメラル秘密鍵シェアが、前記エフェメラル秘密鍵のシェアを生成するための前記共同秘密共有方式を使用して生成される、請求項1から8のいずれか一項に記載の方法。
  10. 前記第1のメッセージ非依存成分が、前記第1のエフェメラル秘密鍵シェアに対応する逆元に基づいて生成される、請求項1から9のいずれか一項に記載の方法。
  11. 前記第1のエフェメラル秘密鍵シェアの前記逆元を生成することが、
    前記エフェメラル秘密鍵および第1のブラインディング鍵に基づいて中間値を生成するステップと、
    前記中間値の逆元および前記第1のブラインディング鍵の第1のブラインディング鍵シェアに基づいて前記第1のエフェメラル秘密鍵シェアの前記逆元を生成するステップと
    を備える、請求項10に記載の方法。
  12. 前記第1のブラインディング鍵シェアが、前記第1のブラインディング鍵のシェアを生成するための前記共同秘密共有方式を使用して生成される、請求項11に記載の方法。
  13. 前記中間値が、
    前記第1のエフェメラル秘密鍵シェアおよび前記ブラインディング鍵シェアに基づいて第1の乗法的鍵シェアを生成するステップと、
    少なくとも前記しきい値数の参加者からそれぞれの乗法的鍵シェアを取得するステップと、
    前記第1の乗法的鍵シェアおよび前記それぞれの乗法的鍵シェアの各々に基づいて前記中間値を生成するステップと
    によって生成される、請求項11または12に記載の方法。
  14. 前記第1の乗法的鍵シェアを少なくとも前記しきい値数の参加者の各々へ送信するステップを備える、請求項13に記載の方法。
  15. 前記メッセージ非依存成分が、第2のブラインディング鍵の第2のブラインディング鍵シェアに基づいて生成される、請求項1から14のいずれか一項に記載の方法。
  16. 前記第2のブラインディング鍵シェアが、前記第2のブラインディング鍵のシェアを生成するための前記共同秘密共有方式を使用して生成される、請求項15に記載の方法。
  17. 前記第1のメッセージ非依存成分が、第1の事前署名シェアに基づいて生成され、
    前記第1の事前署名シェアが、
    第1の中間シェアであって、前記第1の秘密鍵シェア、および前記第1のエフェメラル秘密鍵シェアに対応する前記逆元に基づいて生成される、第1の中間シェア、ならびに
    少なくとも前記しきい値数の参加者から取得されたそれぞれの中間シェア
    に基づいて生成される、請求項10またはそれに従属するいずれかの請求項に記載の方法。
  18. 前記第1のメッセージ非依存成分が、第1の事前署名シェアに基づいて生成され、
    前記第1の事前署名シェアが、
    第1の中間シェアであって、前記第1の秘密鍵シェアおよび前記第1のブラインディング鍵シェアに基づいて生成される、第1の中間シェア、
    少なくとも前記しきい値数の参加者から取得されたそれぞれの中間シェア
    に基づいて生成される、請求項1から16のうちのいずれかに従属するときの請求項10に記載の方法。
  19. 前記第1の事前署名シェアが、前記第1のエフェメラル秘密鍵シェアに対応する前記逆元に基づいて生成される、請求項18に記載の方法。
  20. 前記第1の中間シェアが、前記第2のブラインディング鍵シェアに基づいて生成される、請求項17から19のいずれか一項に記載の方法。
  21. 前記第1の事前署名シェアが、前記共有された値に基づいて生成される、請求項17から20のいずれか一項に記載の方法。
  22. 前記第1の中間シェアが、前記共有された値に基づいて生成される、請求項21に記載の方法。
  23. 前記第1の中間シェアを少なくとも前記しきい値数の参加者へ送信するステップを備える、請求項17もしくは18のいずれか一項またはそれに従属するいずれかの請求項に記載の方法。
  24. 前記メッセージ非依存成分の複数の異なるインスタンスを生成するステップを備える、請求項1から23のいずれか一項に記載の方法。
  25. 前記第1のエフェメラル秘密鍵シェアの複数の異なるインスタンスを生成するステップを備える、請求項1から24のいずれか一項に記載の方法。
  26. 前記第1のブラインディング鍵シェアおよび/または前記第2のブラインディング鍵シェアの複数の異なるインスタンスを生成するステップを備える、請求項24または25に記載の方法。
  27. 前記第1の事前署名シェアの複数の異なるインスタンスを生成するステップを備える、請求項17もしくは18のいずれか一項またはそれに従属するいずれかの請求項に記載の方法。
  28. 前記コーディネータから前記メッセージを取得するステップを備える、請求項1から27のいずれか一項に記載の方法。
  29. 前記メッセージを生成するステップを備える、請求項1から28のいずれか一項に記載の方法。
  30. 前記メッセージが第2のメッセージのハッシュである、請求項1から29のいずれか一項に記載の方法。
  31. 前記第1の署名シェアを前記コーディネータにとって利用可能にさせるステップが、
    前記第1の署名シェアを前記コーディネータへ送信するステップ、
    前記しきい値数の参加者のうちの1または複数へ前記第1の署名シェアをブロードキャストするステップ
    のうちの少なくとも1つを備える、請求項1から30のいずれか一項に記載の方法。
  32. 前記第1のメッセージ非依存成分を前記コーディネータにとって利用可能にさせるステップが、
    前記第1のメッセージ非依存成分を前記コーディネータへ送信するステップ、
    前記しきい値数の参加者のうちの1または複数へ前記第1のメッセージ非依存成分をブロードキャストするステップ
    のうちの少なくとも1つを備える、請求項1から31のいずれか一項に記載の方法。
  33. メッセージのデジタル署名を生成するコンピュータ実装方法であって、前記デジタル署名を生成するために参加者のグループのそれぞれの参加者からのしきい値数の異なる署名シェアが必要とされ、各参加者がそれぞれの秘密鍵シェアを有し、各参加者がそれぞれのエフェメラル秘密鍵シェアを有し、
    前記コンピュータ実装方法が、コーディネータによって実行され、
    少なくともしきい値数のそれぞれのメッセージ非依存成分を取得するステップであって、
    各それぞれのメッセージ非依存成分がそれぞれの秘密鍵シェアに基づいて生成される、ステップと、
    少なくとも前記しきい値数のそれぞれの署名シェアを取得するステップであって、
    各それぞれの署名シェアが少なくともそれぞれのメッセージ依存成分に基づき、
    各それぞれのメッセージ依存成分が前記メッセージに基づいて生成される、ステップと、
    前記取得された署名シェアの各々および前記取得されたメッセージ非依存成分の各々に基づいて前記メッセージの前記デジタル署名を生成するステップであって、
    各メッセージ非依存成分および/またはメッセージ依存成分がそれぞれのエフェメラル秘密鍵シェアに基づく、ステップと
    を備える、コンピュータ実装方法。
  34. 各それぞれの署名シェアが前記それぞれのメッセージ非依存成分に基づく、請求項33に記載の方法。
  35. 前記取得されたメッセージ非依存成分の各々に基づいて共通メッセージ非依存成分を生成するステップと、
    前記共通メッセージ非依存成分に基づいて前記デジタル署名を生成するステップと
    を備える、請求項33に記載の方法。
  36. 各参加者が、前記エフェメラル秘密鍵に対応するエフェメラル公開鍵に基づく共有された値を有し、
    各それぞれのメッセージ非依存成分が、前記共有された値に基づく、請求項35に記載の方法。
  37. 前記しきい値数の参加者の中の前記参加者のうちの1、一部、またはすべてに前記メッセージを送信するステップを備える、請求項33から36のいずれか一項に記載の方法。
  38. それぞれの署名シェアに対する要求を少なくとも前記しきい値数の参加者へ送信するステップを備える、請求項33から37のいずれか一項に記載の方法。
  39. 前記取得された署名シェアのうちの1つを生成するステップを備える、請求項33から38のいずれか一項に記載の方法。
  40. 前記デジタル署名を出力するステップを備える、請求項33から39のいずれか一項に記載の方法。
  41. 前記デジタル署名を出力するステップが、
    前記デジタル署名を1または複数の当事者へ送信するステップ、および/または
    デジタル媒体上に前記デジタル署名を記録するステップ、および/または
    前記デジタル署名を公開させるステップ
    を備える、請求項40に記載の方法。
  42. 前記メッセージがブロックチェーントランザクションの少なくとも一部を備える、請求項1から41のいずれか一項に記載の方法。
  43. 参加者の前記しきい値数が、参加者の前記グループの中の参加者の総数よりも少ない、請求項1から42のいずれか一項に記載の方法。
  44. コンピュータ機器であって、
    1つまたは複数のメモリユニットを備えるメモリと、
    1つまたは複数の処理ユニットを備える処理装置と
    を備え、前記メモリが、前記処理装置上で実行するように構成されたコードを記憶し、前記コードが、前記処理装置上で実行されると、請求項1から43のいずれか一項に記載の方法を実行するように構成される、コンピュータ機器。
  45. コンピュータ可読ストレージ上で具現され、かつ請求項46に記載のコンピュータ機器上で実行されると、請求項1から43のいずれか一項に記載の方法を実行するように構成される、コンピュータプログラム。
JP2022564434A 2020-04-23 2021-04-19 秘密共有を伴う（ｅｃ）ｄｓａしきい値署名 Pending JP2023522748A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB2005953.1 2020-04-23
GB2005953.1A GB2594312A (en) 2020-04-23 2020-04-23 Digital Signatures
PCT/EP2021/060032 WO2021213959A1 (en) 2020-04-23 2021-04-19 (ec)dsa threshold signature with secret sharing

Publications (1)

Publication Number Publication Date
JP2023522748A true JP2023522748A (ja) 2023-05-31

Family

ID=71080157

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022564434A Pending JP2023522748A (ja) 2020-04-23 2021-04-19 秘密共有を伴う（ｅｃ）ｄｓａしきい値署名

Country Status (7)

Country Link
US (1) US20230163977A1 (ja)
EP (1) EP4111637A1 (ja)
JP (1) JP2023522748A (ja)
KR (1) KR20230002941A (ja)
CN (1) CN115516817A (ja)
GB (1) GB2594312A (ja)
WO (1) WO2021213959A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220123950A1 (en) * 2020-10-15 2022-04-21 Cisco Technology, Inc. Multi-party cloud authenticator
CN116915416B (zh) * 2023-09-14 2023-12-15 北京信安世纪科技股份有限公司 一种证书签名方法、装置以及一种证书获取方法、装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4274154A3 (en) 2016-02-23 2023-12-20 nChain Licensing AG Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system
GB201805633D0 (en) * 2018-04-05 2018-05-23 Nchain Holdings Ltd Computer implemented method and system

Also Published As

Publication number Publication date
EP4111637A1 (en) 2023-01-04
KR20230002941A (ko) 2023-01-05
WO2021213959A1 (en) 2021-10-28
GB202005953D0 (en) 2020-06-10
US20230163977A1 (en) 2023-05-25
CN115516817A (zh) 2022-12-23
GB2594312A (en) 2021-10-27

Similar Documents

Publication Publication Date Title
JP2023530141A (ja) 秘密のシェアの生成
US20230319103A1 (en) Identifying denial-of-service attacks
US20240097894A1 (en) Threshold key exchange
CN118160275A (zh) 阈值签名方案
US20240121109A1 (en) Digital signatures
JP2023522748A (ja) 秘密共有を伴う（ｅｃ）ｄｓａしきい値署名
JP2024537102A (ja) 共有鍵の生成
JP2024534237A (ja) 共有暗号キーを生成すること
US20240214218A1 (en) Nested threshold signatures
EP4385167A1 (en) Generating digital signatures
JP2024528292A (ja) デジタル署名の生成
KR20240141783A (ko) 셰어드 개인 키의 생성

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240321

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20240911

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20241015