TL;DR

  • しきい値暗号とは、暗号操作を実行する能力を複数の参加者に分割するものです。操作は、承認されたしきい値の参加者が協力した場合にのみ成功します。しきい値署名では、参加者は完全な秘密鍵を事前に再構築することなく、1つのグループ公開鍵の下で共同で通常のデジタル署名を生成します。
  • 表記「t-of-n」は、意図された操作を行うためにn人の参加者のうち少なくともt人が必要であることを意味します。安全なスキームは通常、t人未満の不正参加者から鍵の秘密性を保護し、少なくともt人の適切な参加者がオンラインである限り可用性を維持することを目指します。これらの保証は、定義された攻撃者、ネットワーク、および実装モデルに依存します。
  • シャミールの秘密分散は、保存された秘密を分割し、しきい値によってそれを再構築できるようにするものです。単純なシャミールの秘密分散では、秘密が分割されたままの状態でのECDSA、シュノール、またはEdDSA署名の計算方法は定義されていません。しきい値署名プロトコルは内部でシャミールのシェアを使用する場合もありますが、対話型計算、証明、ノンスの処理、および検証を追加しているため、再構築は不要となります。
  • 場合による。DKGベースのシステムでは、参加者が共同でシェアとグループ公開鍵を作成するため、プロトコルの前提条件下では、単一の参加者が完全な秘密鍵を知ることはありません。ただし、信頼できる販売業者、インポートされた鍵の変換、または再構築バックアップにより、セットアップ時や復旧時に完全な鍵が生成される可能性があります。答えを決定するのは、マーケティング上のラベルではなく、ライフサイクルです。
1つのブロックで

MPCは広範な分野です。しきい値署名はMPCの応用例の一つであり、あらゆる多者間計算システムの同義語ではありません。 t-of-nしきい値署名では、通常、署名を生成するためにn人の参加者のうち少なくともt人の参加が必要であり、t人未満の不正行為から秘密を保護することを目的としています。可用性と秘密性のしきい値の両方を考慮する必要があります。 シャミールの秘密分散は、保存された秘密を分割するのに最適です。単独で使用すると、通常の署名を行う前にその秘密を再構築しますが、しきい値署名では、シェアが分散されたままの状態で署名計算を実行します。 安全な分散鍵生成プロトコルによって最初からシェアが生成される場合、完全な秘密鍵が存在する必要は全くありません。ただし、信頼できるディーラーを利用したり、既存の鍵をインポートしたり、バックアップを復元したりするシステム…

しきい値暗号とは何か？

簡単な回答

しきい値暗号とは、暗号操作を実行する能力を複数の参加者に分割するものです。操作は、承認されたしきい値の参加者が協力した場合にのみ成功します。しきい値署名では、参加者は完全な秘密鍵を事前に再構築することなく、1つのグループ公開鍵の下で共同で通常のデジタル署名を生成します。

従来の署名鍵は、権限が集中している。秘密鍵を使用できる者は誰でも署名でき、それを永久に失った者はアクセス権を失う可能性がある。バックアップは可用性を向上させるが、同じ権限の追加のコピーを生み出すことになる。しきい値暗号は構造を変える：参加者はシェアを保有し、暗号操作は共同で計算される。その目的は、単一のデバイス、オペレーター、または侵害だけでは、盗難と永久的な損失の両方に対して不十分となるようにすることである。

「しきい値（threshold）」という言葉は、「3分の2」や「5分の3」といったポリシーを表します。2分の3の署名設計では、権限を持つ参加者のうち任意の2人が操作を完了できます。 参加者1人だけでは、署名を行うことも、基礎となる秘密情報を知ることさえできないようにすべきです。シェアは、デバイス、ハードウェアセキュリティモジュール（HSM）、サーバー、オフラインシステム、あるいは異なる人々の手に保管される場合があります。アーキテクチャは演算そのものと同じくらい重要です。1人のクラウド管理者が管理する3つのシェアは、3つの独立した当事者というよりは、1つの障害ドメインのように振る舞う可能性があります。

MPCはしきい値署名よりも広い概念である。セキュア多者間計算（MPC）は、当事者が公開される情報を制御しつつ、秘密の入力に対して関数を評価する方法を研究するものである。しきい値鍵生成、署名、復号、および乱数生成は、その特殊な応用例である。したがって、「MPC」として販売されているウォレットは、プロトコル、しきい値、復旧設計、セキュリティモデルが全く異なるものを使用している可能性がある。ラベルだけでは、実際の保証内容についてはほとんど何も示さない。

t-of-nは実際に何を保証するのか？

簡単な回答

表記「t-of-n」は、意図された操作を行うためにn人の参加者のうち少なくともt人が必要であることを意味します。安全なスキームは通常、t人未満の不正参加者から鍵の秘密性を保護し、少なくともt人の適切な参加者がオンラインである限り可用性を維持することを目指します。これらの保証は、定義された攻撃者、ネットワーク、および実装モデルに依存します。

しきい値は、万能な保証ではありません。専門家は、秘密性、偽造防止性、可用性、堅牢性、および説明責任を区別しています。ある設計では、鍵を保護しつつも、1人の悪意のある参加者がすべての署名試行を中断させることを許容する場合があります。また、妨害者を特定できても、その参加者を置き換えない限り署名を完了できない場合もあります。静的な攻撃者モデル下では1人の侵害された署名者を許容できても、攻撃者が時間の経過とともに異なる署名者を侵害した場合に失敗することもあります。

特性この特性が回答する問いその重要性
秘密性／鍵のプライバシーt 個未満のシェアによって、秘密鍵、あるいはそれを再構築するのに十分な情報が漏洩してしまうか？基盤となる認証機関を、閾値未満の侵害から保護する。
偽造防止攻撃者は、許可されたしきい値を持たずに有効な署名を生成できるか？しきい値署名の核心となるセキュリティ目標。
活性性十分な数の誠実な参加者が利用可能な場合、彼らは操作を完了できるか？安全であっても、常に処理が中断してしまうウォレットは使用できません。
堅牢性メッセージの形式が不正であったり、悪意のある参加者がいたりしても、プロトコルは単に中止するのではなく、処理を完了させることができるか？サービス拒否攻撃に対する耐性を決定する。
特定可能な中止プロトコルが失敗した場合、誠実な当事者は、どの参加者が不正行為を行ったかを特定できるか？排除、説明責任、および運用上の復旧を支援する。
予防的なセキュリティシェアを更新することで、異なるタイミングで発生した侵害が無限に蓄積されるのを防げるか？このモデル下では、攻撃者が利用できる更新ウィンドウを1つに制限します。
適応型セキュリティ攻撃者がプロトコルセッションを観察している最中、あるいは観察後に、誰を侵害するかを決定した場合はどうなるか？長期運用される本番システムをより忠実にモデル化しています。
構成可能性保証は、多数の同時セッションや周辺プロトコルが存在する場合でも維持されるか？大規模な署名を行うサービスにとって重要である。

「t 個未満のシェアでは何も明らかにならない」という表現でさえ、その適用範囲を明確にする必要があります。シャミールの完全秘密分散は、数学的なシェアに関する情報理論的な定理を示しています。一方、実稼働中のしきい値ウォレットは、トランскриプト、公開コミットメント、ログ、タイミング情報、エラーメッセージも生成します。これらの周辺システムは、理想的な秘密分散定理に矛盾することなく、メタデータを漏洩させたり、選択入力攻撃を可能にしたり、実装上の欠陥を露呈させたりする可能性があります。

