Chainflipが報告した内容
Chainflipは9月3日の公表で、3つのバリデーターが直近の鍵引き継ぎセレモニー中に、意図的に不正なメッセージを送信していたと説明しました。チームは本番環境に存在する脆弱性の悪用を試みたものとみていますが、鍵や資金が失われる前に対処したとしています。バリデーターのローテーションは停止され、スワップなど他のサービスは継続しました。
Chainflipによると、不正なセレモニーIDを含むメッセージが受信エンジンの処理キューを圧迫し、正規メッセージの受信を妨げる可能性がありました。その結果、マルチシグプロトコルが検証段階へ進み、正常な参加者が鍵シェアの断片を開示する状況を誘発し得ます。攻撃者がその断片を過去ラウンドの情報と組み合わせ、集約鍵を再構築することが想定されました。150バリデーター中3つを支配する場合、Chainflipの計算では97の参加者による断片開示が必要でした。狙いはBitcoinの引き継ぎ処理とみられ、成功すればBitcoin保管庫が流出した可能性が高いとしています。
資源枯渇が暗号攻撃へ変わるとき
重要な教訓は、可用性と鍵の機密性が別々の領域ではないことです。上限のないデコード処理やキューは、分散暗号プロトコルがどの分岐を実行するかを変え得ます。フォールバック処理で復旧・検証用の情報を開示する設計なら、サービス妨害の手段が鍵抽出の手段へ変わります。
本番実装では、高コストな処理の前にメッセージサイズ、デコード処理量、キュー占有量、ピアごとのレート、セレモニーIDを制限すべきです。遅延、重複、ラウンドをまたぐメッセージ、意図的な不正形式を含む敵対的テストも必要です。通常のセレモニー失敗と、特定ピアに相関する不正トラフィックをメトリクスで区別できれば、機密状態が蓄積する前に疑わしい遷移を止められます。
シェア上限はラウンド、役割、IDをまたいで管理する
Chainflipは、単一セレモニー内で鍵を再構築できる量の情報開示を既に防いでいた一方、悪意ある参加者が複数ラウンドの断片を組み合わせるシナリオを特定したと説明しました。修正では共有上限を半分にし、不正メッセージ処理の性能上の漏れも除去しました。ただし、悪意ある主体がセレモニーを中断・再試行させやすくなるという代償も明記しています。
このトレードオフはセキュリティモデルで明示すべきです。シェア開示の予算は再試行や引き継ぎをまたいで追跡し、認証済み参加者とプロトコルのトランスクリプトに結び付け、セレモニー中断時に無効化する必要があります。共謀を前提に安全な最大開示量を定義し、可用性は別に検証すべきです。ローテーション継続のために開示量を暗黙に増やすことは、安全な可用性対策ではありません。
封じ込めにはプロトコル統制とガバナンスの両方が必要
Chainflipは、ローテーション再開前にバージョン2.2.11へ更新するよう運用者に求めました。また、運用者の支持を条件に、3つのバリデーターが保有するFLIPをオンチェーンのリザーブへ移し、今後の鍵生成から排除する案を提示しました。同社によると対象アカウントはローテーション中だけ資金を動かせるため、停止自体が封じ込めになります。凍結はコンセンサスにより取り消し可能です。
運用者は緊急時ガバナンスを平時に設計しておく必要があります。誰がセレモニーを停止できるか、どの証拠で参加者を排除するか、更新をどう証明するか、どのクォーラムでローテーションを再開するか、異議のある凍結をどう解除するかを定義します。可観測性、リリース配布、ガバナンスの所要時間も鍵管理の脅威モデルの一部です。
Ineezaの見解
しきい値カストディの強度は、暗号だけでなく周囲の状態機械で決まります。キュー上限、トランスクリプト単位のシェア管理、迅速なローテーション停止、再現可能な更新、監査可能なバリデーター制裁を一体で設計すべきです。資金流出が起きなかったからこそ今回の公表には価値があります。保管庫侵害につながり得る経路を、本番インシデントの封じ込めで止める統制を具体的に示したためです。