*編集者注: このテクノロジーは、アプリケーションによる並列および分散処理、ビッグデータおよびクラウド コンピューティング、持続可能なコンピューティングおよびコミュニケーション、ソーシャル コンピューティングおよびネットワーキング (ISPA/BDCloud/SocialCom/SustainCom) に関する 2023 IEEE 国際会議で公開されました。 DOI: 10.1109/ISPA-BDCloud-SocialCom-SustainCom59178.2023.00092*

＃ 導入

Li17 は業界で最も高速で安全な 2-2 ECDSA 署名であり、CGGMP20 は業界で最も安全で比較的高速な tn ECDSA しきい値署名です。デジタル資産保管の分野では、2 ～ 3 ECDSA しきい値署名が広く使用されています。この場合、Li17 2-2 署名は直接使用できないため、適切に変更する必要があります。具体的には、次の変更が行われます。アリスとボブは、分散鍵生成プロトコルを実行して秘密鍵フラグメント $a$ と $b$ をそれぞれ生成し、次に分散鍵リフレッシュ プロトコルを 2 回実行して $(a ', b')$ を生成します。 $(a'', b'')$; アリスは $a'$ をキャロルに内密に送信し、ボブは $b''$ をキャロルに内密に送信します。したがって、アリスとボブは秘密鍵シャーディング $(a,b)$ を使用し、アリスとキャロルは秘密鍵シャーディング $(a'', b'')$ を使用し、ボブとキャロルは秘密鍵シャーディング $(a' ,b) を使用します。 ')$、すべて署名を達成できます。ただし、上記のプロセスでは秘密鍵の断片が直接送信されるため、秘密鍵の断片が漏洩した場合、責任を追跡できず、ストレージの負担が増大します。一方、CGGMP20 tn しきい値署名では $t=2,n=3$ を使用する必要があります。ただし、CGGMP20 のプロトコルの複雑さは比較的高いため、大きなナイフでニワトリを殺すことはできません。

Li17 の巨人の肩の上に立って、この記事は高速かつ安全な 2-n ECDSA しきい値署名を提案します。このプロトコルは、Li17 2-2 署名のセキュリティと速度を継承しています。

具体的には、分散鍵生成プロトコルと鍵リフレッシュプロトコルでは、ラグランジュ補間多項式に基づいてしきい値が構築され、2-n しきい値署名が実現されます。さらに、事前署名段階ではランダム メッセージが事前に計算され、オンライン署名段階ではメッセージとランダム メッセージの差分のみに署名する必要があるため、オンライン署名段階の速度が向上します。したがって、この記事の 2-n ECDSA しきい値署名は、Li17 2-2 署名プロトコルと同じくらい安全で、署名速度も高速です。

# 2-n ECDSA しきい値署名

初期化: 楕円曲線グループ $\mathbb{G}$ の生成子は $G$ で、次数は $\tilde{q}$ です。

##プロトコル 1: 分散鍵生成

**ステップ 1:** 各ユーザー $i$ は、自身の Paillier 鍵ペア $({{N}_{i}},{{p}_{i}},{{q}_{i}} )$ を生成します。

乱数 ${{u}_{i}}\in [0, \tilde{q}-1]$ を選択し、次のように楕円曲線の点を計算します。

$${{U}_{i}}:={{u}_{i}}\cdot G.$$

次に、Promise を計算し、Promise を開きます。

$$(KG{{C}_{i}},KG{{D}_{i}}):=\mathsf{Com}({{U}_{i}}).$$

ブロードキャストコミットメント $KG{{C}_{i}}$ と Paillier 公開鍵 ${{N}_{i}}$、ストア乱数 ${{u}_{i}}$、Paillier 秘密鍵 ${ {p}_{i}}、{{q}_{i}}$、およびオープンコミットメント $KGD_i$。

ブロードキャストコミットメント $KG{{C}_{i}}$ と Paillier 公開鍵 ${{N}_{i}}$、ストア乱数 ${{u}_{i}}$、Paillier 秘密鍵 ${ {p}_{i}}、{{q}_{i}}$、およびオープンコミットメント $KGD_i$。

