Closed9

MPC Fireblocks memo

ikmzkroikmzkro

ウォレットどうすんの問題

Web3でどのような事業を展開するにも結局のところ暗号資産を誰がどのように管理するのかが重要なポイントになる。要件定義レイヤの会議に参加すると必ず下記に関する議論が出てきてふわっとした状態で終わる。

・自社内でウォレットを作るのか?だとしたらどのレベルまで開発する?
・Saasを利用するとしてどのサービスが工数少なく安全に導入できるのか
・そもそも法に触れないのか

何より秘密鍵の管理手法、トラストポイントの設定、アドレスの権限設定に課題意識が出てくるがうまくまとまらない。最近この課題をうまく解決してくれるウォレットサービスとして話題なのがFireblocks。明日はそのミートアップに参加するので予習する。

Fireblocksは、MPC-CMPという暗号技術と多層のセキュリティ施策によって、安全性と利便性を兼ね備えた企業向けセミカストディアルウォレット(顧客の管理方法によってカストディアルにもノンカストディアルにもなり得るウォレット)を提供

ikmzkroikmzkro

マルチシグ vs MPC

単一秘密鍵の課題をマルチシグで解決したように見えるが実は運用面では課題が残っている。

一人の承認者が変更されればウォレットアドレスも変更する必要がある、チェーンによっては対応できない、マルチシグ方式がチェーンに依存するなどの課題がある。3 of 4で承認するフローを設定している場合秘密鍵は2つまで盗まれてもOK=2 of 4では承認が通らない。

これらを解決するのがMPC。各管理者は秘密鍵を所有するのではなく秘密鍵の断片情報を保持する。

https://zenn.dev/mizuneko4345/scraps/a3b6025242447f

ikmzkroikmzkro

シャミアの秘密分散法

シャミアの秘密分散法に従うとこのようになるはず。閾値+1のべき乗で計算される関数でグラフを書いて点をプロットしていき連立方程式を解くとシークレットが求まる。

  • シェア = 秘密鍵の断片情報
  • 閾値 = 何個シェアが集まればシークレットに復元できるのかの数
  • シークレット = 秘密鍵

https://kimh.github.io/blog/jp/security/protect-your-secret-key-with-shamirs-secret-sharing-jp/
https://github.com/fireblocks/mpc-lib/blob/main/src/common/crypto/shamir_secret_sharing/verifiable_secret_sharing.c

ikmzkroikmzkro

秘密鍵はありません!

「STAP細胞はあります!」のように一見虚言のように思えるが本当に秘密鍵がない。
元々存在する秘密鍵を断片するのかと思っていたが、キーシェアを断片してからアドレスを作成する模様。

MPCの技術を署名に応用したものの1つにTSS (閾値署名)というマルチシグに性質が似た技術がある。TSSはMPCの1種で、いくつかのキーシェア(Key shares, 鍵の断片のようなもの)のうち、決められた数のキーシェアによって作成された署名を組み合わせることにより有効な署名を作成することができる技術。これによってトランザクションの作成時に各キーシェアで作成した分散署名を組み合わせることによって、元の秘密鍵によって署名されたのと同等の署名を作成することができます。この時各々のキーシェアを一箇所に集めることなく、バラバラに分散署名を作成することができるため、署名時に秘密鍵自体が作成されることはありません。

また、FireblocksのMPC-CMPでは最初のキーシェアの作成時に元々存在する秘密鍵からキーシェアを分割するのではなく、各キーシェアをバラバラに作成してからアドレスを作成します。つまりキーシェアの作成時からトランザクションの署名までのどのタイミングにおいても秘密鍵自体が生成されることがないため安全性が高いと言えます。

ikmzkroikmzkro

MPCを使うメリットの整理

担当者の変更時に毎回ウォレットアドレスの変更が必要になる可能性がある

→MPCは運用者が変更になってもキーシェアを作成/更新することが可能。秘密鍵が存在しないという定義がそもそもイカれてる。

全てのブロックチェーンで対応されているわけではない(チェーンの種類によってはプロトコル依存となる)/ マルチシグの方式がブロックチェーンに依存している