要点：t-of-nはクォーラムを示すに過ぎない。攻撃者モデル、悪意のある署名者がシステムを停止させられるかどうか、シェアが更新可能かどうか、あるいはコードが独立して検証されているかどうかについては示さない。

なぜシャミールの秘密分散はしきい値署名と同じではないのか？

簡単な回答

シャミールの秘密分散は、保存された秘密を分割し、しきい値によってそれを再構築できるようにするものです。単純なシャミールの秘密分散では、秘密が分割されたままの状態でのECDSA、シュノール、またはEdDSA署名の計算方法は定義されていません。しきい値署名プロトコルは内部でシャミールのシェアを使用する場合もありますが、対話型計算、証明、ノンスの処理、および検証を追加しているため、再構築は不要となります。

シャミールの1979年の手法は、秘密をランダム多項式の定数項として表現するものである。各参加者は、その多項式上の1つの点を受け取る。必要な閾値を満たせば、多項式を補間して秘密を復元できるが、点の数が不足していると秘密は特定できない。これは、バックアップ、エスクロー資料、および復旧用秘密を保護するための、洗練された強力な手法である。

運用上の制約は、秘密鍵を使用しなければならない場面で現れる。利用可能な手段がシャミールの再構成のみである場合、権限を持つ参加者は1台のマシン上で各自のフラグメントを結合し、完全な秘密鍵を取得した上で、通常の署名アルゴリズムを呼び出す。その瞬間、再構成装置、メモリ、プロセスログ、スワップ領域、およびオペレーターが単一の脆弱性ポイントとなる。秘密鍵はその後消去できるが、攻撃対象領域は存在していたことになる。

しきい値署名では、シェアに対して演算が行われます。参加者は部分値を生成し、それらの値が正しく形成されていることを証明または検証した上で、部分結果を組み合わせて署名を作成します。署名セッション中に完全な署名鍵が現れる必要はありません。多くのしきい値方式は、構成要素の一つとしてシャミール式の多項式分割を利用しています。真の違いは、一方では再構成を伴う秘密情報の保存と、他方では完全な分散型署名プロトコルとの間にあります。

機能単純なシャミール・バックアップしきい値署名
複数の場所に秘密を分散して保存するはい。はい。ただし、ライブキーシェアまたはプロトコル状態としてです。
しきい値未満の使用再構築は行われません。このセキュリティモデルでは、有効な署名は生成されません。
鍵を再構築せずに署名するいいえ、それだけでは不可能です。はい。
通常の署名を1つ生成する再構築と通常の署名を行った後にのみ。はい、署名シェアを組み合わせることで可能です。
ノンスとトランスクリプトの制御が必要単なる保存のためだけではありません。はい。これらは署名のセキュリティにおいて極めて重要です。
公開鍵を変更せずに参加者を変更する明示的な再共有プロセスが必要です。スキームがリフレッシュまたは再共有をサポートしている場合にのみ可能。
最適コールドバックアップおよび災害復旧。分散型権限による反復的な運用署名。

完全な秘密鍵は存在することになるのでしょうか？

簡単な回答

場合による。DKGベースのシステムでは、参加者が共同でシェアとグループ公開鍵を作成するため、プロトコルの前提条件下では、単一の参加者が完全な秘密鍵を知ることはありません。ただし、信頼できる販売業者、インポートされた鍵の変換、または再構築バックアップにより、セットアップ時や復旧時に完全な鍵が生成される可能性があります。答えを決定するのは、マーケティング上のラベルではなく、ライフサイクルです。

Threshold signature lifecycle diagram. It compares trusted-dealer or imported-key setup with distributed key generation, then shows live shares, participant validation, nonce commitments or preprocessing, signature-share generation, aggregation and ordinary chain verification. A warning explains that the full key may exist in dealer or import paths but not in a correctly executed DKG path.

図2。「鍵は決して存在しない」というのは、セットアップ、署名、バックアップ、復旧の各段階で完全な鍵が生じないよう設計されたライフサイクルにおいてのみ正確である。

信頼できるディーラー

ディーラーは通常の秘密鍵を生成し、シェアを作成して配布する。ディーラーが強固な乱数を使用し、すべての参加者を認証し、シェアリングのコミットメントを検証し、元の秘密鍵と未使用のシェアを確実に消去すれば、これは安全である可能性がある。とはいえ、完全な鍵を把握している瞬間と主体が生じてしまう。RFC 9591では、鍵生成はメインのFROSTプロトコルの外に行われ、信頼できるディーラーの手順は付録としてのみ含まれている。

分散鍵生成

DKGプロトコルでは、参加者がランダム性を提供し、共同でシェアと共通の公開鍵を導出します。プロトコルが正しく実装され、不正閾値を超えない限り、いかなる単一の当事者も対応する秘密鍵を知ることにはなりません。DKGは単一のアルゴリズムではありません。異なるスキームは、ブロードキャスト、認証済みチャネル、苦情、悪意のある当事者、および参加者の可用性について、それぞれ異なる仮定を置いています。

既存の鍵のインポート

機関によっては、既存のアドレス、取引履歴、または公開鍵を維持したい場合がある。一部のプロトコルは、既存の鍵の変換や共有をサポートしている。そのプロセスでは、鍵の所有者が鍵全体を扱う必要がある場合もあれば、専用のインポートプロトコルが使用される場合もある。インポート前のセキュリティ履歴は依然として重要である。鍵を配布しても、それ以前に作成されたコピー、写真、バックアップ、あるいは漏洩は取り消されない。

復旧と緊急時の再構築

一部のシステムでは、バックアップ資料から鍵を再構築する「緊急時の手段」を用意しています。これにより災害復旧が改善される一方で、しきい値設計が回避しようとしていた「単一鍵の露出」が再び生じる可能性があります。他のシステムでは、意図的に再構築手段を設けず、あらゆる復旧アクションに対して生存している参加者のしきい値を要求します。どちらの選択肢も自動的に正しいとは限りません。選択は明示的に行われ、テストされ、脅威モデルに組み込まれるべきです。

MPCは、複数のシェアからどのようにして1つの署名を生成するのでしょうか？

簡単な回答

当事者らは正確なメッセージとセッションについて合意し、ワンタイムのランダム性またはコミットメントを生成し、各自の秘密シェアから署名シェアを計算し、それらのシェアを検証して集約します。出力は、グループ公開鍵に基づく標準的な署名となります。このプロトコルは、完全な秘密鍵ではなく、最終的な署名とアプリケーションが公開するメタデータのみを開示します。

