こちらの続きです
MPC-TSS（閾値署名）のRefreshの動作を確認します
MPC-TSS-Refreshのココがすごい
- 公開鍵を変えることなく各Partyの「鍵シェア」を変更可能
- これにより、公開鍵を変えずに漏洩した「鍵シェア」を無効化できる
- よって、サービスを止めずに鍵ローテーションが可能
本実験では、ReshareではなくRefreshとなります。Reshareだと更にこんなこともできます。
- Partyの数を増減させることが可能。その際も公開鍵は変更不要
- Refresh = 同じメンバーで鍵を作り直す
- Reshare = メンバー構成ごと変える（追加・削除）
実験内容
- 3人で鍵を再共有（refresh）できることを確認
- refreshを開始するとParty間で計算データのやり取りが行われるので、その様子を観察
- refresh後に署名できることを確認
- refresh前と同じ公開鍵により署名検証できることを確認
- refresh前の古い鍵が混じると署名できないことを確認
実験手順
１～６はSign編と同じ
１．コンテナ起動
２．Node-RED起動
３．Keygen実行
４．署名するファイルのアップロード
５．Sign実行
６．署名検証実行
７．Refresh実行
ダッシュボード画面で「REFRESH開始」をクリック
Refreshが完了すると、ダッシュボードの「鍵シェアのハッシュ」画面が更新される
８．Refresh後に署名＆署名検証
手順５～６を再度実施
Refresh後の署名も、Keygen時の公開鍵で署名検証できる
実験結果
本実験ではMPCプロトコルにGG18を使用しています。
鍵の再共有（Refresh）ができていることの確認
ダッシュボードの「鍵シェアのハッシュ」画面で、各コンテナに格納されている鍵の値が変わっていることが確認できる。
下の例では、14時46分台の3行はKeygenの際のログで、14時48分台の3行はRefresh後のログとなっており、Refreshで鍵の値が変わっていることが分かる。
Refresh時のParty間通信シーケンス
- round 0 ～ 3 で行われる
- Round 0：改ざん検知のためのコミット
- Round 1：暗号通信の準備
- Round 2：新しい鍵シェアの配布
- Round 3：不正検知・合意
Refresh前の古い鍵が混じると署名できないことを確認
以下コマンドでParty1だけ鍵を古いものに戻す
> docker exec -it party1 mv /workspace/co_signer1.key /workspace/co_signer1.key.new
> docker exec -it party1 mv /workspace/co_signer1.key.bak /workspace/co_signer1.key
この状態で、ダッシュボードで署名を開始すると、Round 0 のデータのやり取りが行われた後、先に進まなくなる。
これは、各Partyが持つ鍵シェアが一致しないため、MPCプロトコルの整合性チェックに失敗しているためである。
つまり、
- Refresh前の鍵とRefresh後の鍵は互換性がない
- 一部のノードが古い状態のままだと署名プロトコルは成立しない
ことを意味している。
停止する場合は Ctrl+C を押下
Refresh編 以上