Fireblocksは何を提供しているのか
安全性と利便性を両立した企業向けのWaaS（Wallet as a Service）
暗号資産業界の発展とともに、顧客から暗号資産を預かったり暗号資産を会社で保有したりする企業が増えてきています。この流れの中で問題となってきているのが、企業が暗号資産を管理する上でのリスクです。これに対してFireblocksは、MPC-CMPという暗号技術と多層のセキュリティ施策によって、安全性と利便性を兼ね備えた企業向けセミカストディアルウォレット（顧客の管理方法によってカストディアルにもノンカストディアルにもなり得るウォレット）を提供しています。
複数人に属するウォレットの管理の難しさ
企業が自社資産や顧客資産を管理する場合は、個人で暗号資産を管理する場合とは違い、その資産が複数人に属するという決定的な違いがあります。
複数人に属するウォレットの管理においての単一秘密鍵での管理の問題のうち大きなものとして、秘密鍵の管理責任リスクと秘密鍵の保管リスクの2つが存在します。
1つ目の管理責任リスクは、管理する資産の性質とその管理の手法との乖離に起因します。個人の場合ではウォレットの秘密鍵を本人が管理していればその管理責任は単にその個人が負うことになりますが、複数人に属する資産を単一の人間が管理することは管理責任的な観点から好ましくありません。単一秘密鍵で管理し、単一の人間がその資産を移動できるということは、その資産が複数人に属するものであるということを表現できていないとも言えます。その具体的なリスクとしては、一担当者による持ち逃げや担当者が不在の場合のオペレーションの停止などが挙げられます。
2つ目の保管リスクにはハード面とソフト面の2種類があります。ハード面では秘密鍵を保管する端末 (ハードウェアウォレット等)の故障・紛失・盗難リスク、ソフト面では保管端末に対するハッキングによる秘密鍵の流出リスクがあり、このどちらもが単一秘密鍵での管理の場合、一度で資産の流出や紛失を引き起こすこととなります。
このようなリスクを防げないことから単一秘密鍵での資産管理は複数人向けウォレットにおいては不適であり、秘密鍵管理をどう多元化・冗長化していくのかが重要となります。
従来の主流 マルチシグの問題点
単一秘密鍵管理問題に対する従来の解決策が、マルチシグという技術でした。
マルチシグは資産管理の各担当者が別々に作成した秘密鍵をもとにウォレットを作成し、決められた数の担当者 （秘密鍵）の署名が集まって初めてそのウォレットから送金が行えるような仕組みです。例えば 3-of-4 （全部で4つの秘密鍵が存在し、そのうちの3つの秘密鍵からの署名を組み合わせれば送金できる状態）のマルチシグでは、4つの秘密鍵のうち1つの秘密鍵が紛失した場合でも送金は行え、4つのうち2つまでの秘密鍵の流出であれば資産が盗まれる心配もありません。
このようにマルチシグは単一秘密鍵管理によるリスクを排除することには成功しましたが、それに伴い以下のようなデメリットも存在しました。
- 担当者の変更時に毎回ウォレットアドレスの変更が必要になる可能性がある
- 全てのブロックチェーンで対応されているわけではない（チェーンの種類によってはプロトコル依存となる）
- マルチシグの方式がブロックチェーンに依存している
これらの利便性低下の問題の解決に使われるのが、MPCという技術になります。
MPCとは
MPC（マルチパーティ計算）とは
MPCとは複数の主体がそれぞれの秘密情報をお互いと共有することなく共同で計算問題を解くことができるという技術です。対象となる計算問題自体は各自が単独で解くことはできない性質のものにもかかわらず、お互いの秘密情報を隠したまま協力して計算を行うことができます。
MPCの技術を署名に応用したものの1つにTSS (閾値署名)というマルチシグに性質が似た技術があります。
一部のキーシェアでの署名が行えるTSS（閾値署名）
TSSはMPCの1種で、いくつかのキーシェア（Key shares, 鍵の断片のようなもの）のうち、決められた数のキーシェアによって作成された署名を組み合わせることにより有効な署名を作成することができる技術です。これによってトランザクションの作成時に各キーシェアで作成した分散署名を組み合わせることによって、元の秘密鍵によって署名されたのと同等の署名を作成することができます。この時各々のキーシェアを一箇所に集めることなく、バラバラに分散署名を作成することができるため、署名時に秘密鍵自体が作成されることはありません。
また、FireblocksのMPC-CMPでは最初のキーシェアの作成時に元々存在する秘密鍵からキーシェアを分割するのではなく、各キーシェアをバラバラに作成してからアドレスを作成します。つまりキーシェアの作成時からトランザクションの署名までのどのタイミングにおいても秘密鍵自体が生成されることがないため安全性が高いと言えます。
マルチシグと比べたMPCの3つの利点
マルチシグと比べたMPCの利点の1つとしては、運用上の柔軟性が高いことがあります。マルチシグでは署名に使用する秘密鍵を変更したい時（ウォレット管理の担当者が異動になった時など）に毎回アドレスを再生成する必要があります。その一方MPCでは、元のアドレスを変更することなく新しいキーシェアを作成することが可能です。何らかの運用上の変更があった場合に毎回アドレスが変更されてしまうのは運用自体をより煩雑にするため、このようなMPCの特徴は大きな利点といえます。
2つ目の利点はプロトコルに依存しないことです。MPCではトランザクションの署名の作成自体をオフチェーンで分散的に行えるため、ブロックチェーンによって対応できないということが起こりません。例えばFireblocksのMPCはECDSAおよびEdDSA署名に対応しているため、現状存在するブロックチェーンのほぼ全てに対応していることになります。
3つ目の利点としてはトランザクション手数料が安くなることがあります。多くのマルチシグ署名においては各々の秘密鍵がオンチェーンで署名を行うため、通常のアドレス（シングルシグ）における署名に比べてトランザクション手数料が高くなります。MPCの場合は署名の作成はオフチェーンで行われるため、通常の署名と変わらない手数料でトランザクションを発行することができます。
従来のMPCよりMPC-CMPが優れている点
Fireblocksで利用されているMPC-CMPは2020年にFireblocksの研究開発チームにより開発されたオープンソースのMPCプロトコルです。トランザクションを署名する際にキーシェアの間で6~9周の通信が必要だった従来のMPCに比べて、この技術では1周分の通信で良いことから （厳密には4周の通信が必要ですが、3周分は事前処理が可能）発表当時で従来の8倍程度の速度向上が行われました。
このような機能向上によって、数分単位でのキーシェアの自動更新やコールド環境下での署名といった機能も追加されました。中でもMPCを使ったコールド環境下での署名は各国のカストディ規制下においても重要な機能と考えられます。
Fireblocksにおけるセキュリティ
FIreblocksにおけるセキュリティは複数の層によって構成されており、主なものとしては以下の3つの項目があります。
- MPC-CMPでの単一障害点の排除
- TEEを利用した鍵管理や権限システムのハードウェアレベルでの分離
- トランザクション作成時の権限管理システム (Automated Policy Engine)
MPC-CMPでの単一障害点の排除
Fireblocksでは3-of-3のキーシェア（3つ存在するキーシェアの全ての署名を組み合わせることによって有効な署名の作成が可能）を用いてウォレットを作成します。具体的には3つのキーシェアのうちの2つがFireblocks管理下のクラウド上のTEE （信頼された実行環境, 詳細は後述）内に存在し、残りの一つはユーザーが管理を行います（SaaSモデルの場合）。
前述の通り、ウォレットの生成時やトランザクションの署名時において3つの鍵が一箇所に存在することなくバラバラに秘密計算を行うため、通常の運用時に秘密鍵が生成され単一障害点となることはありません。
また、3つのキーシェアのうちの一つはユーザー側のみにしか存在しないため、Fireblocksが単独で顧客資産を引き出すことは不可能な仕組みとなっています（一方ユーザー側には秘密計算を用いて生成されたキーシェアのバックアップは用意されるため、ユーザーのみが実際にウォレットにアクセスすることができます）。 Fireblocks管理下の2つのキーシェアはクラウド上にありホット環境に存在しますが、3つ目のユーザー管理のキーシェアについては以下のようにユーザーが管理方法をカスタマイズすることでウォレット全体の性質を変更することができます。
- ホットウォレット（インターネット接続下にあり送金などが自動化されたウォレット）
- ウォームウォレット（インターネット接続下にあるが送金に人間が介入するウォレット）
- コールドウォレット（インターネットに接続されていない環境で管理されるウォレット）
ユーザーとFireblocksの2者でキーシェアを管理する運用体制によってキーシェアの管理が多様化し、外部からの攻撃に対する耐性が増していると言えます（キーシェアの地理的分散やユーザー側では難しいTEE下でのキーシェアの運用が可能になる）。
TEEを利用した鍵管理や権限システムのハードウェアレベルでの分離
TEEとは内部のプログラムや記録が外部から読み取ったり改竄したりできないような性質（耐タンパ性）を持った、システムから隔離された実行環境のことです。TEE内ではあらかじめ定められたアルゴリズムによる処理を外部から観測されることなく行うことができ、内部の機密情報が流出することもありません。
Fireblocksにおけるクラウド管理の2つのキーシェアはTEE内部に保存されているため、万が一ハッキングなどのクラウド内部への侵入があったとしてもキーシェア自体は盗まれません。これはクラウドサービスの管理者やFireblocksの従業員に関しても同様となります。キーシェアだけではなくユーザーの権限やトランザクションの管理システムもTEE内部に存在しており、クラウド内のOSからは権限やアルゴリズムの書き換えは不可となっています（ただし厳密に言うとTEE自体を信頼できた上での話となります）。
トランザクション作成時の権限管理システム (Automated Policy Engine)
キーシェアと同様にTEE内部に存在しているトランザクション発行時の権限管理システムでは、ユーザー側に複数の役割が存在します。
- トランザクションの開始者: 発行したいTXを提案するユーザー
- トランザクションの承認者: 提案されたTXを承認するユーザー
- トランザクションの署名者: ユーザー側のキーシェアを保持し実際に部分署名を作成するユーザー
これら3つの役割の管理者がトランザクションの作成時に多重に審査を行うことで、1人の管理者でトランザクションの作成が行えないような仕組みになっています（トランザクションの開始者と承認者はFireblocks管理下のキーシェアを間接的にコントロールしていると言えます）。また、複数存在する署名権限を持ったメンバーのキーシェアは全て別々のものとなっており、各自がキーシェアを紛失した場合でも秘密計算を用いて新たなキーシェアを作成することが可能です（暗号化されたバックアップもFireblocksのクラウド上に存在されます）。
まとめ
複数人管理のウォレットの重要性が増す中、従来のマルチシグではなくMPCという技術を利用することによりFireblocksは柔軟性や冗長性の高いウォレットシステムを提供しています。
MPCだけではなくTEEなどの多層のセキュリティによって資産の安全性を高めるFireblocksは、MPC-CMP技術のオープンソース化や内部システムの監査（SOC 2の取得や定期的な侵入テスト）を通してサービスの透明化と信頼性の向上にも努めています。
企業向けの他にもFireblocksはto C向けのノンカストディアルウォレットを提供するサービスの展開を開始しており今後に注目です。
また秘密鍵を分散しかつそれぞれを1箇所に集めることなく署名を行ったり、鍵の一部を紛失した場合にも復旧が比較的簡易なMPCという技術は暗号資産やプライバシー技術の発展により今後ますます使われていくことになるでしょう。
参考文献
- 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/