デジタル署名は、メッセージ、公開鍵、および秘密の署名素材間の数学的関係である。しきい値プロトコルは、署名スキームの代数構造を活用するか、一般的なセキュア計算ツールを使用することで、各参加者が自身の入力シェアを明かすことなく、その関係に貢献できるようにする。詳細はシュノル式署名とECDSAで大きく異なるが、運用ライフサイクルには共通の段階がある。

  • セッションの確立。システムは、グループ鍵、参加者セット、閾値、正確なメッセージ、チェーン固有の署名ダイジェスト、プロトコルバージョン、および一意のセッション識別子を定義する。
  • 入力の検証。各参加者は、メッセージが構文的に有効であり、ポリシーによって許可されていることを確認する。しきい値プロトコルは、任意の入力に対する署名オラクルとなってはならない。
  • ノンスまたは事前署名の準備。参加者は、1回限りの秘密値、コミットメント、および一部のECDSA方式では乗算素材を生成する。これらの値は一意であり、セッションに正しく紐付けられ、鍵素材と同様に保護されなければならない。
  • 署名シェアの生成。少なくとも t 人の参加者が、各自の秘密シェアを共通のトランスクリプトと組み合わせ、部分署名または関連する MPC 出力を生成する。
  • シェアの検証と集約。無効なシェアは拒否される。コーディネーターまたはすべての参加者が、有効なシェアを組み合わせて1つの最終署名を作成する。
  • 通常の検証。ブロックチェーンまたはアプリケーションは、通常の検証機能を使用して、グループ公開鍵の下で最終署名を検証します。内部のしきい値プロトコルを理解する必要はありません。

コーディネーターはプロトコルの役割であり、必ずしも信頼された鍵保有者である必要はない。例えばFROSTでは、コーディネーターは、秘密シェアを受け取ることなく、コミットメントを収集し、署名者セットを選択し、メッセージを配布し、シェアを集約することができる。それでも、コーディネーターはサービス拒否を引き起こしたり、矛盾したビューを送信したり、悪意のあるメッセージを提示したりする可能性があるため、認証された通信と参加者側での検証は依然として必要である。

ノンス、前処理、コーディネーターが重要な理由

簡単な回答

しきい値署名では、ワンタイムのノンス素材、参加者のコミットメント、および共有トランскриプトを巡るプロトコル状態が導入される。ノンスの再利用や偏り、セッションの混同、不正な形式の証明の受け入れ、あるいは参加者が異なるメッセージに署名することを許容すると、グループ鍵が漏洩したり、無効な署名が生成されたりする可能性がある。前処理はレイテンシを改善するが、保護しなければならない貴重な署名前在庫を生み出す。

ノンスは秘密の一部である

Schnorr、EdDSA、ECDSAの各署名方式はすべて、一般に「ノンス」と呼ばれる署名ごとの秘密値に依存しています。通常の単一当事者による署名では、信頼できる境界内で、堅牢なライブラリがノンスを生成または導出できます。一方、しきい値プロトコルでは、複数の当事者が共同でノンスに関連する状態を構築または計算します。ノンスの再利用、コミットメントのリプレイ、あるいは意図的に不正な形式の乗算メッセージは、1つ以上の署名セッションを鍵抽出攻撃にさらす可能性があります。 RFC 9591では、通常のEdDSAに適した決定論的なノンス導出は、多者間環境では安全ではなく、一意な一様ランダムなノンスの生成が必要であると明示的に警告している。

前処理はメッセージ送信前に実行される

多くのしきい値ECDSAシステムでは、トランザクションが判明する前に計算負荷の高い処理を実行します。これにより、オンラインフェーズを少数のメッセージに削減でき、コールド署名者や高遅延ネットワークにとって有用です。その代償は運用面にあります。プリシグネチャは1回限りの暗号資産となります。再利用、ロールバック、レプリカ間の重複、または状態同期の喪失は壊滅的な結果を招く可能性があります。バックアップでは、消費済みのプリシグネチャを未使用であるかのように復元してはなりません。

セッションバインディングによるミックス・アンド・マッチ攻撃の防止

すべてのメッセージは、プロトコルバージョン、グループ公開鍵、参加者セット、メッセージダイジェスト、チェーン、ネットワーク、署名者の役割、および一意のセッションにバインドされるべきである。参加者は、古くなった、あるいは一貫性のないコミットメントを拒否し、最終的なトランザクションのバイトがポリシーによって承認されたバイトと同一であることを確認しなければならない。ここがアプリケーション設計と暗号技術が交わる点である。形式的に安全な署名コアであっても、アダプタが誤ったペイロードを供給した場合、間違ったチェーン、間違ったノンス、間違ったコントラクト呼び出し、あるいは間違った宛先に署名してしまう可能性がある。

堅牢性は自動的に得られるものではない

一部のプロトコルは秘密性と偽造防止を保証するが、1人の参加者が不正行為を行った場合に処理を中止する。特定可能な中止（identifiable abort）は、失敗の責任を負う参加者を特定できるが、堅牢性（robustness）は、一部の悪意ある当事者が存在しても処理を完了させることを目指す。RFC 9591は堅牢性を主張しておらず、ROASTのような上位レベルのラッパーが、特定の設定において悪意のある妨害に対処できると指摘している。

FROSTとは何か、またRFC 9591は何を標準化しているのか？

簡単な回答

FROSTは、2回の通信ラウンドを経て署名を生成するしきい値シュノールプロトコルである。RFC 9591は、署名プロトコル、暗号スイート、およびテストベクトルを規定している。分散鍵生成、堅牢性、メタデータ保護、あるいは1ラウンドの前処理バリアントについては標準化しておらず、インターネット標準ではなく、IRTFの研究用情報RFCである。

FROSTは、シュノール署名の線形構造を活用しています。選択された各参加者は、グループ署名鍵のシェアを保持します。第1ラウンドでは、参加者はワンタイムノンスを生成し、コミットメントを公開します。第2ラウンドでは、メッセージ、署名者セット、およびコミットメントに紐づけられた署名シェアを計算します。コーディネーターはこれらのシェアを検証・加算し、最終的なシュノール署名を取得します。

RFC 9591には以下が含まれるRFC 9591自体は、
2ラウンドのFROST署名プロトコル。完全な分散鍵生成標準。
Ed25519、ristretto255、Ed448、P-256、およびsecp256k1用の暗号スイート。同じ曲線を使用するすべてのプロトコルとの自動的な互換性。
署名シェアの検証および集約手順。悪意のある参加者に対する堅牢な完了処理。
参考資料として、信頼できるディーラーによる鍵生成について付記。セットアップ中に完全な鍵が存在しなかったことの保証。
ノンスの再利用、サイドチャネル、およびメッセージの妥当性検証に関するセキュリティ上の考慮事項。メタデータのプライバシー、ダウングレード防止、またはポスト量子セキュリティ。
指定されたスイートに対するテストベクトル。チェーン固有のトランザクション解析、ポリシー、またはウォレットの復旧。

研究用 RFC とインターネット標準との区別は重要です。RFC 9591 は Crypto Forum Research Group の合意を反映しており、実装者に正確で共通の仕様を提供していますが、そのステータスセクションには、これは情報提供を目的としたものであり、IETF の標準化トラックには含まれていないと明記されています。NIST は別途、しきい値方式に関する複数年にわたる評価プロセスを開始しており、FROST はその評価対象として検討されている方式の一つです。

RFC secp256k1スイートはビットコインのTaprootと互換性がありますか？