**ステップ 2:** コミットメント $KG{{C}_{j}},j\ne i$ と Paillier 公開鍵 ${{N}_{j}},j\ne i を他のユーザーから受け取った場合$ の後、ユーザー $i$ はオープン コミットメント $KG{{D}_{i}}$ を他のユーザーにブロードキャストします。

**ステップ 3:** 各ユーザー $i$ は、他のユーザーから受け取ったすべてのオープンコミットメントが正しいことを検証します。

有効な場合、共同公開キーは次のように計算されます。

$$PK:=\sum\limits_{i=1}^{n}{U_i}.$$

**ラグランジュ冗長性**の構築: 乱数 $a_i\in [0,\tilde{q}-1]$ を選択し、一次多項式を構築します。

$${{p}_{i}}(x)={{u}_{i}}+x\cdot a_i.$$

${{p}_{i}}(i)$ を保存し、${{p}_{i}}(j)$ を他のユーザー $j$ に密かに送信します。

**フェルドマンタプル**を計算します:

$${{A}_{i}}:={{a}_{i}}\cdot G$$

$A_i$ をブロードキャストします。

**ステップ 4:** 各ユーザー $i$ は、他のユーザーから送信された ${{p}_{j}}(i)$ と $\{{{A}_{j}}\},j を受信します =1 ,...,n $、**フェルドマンタプル**の一貫性を検証します。

$${{p}_{j}}(i)\cdot G={{U}_{j}}+i\cdot {{A}_{j}}.$$

秘密鍵シャードと公開鍵シャードを次のように計算します。

$$\begin{整列}

& {{x}_{i}}:=\sum\limits_{j=1}^{n}{{{p}_{j}}(i)}\,\bmod \,\チルダ{q} =sk+\sum\limits_{j=1}^{n}{(j\cdot {{a}_{j}})}\,\bmod \,\チルダ{q}, \\

& {{X}_{i}}:={{x}_{i}}\cdot G. \\

\end{整列}$$

次に、zk-Schnorr を使用して秘密鍵フラグメント ${{x}_{i}}$ を知っていることを証明し、zk-Paillier-Blum を使用して ${{N}_{i}}$ が Paillier であることを証明します。 -ブルム係数。

${{x}_{i}}$ を Paillier 公開鍵 ${{N}_{i}}$ を使用して暗号化します

$${{c}_{key,i}}:=\mathsf{Enc}_{{{N}_{i}}}({{x}_{i}})$$

zkレンジプルーフ

$$zk\left\{ {{x_i},{r_i}\left| \begin{array}{l}

{{c}_{key,i}} ={{(1+{{N}_{i}})}^{{{x}_{i}}}}r_{i}^{{{N }_{i}}}\bmod N_{i}^{2}、\\

{{X}_{i}} ={{x}_{i}}\cdot G, \\

{{x}_{i}} \in {{\mathbb{Z}}_{\tilde{q}}}

{{X}_{i}} ={{x}_{i}}\cdot G, \\

{{x}_{i}} \in {{\mathbb{Z}}_{\tilde{q}}}

\end{配列} \right.} \right\}$$

公開鍵フラグメント $X_i$、暗号文 $c_{key,i}$、および 3 つの zk 証明をブロードキャストします。

**ステップ 5:** 各ユーザー $i$ が他のユーザーの公開鍵フラグメント ${{X}_{j}},j\ne i$ および zk 証明を受信したら、3 つの zk-proof を検証します。さらに、各ユーザーは次のようにラグランジュ補間の一貫性を検証します。

$$PK=\lambda _{i,j}\cdot X_i +\lambda _{j,i}\cdot X_j,$$

このうち、$\lambda_{i,j}$ と $\lambda_{j,i}$ は、対応するラグランジュ補間係数です。

分散鍵生成プロトコルの実行が完了すると、各ユーザー$i$は秘密鍵フラグメント$x_i$、公開鍵フラグメント$X_i$、共同公開鍵$PK$、および$n-1$暗号文$を取得します。 c_{key_j}、j \neq i$。

