GG18/GG20の脆弱性CVE-2023-33241が今年の夏くらいに公開されていた模様↓
GG18/GG20は閾値ECDSA署名をサポートするMPCプロトコルで、ブロックチェーン界隈のMPC系のウォレット実装でよく利用されているらしい。CVE-2023-33241は、この2つのプロトコルにおいて、秘密鍵を抽出することができてしまうという脆弱性。この2つ以外に、Lindellの2P-ECDSAも対象っぽい。
脆弱性を確認する前にGG18の中身をまず簡単に調べてみた。Lindellの2P-ECDSAについては、以前書いた記事がある。
GG18
脆弱性の内容の前にまずGG18がt-of-nの閾値ECDSA署名を生成するプロトコルについて簡単にみておく(簡略化してるので詳細はペーパー参照)。
鍵生成
まず最初に参加者全員で鍵生成プロトコルを実行して、各参加者がそれぞれ鍵のシェアを持ち閾値署名が可能になるようFeldmanのVSS(検証可能な秘密分散法)を使用して鍵生成を行う*1。この辺りの仕組みは他のプロトコルでもよく使われる手法。Paillier暗号*2の鍵が登場するのが少し異なるポイントだけど、これを利用するのは署名フェーズ。
参加者の鍵ペアをとすると、具体的な手順は↓
- 各参加者は自身の公開鍵
のコミットメントと、Paillier暗号の公開鍵
をそれぞれ交換する。
- 全参加者は、コミットメントの交換後に、コミットされた公開鍵でデコミットし、公開鍵
を計算する。つまり、Pは全参加者の公開鍵をすべて加算したもの。対応する秘密鍵は全参加者の秘密鍵を合算した値(
)
- 続いて、各参加者は、FeldmanのVSS(検証可能な秘密分散法)を使って、自身の秘密鍵と新たに選択したt − 1個のシークレット値
から、t - 1次の多項式
を構築する*3。ここで、tは閾値。
- 続いて、各参加者のIDでその多項式を評価し、対象のIDのユーザーにその評価値
をシェアとして共有する。
- 次に自分が選択した
について、
を計算し、他の参加者に送信する。
- 自分が受け取ったシェアが正しいか、
が成立するか検証する。
ここまでの計算で、各参加者は以下の秘密鍵のシェアと公開鍵のシェアを持っていることになる。
つまり、ラグランジュ補間を利用すれば、公開鍵とそれに対応する秘密鍵を復元することができる。
最後に、秘密鍵のシェアとPaillier暗号の公開鍵に対応する秘密鍵を持っていることを証明する。
署名プロトコル
鍵生成フェーズで鍵のシェアが生成できたら、実際に閾値数のメンバーが協力すれば有効な署名データを作成することができる。具体的にはラグランジュ係数を使用して、閾値分集まれば多項式の秘密鍵のデータを用いた計算が可能になる。現在IETFで標準化が進められているSchnorr署名の閾値署名プロトコルFROSTでも同様のアプローチを採っている。
メッセージをm、ハッシュ関数をH、署名に使用する秘密鍵をx、署名に使用するプライベートnonceをkとすると、Schnorr署名はという計算になるが、ECDSAの場合
という計算式になり(r.xはR = kGのx座標)、単純に部分署名を加算して集約するということはできないので、工夫が必要になる*4。
Multiplicative to Additive
署名プロトコルの中で実行されるプリミティブの1つがMtA(Multiplicative to Additive)という計算。これは、乗法シェアを加法シェアに変換するためのプロトコル。例えば2人の参加者アリスとボブがそれぞれ秘密の値a, bを持っていると仮定すると、これはx = a * b mod qと考えると、aとbはxに対する乗法シェアをそれぞれ持っていると考えることができる。それをα + β = xとなるような加法シェアα、βをそれぞれアリスとボブが保持する形に変換する。
- アリスはPaillier暗号の公開鍵
を持っており、aを暗号化し
と、aの範囲証明を生成し、ボブに送信。
- ボブはランダムな数値β'を選択し、
を計算し、bとβ'の範囲証明を生成し、アリスに送信。そして
とする。
- アリスは
を復号することで
を入手する。
この結果、となる加法シェアα、βをアリスとボブがそれぞれ保持した状態になる。
署名生成
署名はt人いれば完成できる。ここで、各参加者が保持している秘密鍵のシェアとラグランジュ係数
を乗算した値を
とする。署名生成のプロトコルは↓
- t人の参加者はランダムな値
を選択し、そのコミットメントを送信する。そしてこれらの値と↑のwを使用して計算される値を
および
とする。
- 続いて、参加者iとjのペアは、↑の
および
について、それぞれMtAのシェア変換プロトコルを実行することで、シェアは
および
のような加法シェアに変換される。各参加者は、以下をセットする。
- 各参加者は、
を共有し、
を得る。
- 1で送信したコミットメントをデコミットして
を入手する。
であるため、
を計算することでECDSA署名に用いるPublic nonce Rを得ることができる。ここでRのx座標をrとする。
- 各参加者は、
を計算し、コミット、開示、検証のプロセスを経て共有する*5。これを全部加算すると
という値になり、(r, s)がPKとmに対して有効なECDSA署名となる。
Paillier暗号を用いたシェアの変換を利用して、最終的に有効なECDSA署名を生成できるようにしている。
GG20
GG20は、
- 署名プロセスが不正などを含み中断した場合に、対象者を識別できるようにし、
- 事前処理フェーズを設けてほとんどの計算、通信を行うことでメッセージ署名時の通信ラウンドを削減
するといった改良が加えられているみたい。ただ、MtAの実行やPaillier暗号を使った処理はGG18と同じなので、同様に今回の脆弱性の影響を受けるということみたい。
*1:全参加者が並行してFeldmanのVSSを行い結果を集約するのがPedersenのDKG。FeldmanのVSS単体だと共有シークレットを知るディーラーが存在するが、PedersenのDKGの場合は誰も共有シークレットを知らない
*2:Paillier暗号は、加法準同型性のある暗号化方式で、例えばメッセージを暗号化したデータ
から、暗号化したまま
を計算でき、メッセージ
を暗号化したデータ
に対して任意のスカラー値sを暗号化したまま乗算し、
の暗号データを計算することができる。以前書いたLindellの2P-ECDSAなどでも使用されている。
*4:ペーパーの方では、という形式になってる。
*5:攻撃者がプロトコルを失敗させた場合に、正直な参加者のを学習するのを防ぐため、検証プロセスを経た上で共有するようになっている。具体的なプロトコルはペーパー参照