必ずしもそうとは限りません。ビットコインのBIP340では、xのみの公開鍵、タグ付きハッシュ、特定のチャレンジ方程式、および64バイトのエンコーディングが定義されています。RFC 9591のFROST secp256k1暗号スイートは、独自のドメイン区切りハッシュ構成と汎用的な圧縮点の処理を採用しています。プロトコルが同じ曲線を使用しても、BIP340検証ツールが拒否する署名が生成される可能性があります。 したがって、ビットコイン互換のしきい値シュノール署名には、BIP340のセマンティクスに合わせて明示的に設計された構成と実装が必要です。

要点：「secp256k1を使用している」ということは、互換性の保証にはなりません。曲線は署名システムの構成要素の一つに過ぎないのです。

なぜ閾値ECDSAは閾値シュノールよりも難しいのか？

簡単な回答

シュノール署名は線形であるため、適切に重み付けされた署名シェアを加算することができます。一方、ECDSAには秘密のノンスの逆数による乗算が含まれており、当事者は共有秘密を明かすことなく、その積や逆数を計算しなければなりません。そのためには、追加のMPC機構、証明、およびプロトコルラウンドが必要となります。

簡略化すると、ECDSA署名には値 s = k^-1(H(m) + r x) mod q が含まれます。ここで、x は秘密鍵、k はワンタイムノンスです。 しきい値設定では、x も k もいずれの当事者にも知られてはならない。したがって、参加者は、x と k を含む積、そして最終的には逆数に関連する式の加法的または多項式のシェアを取得すると同時に、悪意のある当事者が別のシェアを漏洩させるような不正な値を選択することを防止しなければならない。

Paillierベースのプロトコルは、加法同型暗号および乗算から加算への変換（MtA）サブプロトコルを使用する。他のプロトコル群では、クラス群やオブリビウス転送が用いられる。 ゼロ知識証明や整合性チェックにより、暗号化された値とシェアが所定の範囲内にあり、プロトコルの関係式を満たしていることが実証される。これらの構成要素は、しきい値シュノル方式よりも実装上の負担が大きくなる：大整数演算、証明システム、トランскриプト管理、前処理、障害原因の特定、および複数の暗号学的仮定などである。

次元しきい値シュノール／FROSTしきい値ECDSA
コア代数線形関係。署名シェアは加法的に結合可能。共有ノンスの逆数および秘密鍵の積を含む非線形関係。
典型的な署名インタラクションRFC 9591では2ラウンド；RFC外には前処理のバリエーションが存在する。プロトコルによって異なる。オンライン／オフラインの設計により、オンラインフェーズを短縮できる。
補助プリミティブ素数順序群、ハッシュ、秘密分散、コミットメント、およびシェア検証。Paillier 暗号やクラス群暗号、オブリビオス転送、範囲証明、ゼロ知識検証が追加される場合がある。
実装の複雑さかなり高いが、比較的単純である。実装の難易度は高く、歴史的にも落とし穴が多い。
検証者の出力選択したスイートに対する通常のシュノール署名、または互換性のある署名。チェーン固有のエンコーディング規則が満たされている場合は、通常のECDSA署名。
プロトコルの全体像FROSTには共通のCFRG仕様がある。いくつかのプロトコルファミリーが存在し、単一の普遍的な導入標準は存在しない。

ビットコインのレガシーおよび SegWit v0 キーによる支出、イーサリアムの外部所有アカウント、その他多くの導入済みシステムが ECDSA を検証しているため、しきい値 ECDSA は依然として重要です。既存のアドレスやハードウェアとの互換性がその複雑さを正当化する可能性はありますが、攻撃対象領域が拡大することを明確に認識した上で選択を行う必要があります。

どのしきい値ECDSAプロトコルファミリーが重要か？

簡単な回答

実用化および研究の分野には、Gennaro-GoldfederやCGGMPといったPaillier/MtAプロトコル、Doerner-Kondi-Lee-Shelatによる2者間および多者間プロトコル、クラス・グループ構成、そして新しい2ラウンドおよび3ラウンドの設計などが含まれます。GG18、GG20、CGGMP21といった名称は、論文を指すものであり、互換性のある単一の業界標準を示すものではありません。

この分野は急速に進化しており、プロトコルの通称はしばしば不正確に使用されます。実装者は、論文の正確な改訂版、パラメータセット、セキュリティ証明、およびコードのバージョンを特定する必要があります。「GG18」と記述されたライブラリは、後のパッチが組み込まれていたり、必要な証明が省略されていたり、独自の前処理が追加されていたり、あるいは古い脆弱性のある亜種が実装されていたりする可能性があります。通称に含まれる年号だけでは、セキュリティを保証する十分な根拠とはなりません。

プロトコル／ファミリー形状重要な貢献または注意点
Lindell-Nofおよび関連する2者間ECDSA主に2-of-2設計。2者間の実用的な分散鍵生成および署名。異なるセキュリティ仮定や構成が存在する。
GG18 / 更新版Gennaro-Goldfeder一般的なしきい値型ECDSA。Paillier/MtAを用いた高速なディーラーレスセットアップおよび実用的な多者間署名。実装の詳細や改訂が重要である。
GG20前処理を伴う汎用しきい値ECDSA。非対話型のオンラインフェーズと識別可能な中止機能を追加。公開された改訂版で問題が修正された。
CGGMP / CGGMP21署名者の数は任意。プロアクティブかつUC指向の設計。所定の仮定の下で、前処理、プロアクティブな更新、適応型セキュリティ、および識別可能な中止を組み合わせたもの。
DKLS 2 者間および多者間ファミリーOT ベースの ECDSA プロトコル。一部の構成では Paillier の仮定を回避。その後の研究により、3 ラウンドの不正多数派署名が可能となった。
クラス群およびより新しい構成様々な閾値およびオンライン／オフラインのトレードオフ。帯域幅、ラウンド数、仮定、または説明責任の改善を目指す。NISTの公募では複数の候補が募集されている。

本記事では、これらのプロトコルの順位付けは行っていない。性能は、参加者数、地理的分布、閾値、前処理、ハードウェア、可用性の仮定、および実装の品質に依存する。新しい論文が、成熟した実装よりも自動的に安全であるとは限らず、また、基礎となる論文が十分に研究されているという理由だけで、成熟した実装が安全であるとは限らない。

FROST、MuSig2、および通常のマルチシグはどのように異なるのか？

簡単な回答

FROSTは、1つのグループ鍵のシェアを使用するt-of-nしきい値シュノール方式である。MuSig2は、複数の独立したシュノール鍵を集約し、n人の署名者全員を必要とするため、一般的なしきい値方式ではなくn-of-n方式である。通常のオンチェーンマルチシグは、ブロックチェーンスクリプトまたはコントラクトに対し、独自のポリシーに従って複数の鍵や署名を検証するよう求めるものである。

特徴FROSTMuSig2オンチェーン・マルチシグ／コントラクトウォレット
署名者の構成1つのグループ秘密鍵のシェア。複数の完全かつ独立した秘密鍵。複数の完全な鍵、またはその他のスマートコントラクトで定義された権限。
クオラムt-of-n。n-of-n。チェーン固有の m-of-n またはプログラム可能なポリシー。
検証者は以下を確認します1つの署名と1つのグループ公開鍵。1つの集約シュノール署名と集約鍵。複数の署名、スクリプトの実行、またはコントラクトの呼び出し — Taproot キーパスなどの仕組みによって隠されていない限り。
鍵生成ディーラーまたはDKG／分散型セットアップ。既存の公開鍵の非対話型集約。各署名者は通常の鍵を作成し、ポリシーはオンチェーンで展開される。
参加者の差し替えサポートされている場合は、再共有を通じてグループ公開鍵を維持できる。署名者が変更されると、集約鍵も変更される。多くの場合、新しいスクリプト、コントラクトの状態の更新、または新しいアドレスが必要となるが、設計は様々である。
主な標準リファレンス2ラウンドのFROST署名についてはRFC 9591を参照。BIP340 互換の MuSig2 については BIP327。ビットコインスクリプト/Taprootのルール、イーサリアムのコントラクトコード、またはその他のチェーン固有のメカニズム。