##プロトコル 2: 分散キー更新

**ステップ 1:** 各ユーザー $i,i=1,...,n$ は乱数 $a_i'\in [0,\tilde{q}-1]$ を選択し、**ラグランジュ多項式 * を構築します*：

$$p_i'(x)=x\cdot a_i'.$$

定数項は 0 であることに注意してください。 ${{p}_{i}}'(i)$ を保存し、${{p}_{i}}'(j)$ を各ユーザー $j$ に密かに送信します。次に、**フェルドマンタプル**を計算します。

$$A_i':=a_i'\cdot G$$

$A_i'$ をブロードキャストします。

**ステップ 2:** 各ユーザー $i$ は、他のユーザーから $p_j'(i)$ と $\{A_j'\},j=1,...,n$ を受け取り、**フェルドマン要素を検証しますグループ**の一貫性:

$$p_j'(i)\cdot G=i\cdot A_j'.$$

新しい秘密鍵シャードと新しい公開鍵シャードを次のように計算します。

$$\begin{整列}

& x_i':=x_i+a_j', \\

& X_i':=x_i'\cdot G. \\

\end{整列}$$

次に、zk-Schnorr は $x_i'$ を知っていることを証明します。

パイリエ公開鍵 ${{N}_{i}}$ を使用して $x_i'$ を暗号化します

$$c_{key,i}':=\mathsf{Enc}_{{{N}_{i}}}(x_i')$$

zk 範囲の証明:

$$zk\left\{ {x_i',r_i'\left| \begin{array}{l}

c_{key,i}' = {(1 + {N_i})^{x_i'}}{(r_i')^{{N_i}}}\bmod N_i^2\\

X_i' = x_i' \cdot G\\

c_{key,i}' = {(1 + {N_i})^{x_i'}}{(r_i')^{{N_i}}}\bmod N_i^2\\

X_i' = x_i' \cdot G\\

x_i' \in {\mathbb{Z}_{\チルダ q}}

\end{配列} \right.} \right\}$$

新しい公開鍵フラグメント $X_i'$、暗号文 $c_{key,i}'$、および 2 つの zk-proof をブロードキャストします。

**ステップ 3:** 各ユーザー $i$ は、他のユーザーの公開鍵フラグメント $X_j',j\ne i$ と 2 つの zk-proof を受け取り、2 つの zk-proof の有効性を検証します。さらに、各ユーザーはラグランジュ補間の一貫性を検証できます。

$$PK=\lambda _{i,j}\cdot X_i' +\lambda _{j,i}\cdot X_j',$$

このうち、${{\lambda }_{i,j}}$ と ${{\lambda }_{j,i}}$ は、対応するラグランジュ補間係数です。

分散鍵リフレッシュプロトコルが完了すると、各ユーザー$i$は新しい秘密鍵フラグメント$x_i'$、新しい公開鍵フラグメント$X_i'$、および$n -1$の新しい暗号文$c_{key_j}',jを取得します。 \neq i$。

##契約 3: 事前に署名された契約

**ステップ 1:** ユーザー $i$ は、次のように計算された乱数 ${{k}_{i}}\in [0,\tilde{q}-1]$ を選択します。

$${{R}_{i}}:={{k}_{i}}\cdot G.$$

zk-Schnorr は乱数 ${{k}_{i}}$ を知っていることを証明します。

$$proo{{f}_{i}}:=zk\left\{ {{k}_{i}}\left| {{R}_{i}}={{k}_{i}} \cdot G \right. \right\}.$$

${{R}_{i}}$ と $proo{{f}_{i}}$ について、コミットメントを計算し、コミットメントをオープンします

$$\left[ KG{{C}_{i}},KG{{D}_{i}} \right]:=\mathsf{Com}({{R}_{i}},proo{{ f}_{i}}).$$

コミットメント $KG{{C}_{i}}$ をユーザー $j$ に送信します。

**ステップ 2:** コミットメント $KG{{C}_{i}}$ を受け取った後、ユーザー $j$ は [0,\チルダ { q}-1]$、計算します