→トランザクション作成はオフチェーンで作成できるのでプロトコルに依存しない。署名アルゴもECDSA or EdDSAなので基本順応できる。

オンチェーンで署名生成されるためTx手数料高い

→署名生成がオフチェーンで可能になるためTx手数料が低減される。

ikmzkroikmzkro

MPC vs MPC-CMP

従来のMPC

  • トランザクションを署名する際にキーシェアの間で6~9周の通信が必要

MPC-CMP

  • 1周分の通信で良いこと (厳密には4周の通信が必要ですが、3周分は事前処理が可能)
  • 発表当時で従来の8倍程度の速度向上

メリット

数分単位でのキーシェアの自動更新やコールド環境下での署名が可能になる。MPCを使ったコールド環境下での署名は各国のカストディ規制下においても重要な機能。

このような機能向上によって、数分単位でのキーシェアの自動更新やコールド環境下での署名といった機能も追加されました。中でもMPCを使ったコールド環境下での署名は各国のカストディ規制下においても重要な機能と考えられます。

法規制の観点なども含めるとFireblocksの得意領域はここなので下記記事に整理した。
https://zenn.dev/mizuneko4345/scraps/716adbf32e77af

ikmzkroikmzkro

MPC-CMPでの単一障害点の排除

Fireblocksでは3-of-3のキーシェアでウォレットを作成する。
暗号資産交換業とFireblocksが連携する場合、交換業側に1つ、Fireblocks側に2つ保管する。

キーシェアの一つは交換業が保管するのでもちろんFireblocksが単独で顧客資産を引き出すことは不可能ですが、一方、ユーザー側には秘密計算を用いて生成されたキーシェアのバックアップは用意されるため、ユーザーのみが実際にウォレットにアクセスすることができます。

TEEを利用した鍵管理や権限システムのハードウェアレベルでの分離

Fireblocks側の保管方法だがTEEと呼ばれる外部からアクセス不可能な環境に保管される。交換業側は法的手段に従いコールドウォレット=ハードウェアウォレット/金庫に保管し常時ネットワークから遮断された環境に保管し、鍵があるなら信頼できる管理者に預けるしかない。人間をどこまで信頼できるかは不確実だが。。。

TEEはここでは深入りしないが仮にクラウドがハックされてもキーシェア(アドレス生成に必要な断片情報)、アドレスロール、トランザクション管理システムなどが秘匿領域に保管されており、盗難できない模様。

トランザクション作成時の権限管理システム (Automated Policy Engine)

トランザクション作成のためには単一責任とならないように下記ロールが存在する模様。マルチシグではないけど同じような発想。

トランザクションの開始者: 発行したいTXを提案するユーザー
トランザクションの承認者: 提案されたTXを承認するユーザー
トランザクションの署名者: ユーザー側のキーシェアを保持し実際に部分署名を作成するユーザー

ikmzkroikmzkro

Fireblocks Direct Custody Principles | Fireblocks https://www.fireblocks.com/principles/
MPC vs. Multi-sig | Fireblocks Blog https://www.fireblocks.com/blog/mpc-vs-multi-sig/
Introducing MPC-CMP: Pushing MPC Wallet Signing Speeds 8X | Fireblocks Blog https://www.fireblocks.com/blog/pushing-mpc-wallet-signing-speeds-8x-with-mpc-cmp-9/
Fireblocks’ MPC-CMP code is Open-Source | Fireblocks Blog https://www.fireblocks.com/blog/fireblocks-mpc-cmp-code-is-open-source/
中学数学で学ぶMPCの仕組み | Stir社内勉強会資料 https://stirnetwork.notion.site/MPC-3578f0b4f5374605a4bb18f9fa26b04b
秘密分散/MPC, TSS等 | questryio https://scrapbox.io/questryio/秘密分散%2FMPC,_TSS等
違いは何?HSM, TPM, セキュアエンクレーブ, セキュアエレメント | wolfSSL https://wolfssl.jp/wolfblog/2022/03/08/difference-hsm-tpm-secure-enclave-secure-element-hardware-root-trust/

このスクラップは3ヶ月前にクローズされました