MuSig2は、複数の当事者が協力するため、しきい値署名と呼ばれることがあります。BIP327では、これがt-of-nしきい値署名ではなく、n-of-nマルチシグ方式であることを明示しています。集約に使用されるすべての鍵は、完全な署名鍵のままです。1人の参加者が利用できない場合、別途フォールバックパスが存在しない限り、グループは署名を行うことができません。

Taprootは可視性の比較を複雑にします。MuSig2やその他の集約されたキーパスによる支出は、通常の単一署名者によるBIP340の支出のように見えることがあり、オプションのスクリプトパスは使用されない限り隠されたままです。スクリプトパスによる支出は、実行された分岐と証明を明らかにしますが、必ずしもすべての未使用の分岐を明らかにするわけではありません。したがって、「マルチシグは可視であり、しきい値署名は不可視である」という主張は、あまりにも絶対的すぎます。

しきい値署名とオンチェーン・マルチシグ：どのようなトレードオフが異なるのか？

簡単な回答

オンチェーン・マルチシグでは、独立した鍵やコントラクトロジックを用いて、ブロックチェーンがクォーラムを強制します。一方、しきい値署名では、オフチェーンでクォーラムを強制し、チェーンには1つの公開鍵と署名のみを提示します。マルチシグは通常、より単純で独立して検証可能なポリシーを提供します。しきい値署名は、より複雑なオフチェーン暗号技術を代償として、コンパクトな署名、ポリシーのプライバシー、および潜在的なアドレスの継続性を提供します。

この比較は普遍的な順位付けではありません。ビットコインスクリプト、Taproot、イーサリアムのスマートコントラクトアカウントは、それぞれ異なる機能を提供します。効率的なネイティブマルチシグをサポートするチェーンもあれば、コントラクトウォレットを必要とするものや、柔軟なスクリプト機能を全く備えていないものもあります。しきい値署名では、チェーン側には馴染みのある署名が提示されますが、オフチェーンのプロトコルが信頼できる計算基盤（TCB）の一部となります。

次元オンチェーン・マルチシグしきい値署名
クォーラムが適用される場所ブロックチェーンの検証ルールまたはコントラクトコードによって。オフチェーンの暗号プロトコルによって。
鍵各署名者は通常、完全に独立した鍵を保持しています。各参加者は、1つのグループ署名鍵の一部を保有します。
監査可能性構成によっては、ポリシーや署名がオンチェーンで検証可能となる場合があります。検証者は通常、1つの鍵と1つの署名を確認しますが、内部のクォーラムはオンチェーンでは証明されません。
手数料とフットプリントより多くのデータやコントラクトの実行が必要になる場合がありますが、Taprootの集約機能によりこれを軽減できます。通常、チェーン層では通常の署名が1つ必要です。
障害の隔離1人の署名者のバグがあっても、必ずしも他の完全な鍵が漏洩するわけではありません。プロトコルや実装上の欠陥により、誠実な参加者からグループキーが抽出されてしまう場合があります。
アドレスの継続性ポリシーを変更すると、スクリプトや契約の状態が変更されることが多く、設計は様々です。一部の再共有プロトコルでは、同じグループ公開鍵とアドレスが維持される。
移植性チェーンのスクリプトやコントラクトのサポート状況に依存します。正確な署名の互換性と、チェーンアダプタの正確さに依存します。
復旧バックアップキー、遅延、ガバナンスをチェーン上で直接エンコードできます。オフチェーンでの更新、再共有、バックアップ、およびサービス設計に依存します。

両方を組み合わせた設計が有用である。例えば、Taprootの出力は、日常的な支出に集約型または閾値型のキーパスを使用し、時間遅延や緊急時の復旧用に隠されたスクリプトパスを保持することができる。イーサリアムのスマートアカウントでは、閾値生成されたECDSA署名に加え、契約レベルでの制限を要求することができる。階層化はリスクを低減できる一方で運用上の複雑さを増すため、各復旧ブランチは単に文書化するだけでなく、実際にテストを行う必要がある。

しきい値署名はどのブロックチェーンでも機能しますか？

簡単な答えは「いいえ」です。しきい値プロトコルは、対象チェーンが検証する署名、公開鍵形式、メッセージダイジェストを正確に生成しなければなりません。楕円曲線が一致することは、場合によっては必要ですが、それだけでは不十分です。チェーン固有のハッシュ化、エンコーディング、正規化、復旧識別子、アドレスの導出、トランザクションのセマンティクスなどが、互換性を損なう可能性があります。

ブロックチェーンの署名スタックは、数学的曲線、署名方程式、公開鍵のエンコーディング、署名のエンコーディング、トランザクションのシリアライズ、署名用ダイジェスト、ドメインの分離、正規値のルール、およびアカウントやスクリプトのセマンティクスといった複数の層から構成されています。しきい値署名は、これらすべてに一致する必要があります。「同じ曲線を持つあらゆるチェーンで機能する」という表現は、このスタックの大部分を無視しています。

互換性レイヤーその重要性を示す例
曲線と群secp256k1、P-256、Ed25519は、それぞれ異なる群とエンコーディングを使用しています。
署名方程式secp256k1 上の汎用シュノールは、自動的にビットコインの BIP340 シュノールになるわけではありません。
チャレンジハッシュ／ドメインの分離同じ R および公開鍵であっても、ハッシュ規則が異なれば異なるチャレンジが生成される可能性があります。
署名のエンコーディングビットコインのBIP340では、固定の64バイトのエンコーディングが使用されます。ECDSAシステムでは、DER、コンパクト、またはr/sに加え、リカバリメタデータが使用される場合があります。
正規化イーサリアムとビットコインのポリシーは、高SのECDSA署名を異なる方法で制限しています。しきい値アダプタは、許容される値を出力する必要があります。
ダイジェストの署名ビットコインのsighashフラグ、イーサリアムの型付きトランザクション、および契約固有のメッセージは、それぞれ異なるバイトシーケンスに署名します。
アドレスの導出同じ公開鍵が、異なるチェーンやアカウントタイプにおいて異なるアドレスに対応する場合があります。
アプリケーションポリシー有効な署名であっても、誤ったネットワーク、トークン契約、ノンス、金額、または宛先を承認してしまう可能性があります。

ビットコイン

レガシーおよびSegWit v0の鍵による送金にはECDSAが使用される一方、Taprootのキーパス署名にはBIP340のシュノール方式が使用されます。BIP340には、xのみの鍵とタグ付きハッシュ処理という特徴があります。MuSig2 BIP327は、BIP340向けに明示的に設計されています。汎用のしきい値型ECDSAまたはFROSTライブラリには、sighashの構築、スクリプトタイプ、鍵の調整、ノンスのルール、および許容される署名エンコーディングを処理するビットコインアダプタが必要です。