$${{R}_{j}}:={{k}_{j}}\cdot G$$

zk-Schnorr は乱数を知っていることを証明する

$$proo{{f}_{j}}:=zk\left\{ {{k}_{j}}\left| \cdot G \right. \right\}.$$

次に、$({{R}_{j}},proo{{f}_{j}})$ をユーザー $i$ に送信します。

**ステップ 3:** $({{R}_{j}},proo{{f}_{j}})$ を受け取った後、ユーザー $i$ はコミットメントの一貫性を検証します。矛盾する場合は拒否し、矛盾する場合はコミット $KG{{D}_{i}}$ が開かれ、ユーザー $j$ に送信されます。

**ステップ 4:** $({{R}_{i}},proo{{f}_{i}})$ を受け取った後、ユーザー $j$ は Promise の一貫性をチェックします。矛盾する場合は拒否し、そうでない場合は次のように計算します。

$$\begin{整列}

R&:={{k}_{j}}\cdot {{R}_{i}}, \\

$$\begin{整列}

R&:={{k}_{j}}\cdot {{R}_{i}}, \\

r&:={{R}_{[x]}}\bmod \チルダ{q},

\end{整列}$$

ここで、${{R}_{[x]}}$ は $R$ の $x$ 座標を表します。

ランダムなメッセージ ${{m}_{0}}\in [0,\tilde{q}-1]$ と乱数 $\rho \in [0, {{\tilde{q}}^{ 2}}-1]$、計算します

$${{c}_{0}}:=\mathsf{Enc}_{{{N}_{i}}}(k_{j}^{-1}\cdot {{m}_{0} }\bmod \tilde{q}+\rho \cdot \tilde{q}).$$

次に、次のように計算します

$$\begin{整列}

& {{c}_{1}}:=\left( ({{\lambda }_{i,j}}\odot {{c}_{key,i}})\oplus \mathsf{Enc}_ {{{N}_{i}}}({{\lambda }_{j,i}}{{x}_{j}}) \right)\odot (k_{j}^{-1}r )、\\

& {{c}_{2}}:={{c}_{0}}\oplus {{c}_{1}}。

\end{整列}$$

最後に、${{c}_{2}}$ がユーザー $i$ に送信され、$({{m}_{0}},r)$ が保存されます。

**ステップ 5:** ${{c}_{2}}$ を受信した後、ユーザー $i$ は次のように Paillier 秘密鍵を使用して復号化します。

$${{s}_{0}}:=\mathsf{Dec}_{{{p}_{i}},{{q}_{i}}}({{c}_{2}} ).$$

次に、次のように計算します

$$\begin{整列}

& {{s}_{1}}:=k_{i}^{-1}\cdot {{s}_{0}}\bmod \tilde{q}, \\

& R':={{k}_{i}}\cdot {{R}_{j}},\\

& r':=R_{[x]}'\bmod \tilde{q}。

\end{整列}$$

${{s}_{1}}$ と $r'$ を保管します。

*分析 1:*

なぜなら

$${{k}_{j}}\cdot {{R}_{i}}={{k}_{i}}{{k}_{j}}\cdot G={{k}_ {i}}\cdot {{R}_{j}}$$

したがって、$R=R'$、つまり $r=r'$ となります。

一方、${{c}_{1}}$ の式は次のとおりです。

$$\begin{整列}

{{c}_{1}} & =\left( ({{\lambda }_{i,j}}\odot {{c}_{key,i}})\oplus \mathsf{Enc}_{ {{N}_{i}}}({{\lambda }_{j,i}}{{x}_{j}}) \right)\odot (k_{j}^{-1}r) \\

{{c}_{1}} & =\left( ({{\lambda }_{i,j}}\odot {{c}_{key,i}})\oplus \mathsf{Enc}_{{{N}_{i}}}({{\lambda }_{j,i}}{{x}_{j}}) \right)\odot (k_{j}^{-1}r) \\