イーサリアム

外部所有のアカウントはsecp256k1 ECDSAを使用し、署名コンポーネントからアドレスを復元します。イーサリアムのトランザクションタイプ、チェーンID、およびEIP-712構造化データは、それぞれ異なる署名ドメインを使用します。EIP-2は、s値が大きなトランザクションの署名を拒否します。したがって、しきい値署名者は、正確なペイロードに対して、正規化されたrおよびsの値に加え、正しい復元情報を生成する必要があります。

Ed25519ベースのシステム

RFC 9591には、Ed25519互換およびEd448互換のスイートが含まれており、それらの最終的な署名は対応する標準検証ツールによって検証可能です。アプリケーションは、正確なチェーンメッセージ、公開鍵形式、およびトランザクションポリシーを提供する必要があります。検証ツールの互換性は、周辺のウォレット統合の妥当性を検証するものではありません。

リフレッシュ、再共有、復旧、およびメンバーシップの変更はどのように機能しますか？

簡単な回答：プロアクティブなリフレッシュでは、グループ公開鍵を変更せずに、すべてのシェアを同じ秘密鍵を持つ新しいシェアに置き換えます。リシェアリングでは、そのためのプロトコルが設計されている場合、しきい値や参加者セットを変更することも可能です。いずれの操作も自動的には行われません。十分な数の承認済み参加者、認証された通信、正しい状態、および明示的なプロトコルサポートが必要です。

プロアクティブなリフレッシュ

リフレッシュでは、シェアをゼロに追加するか、あるいはシェアを再ランダム化して、基盤となるグループの秘密鍵が同じままになるようにします。リフレッシュ後は、古いシェアは使用できなくなるはずです。プロアクティブなセキュリティモデル下では、時間の経過とともに異なる参加者を侵害する攻撃者は、シェアを永久に蓄積し続けるのではなく、1回のリフレッシュ期間内にしきい値に達するシェアを集めなければなりません。リフレッシュは、すでにしきい値に達してしまった侵害を修復するものではなく、また、攻撃者が作成した可能性のあるアプリケーションの認証情報やポリシーシステムのコピーを消去するものでもありません。

シェアの再割り当てと参加者の置換

再共有プロトコルは、新しい参加者セットに新しいシェアを配布し、同じグループ公開鍵を維持したまま t または n を変更することができます。これにより、オンチェーンの資金を移動させることなく、紛失したデバイスの置き換え、従業員のローテーション、または組織の管理体制の変更を行うことが可能です。これは、プロトコルがこれをサポートしており、十分な数の承認済みセットが協力する場合にのみ可能です。製品は、失われたシェアを何もない状態から「再作成」することはできません。

1つのシェアが紛失した場合はどうなるか？

有効なシェアが少なくとも t 個残っていれば、グループは通常、署名を継続できます。再共有を通じて代替シェアを作成できる場合もあります。生存しているシェアが t 個未満で、別途の復旧キー、バックアップ、または契約パスが存在しない場合、署名権限は失われます。しきい値方式は冗長性を向上させますが、あらゆる損失パターンからの復旧を保証するものではありません。

1つのシェアが盗まれた場合はどうなりますか？

理想的な t-of-n 秘密分散モデルでは、t 個未満のシェアでは秘密が明かされず、署名もできません。運用上、シェアが盗まれた場合でも、それは依然として重大なセキュリティインシデントです。攻撃者は、それをプロトコルセッションで使用したり、将来の侵害と組み合わせたり、実装上のバグを悪用したり、メタデータを取得したりする可能性があります。適切な対応は、リスクのあるセッションを停止し、調査を行い、シェアの更新または再分散を行い、関連する認証情報をローテーションし、残りの参加者が独立していることを確認することです。

Six-scenario matrix for a 2-of-3 threshold design. It explains the consequences of one unavailable share, one stolen share, two compromised shares, a malicious coordinator, shares placed in one correlated cloud failure domain, and an implementation flaw. The diagram emphasises that thresholds depend on independence and code correctness.
図3. 2-of-3設計は、1つの孤立したシェアの障害には耐えますが、相互に関連したインフラストラクチャやプロトコルのバグによって、名目上の閾値が破られる可能性があります。

主なセキュリティ上の仮定と障害モードは何か？

簡潔な回答：しきい値署名はリスクを排除するのではなく、単にリスクの所在を移すものである。主な障害の分類としては、しきい値の多数が侵害されるケース、相関したインフラ、悪意のある参加者、サービス拒否（DoS）、ノンスや乱数生成の失敗、プロトコルや証明のバグ、サイドチャネル、チェーン統合の誤り、安全でない復旧、および誤ったメッセージを承認してしまうポリシー層などが挙げられる。

障害モードどのような事態が発生し得るか主要な制御機能
しきい値・多者共有の侵害攻撃者は、グループ鍵を用いて有効な署名を生成することができる。独立したデバイスとオペレーター、更新、最小権限、監視、および迅速なローテーション。
相関した侵害1つのクラウドID、管理者、更新チャネル、またはライブラリが、複数のシェアにアクセスできる。障害ドメイン、ベンダー、認証情報、ネットワーク、および運用責任を分離する。
悪意のある参加者中止、不整合なビュー、不正な形式のプロトコルメッセージ、または選択入力攻撃。認証済みトランスクリプト、共有の検証、識別可能な中止、堅牢性、および排除手順。
ノンス/事前署名の失敗再利用、バイアス、ロールバック、または複製後の完全な鍵の抽出、または無効な署名。CSPRNG、単回使用状態、ロールバック防止ストレージ、セッションバインディング、およびインベントリ管理。
プロトコル実装のバグプロトコル仕様書上は安全であるにもかかわらず、鍵が抽出されてしまうこと。論文通りの正確な実装、独立した監査、テストベクトル、実用的な範囲での形式手法、およびパッチのガバナンス。
サイドチャネルタイミング、キャッシュ、電力、障害、またはエラーの挙動による秘密分散やノンスの漏洩。定数時間プリミティブ、HSM/デバイスの強化、障害検出、および環境固有のテスト。
チェーンアダプタのバグ誤ったペイロード、誤ったチェーン、または拒否されたエンコーディングに対する有効な署名。独立したトランザクション解析、標準エンコーディング、テストネット、リファレンスベクトル、およびポリシーの検証。
復旧の失敗恒久的なロックアウト、安全でないデバイス上での秘密鍵の再構築、または許可されていない緊急時の使用。文書化およびリハーサル済みの復旧手順、クォーラムの分離、封印された手順、および監視。
ポリシー／人的ミスクォーラムが、詐欺、悪意のある承認、または設定ミスのあるトランザクションに署名してしまうこと。信頼できる表示のクリア化、独立したレビュー、制限、許可リスト、遅延、および帯域外検証。

中止に対するセキュリティは、盗難に対するセキュリティとは異なる

多くの不正多数派プロトコルは、悪意のある参加者がセッションを停止した場合でも秘密性を維持する。これは暗号学的観点からは成功だが、運用上の観点からは失敗である。財務システムでは、不正な参加者をどのくらいの速さで排除できるか、代替署名者のサブセットが存在するか、期限切れのセッションがどのようにキャンセルされるか、そして紛争中に業務をどのように継続するかを定義すべきである。