& =\left( \mathsf{Enc}_{{{N}_{i}}}({{\lambda }_{i,j}}{{x}_{i}})\oplus \mathsf{Enc}_{{{N}_{i}}}({{\lambda }_{j,i}}{{x}_{j}}) \right)\odot (k_{j}^{-1}r) \\

& =\mathsf{Enc}_{{{N}_{i}}}({{\lambda }_{i,j}}{{x}_{i}}+{{\lambda }_{j ,i}}{{x}_{j}})\odot (k_{j}^{-1}r) \\

& =\mathsf{Enc}_{{{N}_{i}}}(x)\odot (k_{j}^{-1}r) \\

& =\mathsf{Enc}_{{{N}_{i}}}(k_{j}^{-1}rx)。

\end{整列}$$

${{c}_{2}}$ の式は次のとおりです。

$$\begin{整列}

{{c}_{2}} & ={{c}_{0}}\oplus {{c}_{1}} \\

& =\mathsf{Enc}_{{{N}_{i}}}(k_{j}^{-1}{{m}_{0}}\bmod \tilde{q}+\rho \tilde {q})\oplus \mathsf{Enc}_{{{N}_{i}}}(k_{j}^{-1}rx) \\

& =\mathsf{Enc}_{{{N}_{i}}}(k_{j}^{-1}{{m}_{0}}\bmod \tilde{q}+\rho \tilde {q}+k_{j}^{-1}rx)。

\end{整列}$$

したがって、${{s}_{0}}$ の式は次のようになります。

$${{s}_{0}}=k_{j}^{-1}{{m}_{0}}\bmod \tilde{q}+\rho \tilde{q}+k_{j} ^{-1}rx.$$

${{s}_{1}}$ の式は次のとおりです。

$$\begin{整列}

{{s}_{1}} & =k_{i}^{-1}{{s}_{0}}\bmod \tilde{q} \\

& =k_{i}^{-1}k_{j}^{-1}{{m}_{0}}\bmod \tilde{q}+k_{i}^{-1}k_{j} ^{-1}rx\bmod \チルダ{q} \\

& ={{k}^{-1}}{{m}_{0}}+{{k}^{-1}}rx\bmod \チルダ \\

\end{整列}$$

*分析 2:* アクティブで安全なしきい値署名を達成する場合、参加者は各署名後に秘密鍵シャードを更新する必要があります。キー更新プロトコルには 2 ラウンドの対話が必要ですが、事前署名プロトコルには 4 ラウンドが必要です。効率を向上させるために、2 つのプロトコルを統合できます。具体的には、事前署名プロトコルと分散鍵リフレッシュプロトコルの双方向データを同時に送信することができる。このアプローチにより、分散キー リフレッシュ プロトコルの 2 回の個別の対話が不要になり、ユーザー認証などのプロセスが簡素化され、効率が向上します。

##プロトコル 4: オンライン署名

**ステップ 1:** メッセージ $msg$ について、ユーザー $j$ は次の計算を行います。

##プロトコル 4: オンライン署名

**ステップ 1:** メッセージ $msg$ について、ユーザー $j$ は次の計算を行います。

$$\チルダ{m}:=(\mathsf{ハッシュ}(msg)-{{m}_{0}})\bmod \チルダ{q}.$$

それから計算します

$${{c}_{3}}:=\mathsf{Enc}_{{{N}_{i}}}(k_{j}^{-1}\tilde{m}\bmod \tilde{ q}).$$

${{c}_{3}}$ をユーザー $i$ に送信します。

**ステップ 2:** ${{c}_{3}}$ を受信した後、ユーザー $i$ は秘密鍵を使用して復号化します

$${{s}_{2}}:=\mathsf{Dec}_{{{p}_{i}},{{q}_{i}}}({{c}_{3}} ).$$

次に、次のように計算します。

$$\begin{整列}

& {{s}_{3}}:=(k_{i}^{-1}{{s}_{2}})\bmod \tilde{q}, \\

& {{s}_{4}}:=({{s}_{1}}+{{s}_{3}})\bmod \チルダ \\

\end{整列}$$