コーディネーターは非秘密であっても強力な権限を持つことができる

コーディネーターは、署名者を選定し、コミットメントを収集し、メッセージを選択し、セッションをスケジュールし、最終的な署名を公開することができる。鍵の共有がなくても、メタデータを監視したり、リクエストを検閲したり、参加者のビューを分割したり、コストのかかる作業を繰り返しトリガーしたりすることが可能である。プロトコルメッセージは認証されるべきであり、参加者はトランザクションを導出するか、独立して検証すべきであり、監視では通常の障害と敵対的な行動を区別すべきである。

しきい値署名はデフォルトではポスト量子耐性ではない

FROST、ECDSA、および現在のシュノール方式は、離散対数仮定に依存している。鍵を分割したからといって、その基盤となる署名アルゴリズムが、十分な能力を持つ量子コンピュータに対して耐性を持つようになるわけではない。ポスト量子しきい値署名は現在、活発な研究および標準化が進められている分野であり、移行計画では、チェーン検証者と分散型鍵管理層の両方を考慮しなければならない。

Alpha-Rays、TSSHOCK、およびその後の鍵抽出に関する研究は何を明らかにしたのか？

簡潔な答え：これらは、しきい値ECDSAの実装上の手抜きにより、悪意のある参加者がECDSAや楕円曲線を破ることなく、完全な署名鍵を抽出できてしまうことを示した。範囲証明の欠如、不正な形式のパイリエパラメータ、脆弱なゼロ知識検証、およびプロトコル固有のコーディングエラーにより、しきい値以下のアクセスが完全な侵害へとつながった。

Alpha-Rays

2021年のAlpha-Raysの研究では、GG18およびGG20方式のしきい値ECDSAの実装に対する鍵抽出攻撃が報告された。これらの攻撃は、乗算から加算へのサブプロトコルや、必要な範囲証明を省略した「高速」モードなどの実装上の選択を標的とした。悪意のある参加者は、この相互作用を悪用して完全な鍵を復元することができた。 この結果はECDSAそのものを破ったわけではないが、証明や検証の手順を省略すると、セキュリティの根拠が成り立たなくなることを実証した。

TSSHOCK

2023年に公表されたTSSHOCKは、しきい値ECDSAの実装に対するさらなる攻撃を報告した。この研究は、同型暗号および証明処理における実装上の欠陥に焦点を当て、秘密鍵を復元するいくつかの経路を明らかにした。ここから得られる重要な教訓は、名指しされた攻撃の範囲を超えたものである。すなわち、しきい値ECDSAプロトコルは、正確な範囲、パラメータの検証、証明の記述、およびエラー処理に対して脆弱であるということだ。

BitGo Zero Proof

Fireblocksによって発見され、公開されたBitGoウォレットの脆弱性は、本番環境での統合において同様のパターンを浮き彫りにした。2者間ECDSAフローにおける証明検証の欠如により、一方の当事者が他方の当事者のシェアを抽出し、鍵を再構築できる可能性があった。影響を受けたサービスは、開示後に停止され、修正パッチが適用された。ここでも、失敗の原因はECDSAプリミティブそのものではなく、プロトコルの実装と検証境界の欠如にあった。

2024年の実用的な鍵抽出に関する研究

その後の学術界および産業界による研究では、主要なMPCウォレットの実装が分析され、署名インタラクションの回数が異なる鍵抽出攻撃が報告された。あるケースでは、調査条件下でわずか1回の署名のみで攻撃が可能であった。これらの結果は、正確なプロトコルバージョンを特定し、すべての証明および検証ステップを含め、実装レビューを暗号セキュリティ保証の一部として扱う必要性を裏付けている。

MPCや閾値署名の実装はどのように評価すべきか？

簡潔な答え：正確なプロトコル、バージョン、および攻撃者モデルから始め、次にコード、乱数、ノンスのライフサイクル、チャネル、サイドチャネル耐性、チェーンアダプタ、シェアの独立性、リフレッシュ、リカバリ、およびポリシーを評価する。「MPCを使用している」、「監査済み」、あるいは「鍵は決して存在しない」といった記述だけでは、それ単体では十分な証拠とはならない。

暗号仕様

  • 正確な論文名、リビジョン、暗号スイート、およびパラメータセットを明記してください。実装が、証明が引用されているバージョンと一致しているかを確認してください。
  • しきい値、参加者数、静的または適応型の改ざんモデル、誠実多数派または不誠実多数派の仮定、中止時の挙動、および堅牢性に関する主張を文書化する。
  • 鍵の生成またはインポート方法、信頼できる販売業者の有無、および完全な鍵や再構築可能なバックアップが作成されるかどうかを確認してください。
  • すべての補助プリミティブ（Paillier パラメータ、オブリビオス転送、クラスグループ、コミットメント、ゼロ知識証明、ハッシュ関数、乱数生成器）を特定してください。

実装とテスト

  • 一般的なスマートコントラクトやアプリケーションの監査だけでなく、そのプロトコルファミリーに精通した専門家による独立したレビューを義務付ける。
  • すべてのネガティブパス（不正な形式のポイント、スカラー、証明、暗号文、参加者識別子、署名者セット、重複したノンス、リプレイされたメッセージ、中止されたセッション）をテストしてください。
  • デバイス環境に適した定数時間かつサイドチャネル耐性のあるプリミティブを使用し、ログ、クラッシュダンプ、スワップ、テレメトリ、および可観測性システムを保護する。
  • 公開されているテストベクトルに対して検証を行い、仕様が存在する場合は、実装間の相互運用性テストを構築する。
  • 運用上の影響を隠すことなく、参加者の資格を剥奪し、署名を停止し、共有情報を更新し、資金を移行できる脆弱性対応プロセスを維持する。

運用アーキテクチャ

  • シェアを真に独立した障害ドメインに配置する：異なる認証情報、管理者、デバイス、ネットワーク、そして実用的な場合は異なるソフトウェアまたはハードウェアのルートが望ましい。
  • 署名前の状態およびノンスの状態を、ロールバック、クローン作成、バックアップからの復元から保護する。消費された状態は、恒久的に消費されたものとして扱う。
  • 参加者のメッセージを認証し、各署名者に、文脈のないハッシュだけでなく、経済的行為を検証するのに十分なトランザクションデータを提供する。
  • 損失、侵害、従業員の離職、クラウドの停止、コーディネーターの障害、および災害復旧についてシミュレーションを行う。一度も実行されたことのない復旧計画は、単なる仮定に過ぎない。
  • 署名試行、参加者の選定、失敗した証明、更新イベント、およびポリシーの上書きを監視する。暗号によるプライバシー保護は、運用上の説明責任を排除してはならない。