$s=\min \{{{s}_{4}},\tilde{q}-{{s}_{4}}\}$ とします。メッセージ $msg$ の場合、$(r, s)$ が有効な署名であれば受け入れ、そうでなければ拒否します。

*分析 1:* ${{s}_{2}}$ と ${{s}_{3}}$ の式はそれぞれ

$$\begin{整列}

& {{s}_{2}}=k_{j}^{-1}\チルダ{m}\bmod \チルダ{q}, \\

& {{s}_{3}}=k_{i}^{-1}k_{j}^{-1}\tilde{m}\bmod \tilde{q}={{k}^{-1 }}\チルダ{m}\bmod \チルダ{q}。

\end{整列}$$

${{s}_{4}}$ の式は次のとおりです。

$$\begin{整列}

{{s}_{4}} & =({{s}_{1}}+{{s}_{3}})\bmod \チルダ{q} \\

& ={{k}^{-1}}{{m}_{0}}+{{k}^{-1}}rx+{{k}^{-1}}\チルダ{m}\bmod \チルダ{q} \\

& ={{k}^{-1}}(\チルダ{m}+{{m}_{0}})+{{k}^{-1}}rx \\

& ={{k}^{-1}}(\mathsf{ハッシュ}(msg)+rx) .\\

\end{整列}$$

したがって、$(r, s)$ はメッセージ $msg$ の有効な署名です。

*分析 2:*

\end{整列}$$

したがって、$(r, s)$ はメッセージ $msg$ の有効な署名です。

*分析 2:*

(1) 楕円曲線の対称性により、ECDSA シグネチャに延性が導入されます。 $(r, s)$ が有効な署名の場合、$(r, \tilde{q}-s)$ も有効です。したがって、2-n しきい値署名プロトコルには順応性がありません。つまり、$(r, s)$ と $(r, \tilde{q}-s)$ は両方とも有効な署名です。この問題を防ぐには、$s = \min\{s, \tilde{q}-s\}$ を使用して $s$ の値を標準化し、延性を排除します。 (2) BitForge 攻撃を防ぐには、署名が失敗した場合は、分散キー リフレッシュ プロトコル プロトコルを実装します。

**参考文献**

1. Lindell Y. Fast secure two-party ECDSA signed[C]//Advances in Cryptology – CRYPTO 2017: 37th Annual International Cryptology Conference、米国カリフォルニア州サンタバーバラ、2017 年 8 月 20 ～ 24 日、議事録、パート II 37。 Springer International Publishing、2017: 613-644。

2. Canetti R、Gennaro R、Goldfeder S、他、識別可能な中断を伴う UC 非インタラクティブ、プロアクティブ、しきい値 ECDSA [C]//2020 年コンピューターおよび通信セキュリティに関する ACM SIGSAC 会議の議事録: 1769-1787。

3. Makriyannis N、Yomtov O.: 主要な MPC ウォレットにおける実用的なキー抽出攻撃 [J]、2023 年。

シノホープについて

SINOHOPE Technology Holdings Co., Ltd. (「SINOHOPE」、証券コード: 1611.HK) は、デジタル資産の保管に重点を置き、あらゆる企業がデジタル資産を安全かつ便利に使用できるよう、さまざまな保管ソリューションを提供しています。同社の中核製品である MPC セルフホスト プラットフォーム SINOHOPE は、MPC-CMP テクノロジーを使用して秘密キーのシャーディングと共同署名のユーザーの分散管理をサポートし、秘密キーの単一点リスクを解決し、透明性と使いやすさを効果的に高めます。

SINOHOPEは、安全性、コンプライアンス、専門性、多様化のサービス原則を遵守し、MPCセルフカストディプラットフォームとライセンスされたデジタル資産カストディサービスに基づいて、シンプルで使いやすい集中型および分散型混合産業サービスを提供します。カスタマイズされた OTC ブロック取引、仮想資産管理、および機関や富裕層顧客の開発者向けに特別に設計されたワンストップの Web3 製品構築ソリューション サービスを提供します。

会社ウェブサイト: www.sinohope.com

投資家向け相談: [email protected]

メディアに関するお問い合わせ: [email protected]