危険信号なぜ不十分または危険なのか
プロトコル名が明記されていない「軍事グレードのMPC」評価すべき技術的な主張が存在しない。
すべてのシェアが1つのクラウドテナント下で実行される1つの認証情報または管理者の権限が侵害されただけで、システムが機能不全に陥る可能性がある。
クォーラムがなくても、リカバリによって任意のシェアを再作成できる隠されたマスターシークレットや中央回復機関が存在する可能性がある。
汎用的な secp256k1 ライブラリは、すべてのチェーンをサポートしていると言われているCurveの互換性では、メッセージ、エンコーディング、および検証者の違いが無視される。
監査レポートの対象は、モバイルアプリまたはスマートコントラクトのみです。しきい値プロトコル、ネイティブ暗号、およびバックエンドの状態は、監査の対象外となる可能性がある。
シェアの盗難に対する対応策が文書化されていないシステムに、リフレッシュ、再共有、または緊急移行の機能が欠けている可能性がある。
署名者は不透明なダイジェストのみを受け取る署名者は、自分が承認している経済的アクションの内容を独自に検証することができません。

よくある質問

MPCはしきい値署名と同じものですか？

いいえ。MPC は、複数の当事者が保有する秘密入力に対して計算を行うという、広範な分野です。しきい値署名は、共有グループ鍵の下でデジタル署名を生成する MPC の応用例の一つです。その他の MPC の応用例としては、しきい値復号、秘密集合の交差、共同乱数生成などがあります。

しきい値ウォレットには秘密鍵がありますか？

公開鍵に対応する署名権限は持っていますが、その権限は分散されたシェアとしてのみ存在する可能性があります。DKGベースの設計では、どの参加者も完全な秘密鍵を保持することはありません。ディーラー、インポート、または再構成の設計では、ある段階で完全な鍵が存在する場合があります。

1つのシェアが盗まれただけで資金を盗まれることはありますか？

正しく実装されたt-of-nスキームの下では、t個未満のシェアでは署名を生成したり鍵を明らかにしたりすることはできないはずです。シェアが盗まれることは依然として重大な事象です。攻撃者は、それを後の侵害と組み合わせたり、プロトコルセッションを悪用したり、実装上の欠陥を突いたりする可能性があります。設計上許容される場合は、リフレッシュまたは再シェアを行ってください。

紛失したシェアは置き換えられますか？

十分な数の承認済みシェアが残っており、かつプロトコルまたは復旧アーキテクチャが再シェアをサポートしている場合にのみ可能です。生存している参加者は、公開鍵を維持したまま新しいシェアを作成できる場合があります。閾値未満のシェアしか生存しておらず、別途の復旧経路が存在しない場合、鍵は復旧できません。

FROSTは公式のインターネット標準ですか？

いいえ。RFC 9591は、Crypto Forum Research Groupの合意を反映したIRTFの情報提供文書です。これは厳密な共有仕様ですが、IETFの標準化トラック文書ではありません。NISTは、2026年に正式な公募を開始したプロセスを通じて、しきい値方式の提案を別途評価しています。

RFC 9591には鍵生成が含まれていますか？

主な仕様は2ラウンドのFROST署名を対象としています。鍵生成は明示的にその主な範囲外です。付録にはトラステッド・ディーラーの例が示されており、実装では別のDKGプロトコルを使用することができます。

FROST secp256k1はビットコインのTaprootと互換性がありますか？

このRFCにはsecp256k1暗号スイートが含まれていますが、それだけで自動的にBIP340と互換性があるわけではありません。ビットコインでは、特定の「xのみ」の鍵、タグ付きハッシュ、およびエンコーディング規則が使用されています。ビットコインの導入には、BIP340専用の閾値構成とチェーンアダプターが必要です。

MuSig2はしきい値署名ですか？

MuSig2は、独立したシュノール鍵を集約し、n人の署名者全員を必要とするマルチシグネチャ方式です。BIP327では、これを一般的なt-of-nしきい値署名方式ではなく、n-of-nとして明示的に記述しています。

ブロックチェーンからMPCが使用されたことが判別できますか？

多くの場合、最終的な署名だけでは判別できません。ブロックチェーンは、単一の公開鍵による通常の署名と同様に検証を行うためです。ただし、アドレスの種類、コントラクトコード、トランザクションのパターン、サービスのメタデータ、あるいは事後の開示によって、カストディの設計が明らかになる可能性があります。また、Taprootも一部のマルチシグやスクリプトポリシーを隠蔽できるため、不可視性はMPCに特有のものではありません。

しきい値署名はマルチシグよりも安全か？

どちらが普遍的に安全であるとは言えません。マルチシグは、チェーンによって強制されるシンプルなポリシーと独立した完全な鍵を提供します。一方、しきい値署名は、オンチェーン上のフットプリントを削減し、クォーラムを隠蔽し、再共有を通じてアドレスを維持することができます。しきい値プロトコルは、オフチェーンでの暗号学的および実装上の複雑さを伴います。適切な選択は、チェーン、脅威モデル、復旧のニーズ、および運用スキルによって異なります。

しきい値署名は詐欺から保護しますか？

複数の承認を必要とし、制限を課すことはできますが、正当なクォーラムであっても悪意のあるトランザクションに署名してしまう可能性があります。参加者とポリシーシステムは、シェアを生成する前に、正確な宛先、金額、コントラクト呼び出し、ネットワーク、および権限を理解しておく必要があります。

しきい値暗号はポスト量子対応ですか？

現在のFROST、シュノール、ECDSAのしきい値方式は、ポスト量子対応ではありません。これらは既存の署名権限を分散させるものの、基盤となる署名アルゴリズムのセキュリティ仮定は維持しています。ポスト量子対応のしきい値方式には、異なるプリミティブとチェーン側のサポートが必要です。

結論

しきい値暗号は、現実の運用上の問題を解決する。すなわち、1つの署名秘密鍵が、巨額の残高やシステム、あるいは機関の運命を決定してはならないという問題である。その解決策は、単に鍵を分割することではない。完全なしきい値署名設計では、シェアの生成方法、ワンタイムランダム性の保護方法、参加者が1つのメッセージについて合意する方法、不正な貢献の拒否方法、障害の原因の特定方法、シェアの更新方法、そして最終的な署名がターゲットチェーンと一致させる方法を定義しなければならない。

一般的なマーケティング用語に対する最も重要な修正点は、あらゆる主張が条件付きであるということです。DKGベースのシステムは、そのライフサイクル全体を通じて完全な鍵を回避できますが、インポート鍵システムは同様の実績を主張することはできません。単一のシェアは、暗号学的には不十分でありながら、運用上は緊急を要する可能性があります。ある署名は、オンチェーン上では普通に見えても、オフチェーンの巨大な信頼できる計算基盤に依存している場合があります。プロトコルは安全であると証明されていても、実装上は安全でない場合があります。

独立した障害ドメイン、監査済みのコード、厳格なノンス管理、正しいチェーンアダプター、事前のリカバリー演習、そして承認内容を検証する署名者といった要素と組み合わせて使用すれば、しきい値署名は、通常の署名検証との互換性を損なうことなく、単一障害点を排除できます。しかし、こうした制御措置を伴わずに単なるラベルとして使用された場合、より複雑な単一障害点を隠蔽してしまう可能性があります。

出典および参考文献

本記事の主要参考文献（2026年7月時点）。

簡単なクイズ: 定着しましたか?

基本的な事項を確認するためのいくつかの質問がありました。解説付きの解答が続きますが、あなたの将来のポートフォリオを除いて誰もあなたを採点しません。

問題 1/6
シャミア・バックアップとしきい値署名の違いは何ですか？

これは役に立ちましたか?