約400万ドルの損失：TaikoとSecondFiのエクスプロイト｜BlockSec週次レポート

過去1週間（2026/06/22 - 2026/06/28）に、2件の注目すべきセキュリティインシデントが確認され、合計約410万ドルの損失が発生しました。

• Taiko: 攻撃者は、漏洩したSGXエンクレーブ署名鍵と不完全なアテステーションポリシーを組み合わせ、悪意のあるプルーバーを認可済みインスタンスとして登録しました。これは、包括的な属性の強制なしには、有効なアテステーションだけでは不十分であることを示しています。
• SecondFi: 暗号実装の欠陥により、攻撃者は公開されているトランザクションデータのみを使用してアドレスレベルの署名鍵を復元できました。Ed25519仕様からのわずかな逸脱が、鍵の完全な漏洩につながりうることを示しています。

週間ハイライト：Taikoインシデント

Taikoインシデントがハイライトされている理由は、この攻撃が2つの独立したセキュリティ上の失敗（漏洩したエンクレーブ署名鍵と不完全なアテステーションポリシー）を組み合わせて、SGXベースの証明検証システムを侵害したためです。このインシデントは、TEEトラストチェーンの各層が独立してセキュリティ特性を強制しなければならないことを示しています。有効なアテステーション署名チェーンは、未検査のランタイム属性を補うものではありません。

2026年6月22日、TaikoのSGXベースの証明検証フローがEthereum上で悪用され、約170万ドルの損失が発生しました [1]。攻撃者は、公開GitHubリポジトリにコミットされていたエンクレーブ署名秘密鍵を使用して、DEBUGモードで起動されたプルーバーエンクレーブのSIGSTRUCTに署名しました。オンチェーンのアテステーションコントラクトがDEBUGエンクレーブを拒否しなかったため、攻撃者は認可済みインスタンスとして登録し、偽造した証明データを送信し、L1コントラクトに存在しないL2状態を受け入れさせてブリッジ資金を引き出しました。

背景

Taikoは、あるL2状態またはクロスチェーンメッセージを受け入れるべきか判断するために証明システムに依存したブリッジを持つEthereumレイヤー2ロールアップです。この証明システムの一環として、TaikoはSGXプルーバーを使用しています。SGXプルーバーは、物理マシン上のSGXエンクレーブ内で動作するオフチェーンプログラムで、エンクレーブによって保護された鍵を使用して証明結果に署名します。

オフチェーン（物理マシン）                オンチェーン（Ethereum）
┌─────────────────────────┐                ┌────────────────────────────────────┐
│  SGX プルーバーエンクレーブ │                │  SgxVerifier                       │
│  - 証明を生成する         │── DCAPクォート ─→│  ├─ registerInstance()             │
│  - インスタンス鍵を保持する │                │  │  └─ AutomataDcapV3Attestation   │
│                         │── 署名済み証明→│  └─ verifyProof()                  │
└─────────────────────────┘                └────────────────────────────────────┘

SGX & DCAPの概要

SGXの中核的概念はエンクレーブです。エンクレーブとはCPUによって隔離されたプログラム環境です。MRENCLAVEはエンクレーブの初期コード、データ、ページレイアウト、および関連メタデータの測定値であり、エンクレーブビルドのハッシュと近似できます。MRSIGNERはエンクレーブ署名公開鍵のハッシュであり、発行者のアイデンティティを表します。

エンクレーブ署名秘密鍵はSGXのSIGSTRUCTに署名します。SIGSTRUCTにはMRENCLAVE、ISVPRODID、ISVSVN、ATTRIBUTESなどのエンクレーブメタデータが含まれています。この署名はオンチェーンコントラクトでは検証されず、エンクレーブ初期化時のEINITフェーズでSGXハードウェアによって検証されます。CPUはSIGSTRUCT署名が有効であること、およびその中のMRENCLAVEが実際にロードされたエンクレーブの測定値と一致することを確認します。この検証が成功して初めて、エンクレーブが初期化され、後続のレポートとクォートを生成できます。

Intel SGX DCAP v3クォートは、3つの部分を含むリモートアテステーションパッケージです：

• header: クォートバージョン、アテステーション鍵タイプ、QE/PCE SVN、ベンダーなどのメタデータ。
• localEnclaveReport: MRENCLAVE、MRSIGNER、ATTRIBUTES、ISVPRODID、ISVSVN、reportDataを含む、アテストされたアプリケーションエンクレーブのアイデンティティ。reportDataはレポート生成時にエンクレーブが書き込む64バイトの値です。TaikoはreportDataの最初の20バイトにプルーバーインスタンスアドレスを格納します。
• v3AuthData: クォート署名、アテステーション鍵、QEレポート、QEレポート署名、PCK証明書チェーンを含む、クォートの真正性証明。

オンチェーンアテステーション

オンチェーンアテステーションコントラクト（AutomataDcapV3Attestation、リモートアテステーションを担当）は、Intel DCAP証明書チェーンを通じてクォートの真正性を検証します。証明書チェーンの発行者公開鍵は外部から提出されたクォートの一部として提供されますが、コントラクトはチェーンをステップごとに検証し、最終的な発行者公開鍵ハッシュがコントラクトに固定されているIntel SGX Root CA公開鍵ハッシュと一致することを要求します [2]。このチェーンを通じて、コントラクトはクォート署名でカバーされたlocalEnclaveReportがcalldataで任意に変更されていないことを確認します。

Taikoプルーバー登録

SGXプルーバーインスタンスはまずSgxVerifier.registerInstance()を通じて登録する必要があります。登録時に、呼び出し元はDCAPクォートを送信します。SgxVerifierはクォートの検証をAutomataDcapV3Attestation.verifyParsedQuote()に委任します。クォートが通過すると、SgxVerifierはlocalEnclaveReport.reportDataの最初の20バイトをインスタンスアドレスとして読み取り、認可済みインスタンスセットに追加します。

署名検証フローは3つの層に簡略化できます：

• SGX CPUはEINIT中にSIGSTRUCT署名を検証し、エンクレーブのMRENCLAVEと署名者のアイデンティティを確認します。
• DCAPの証明書チェーンとQEレポートがクォート署名鍵を認証します。AutomataDcapV3Attestationはその鍵を使用してクォート署名を検証し、localEnclaveReportへの信頼を確立します。
• Taikoの証明検証者は、登録済みインスタンスアドレスを使用して後続の証明署名を検証し、対応するL2状態またはクロスチェーンメッセージを受け入れるかどうかを判断します。

脆弱性の分析

このインシデントの根本原因は、運用上の失敗とコントラクトレベルの脆弱性の組み合わせです。攻撃が成功するためには両方が必要でした。

運用上の失敗：エンクレーブ署名鍵の漏洩。 TaikoおよびRaikoがSGXのSIGSTRUCTへの署名に使用していたエンクレーブ署名秘密鍵が、公開GitHubリポジトリにコミットされていました。MRSIGNERは対応する署名公開鍵のハッシュです。この秘密鍵を入手した者は誰でもプルーバーエンクレーブのSIGSTRUCTに署名でき、生成されたクォートのMRSIGNERがTaikoの許可リストと一致するようになります。

コントラクトの脆弱性：ATTRIBUTESチェックの欠如。 一致するMRSIGNER（漏洩した鍵を通じて許可リストを通過）があれば、攻撃者はMRENCLAVEを変更せずに同じ承認済みエンクレーブをDEBUGモードで起動できます（DEBUGフラグはMRENCLAVEの一部ではありません）。アテステーションポリシーはこれを検出すべきでしたが、AutomataDcapV3Attestation（0x5e46...dd72）はアプリケーションエンクレーブのlocalEnclaveReport.attributesをチェックしていませんでした。DEBUGエンクレーブはホストまたはデバッガーがエンクレーブメモリを読み書きできるため、SGXエンクレーブによって保護されるべきだったインスタンス署名鍵はもはや安全ではありません。

これらの2つの条件が組み合わさることで、いかなる当事者も同じプルーバーエンクレーブコードをDEBUGモードで起動し（正規のビルドと同じMRENCLAVEを生成する）、漏洩した署名鍵を使用してMRSIGNERをTaikoの許可リストと一致させるSIGSTRUCTに署名できます。生成されたクォートはMRENCLAVEとMRSIGNERの両方の許可リストを満たしつつ、未チェックのDEBUG属性を持ちます。AutomataDcapV3AttestationがDEBUG属性を拒否しないため、そのようなクォートはverifyParsedQuote()を通過し、その後SgxVerifierがインスタンスアドレスを認可済みインスタンスセットに登録します。

DEBUGモードのエンクレーブはホストまたはデバッガーからメモリを保護しません。そのため、エンクレーブ内部で生成されたインスタンス秘密鍵は抽出可能です。その鍵があれば、保有者はL1コントラクトが受け入れる任意の証明データに署名でき、偽造されたL2状態遷移とボールト（0x9962...15ab）からのブリッジ資金の不正引き出しが可能になります。

攻撃の分析

攻撃者は複数のトランザクションを送信しました。以下の分析は2つの代表的なトランザクションに基づいています。1つ目は攻撃者を認可済みインスタンスとして登録したもの（0x2f44dc...277260）、2つ目は偽造した証明を実行して資産を盗んだもの（0x017292...ae35ee）です。

• ステップ1: 漏洩したエンクレーブ署名鍵を使用してSIGSTRUCTに署名し、クォートのMRSIGNERを許可リストと一致させる。

• ステップ2: DEBUG属性でエンクレーブを実行する。DEBUGはMRENCLAVEを変更しないが、localEnclaveReport.attributesに反映される。

• ステップ3: registerInstance()を呼び出し、実際のSGXクォートを送信する。クォートにはattributes = 0x07...があり、DEBUGビット（0x02）が含まれていたが、AutomataDcapV3Attestationはこのフィールドをチェックしなかったため、verifyParsedQuote()はtrueを返した。

• ステップ4: SGXエンクレーブのメモリからインスタンス秘密鍵を抽出する（DEBUGモードはメモリ保護を無効にするため可能）し、悪意のある証明データの署名に使用する。

• ステップ5: 作成した証明を送信し、L1コントラクトに存在しないL2状態を受け入れさせ、ボールトから資産を盗む。

まとめ

完全なSGXアテステーションポリシーは少なくとも以下を行うべきです：

• 本番環境のデプロイメントではSGX_FLAGS_DEBUGを拒否する。
• MRENCLAVE、MRSIGNER、ISVPRODID、ISVSVNを確認する。

DEBUGクォートが受け入れられる場合、ハードウェアは正常に機能している可能性がありますが、期待されるメモリ保護のセマンティクスはもはや提供されません。エンクレーブ署名鍵は公開リポジトリにコミットしてはなりません。漏洩した署名鍵により、いかなる当事者も一致するMRSIGNERを持つバイナリを生成できるため、アテステーションポリシーの残存する障壁はMRENCLAVEと属性の強制のみとなります。

より広い観点から、TEEに依存するあらゆるシステムにおいて、アテステーションは署名チェーンが有効で測定値が許可リストにあることを確認するだけでは不十分です。トラストチェーンの各層が独立してセキュリティ特性を強制しなければなりません。

参考文献

• [1] Phalconアラート：Taikoブリッジエクスプロイト検知
• [2] Intel SGX開発者ガイド

今週のその他のインシデント

SecondFiインシデント

2026年6月23日、CardanoウォレットであるSecondFi（旧Yoroi、EMURGOが開発）は、そのEd25519署名実装における重大な脆弱性を公開しました [1]。ウォレットの署名実装は、署名ナンスを公開されたトランザクションメッセージのみから計算しており、必要な秘密入力を省略していました。これによりデジタル署名は一方程式の問題に帰着し、攻撃者は公開されたオンチェーンデータからアドレスレベルの秘密鍵を復元できるようになりました。2人の別々の攻撃者がこの欠陥を悪用し、374のウォレットから約240万ドル（1,600万ADA）を引き出しました [2]。

背景

SecondFiは、2026年4月にYoroiからリブランドされたCardanoブロックチェーン向けセルフカストディウォレットです。Cardanoの3つの創設組織の一つであるEMURGOが開発し、Yoroiはかつて100万人以上のユーザーに利用されていました。

Ed25519はCardanoがトランザクション承認に使用するデジタル署名方式です。署名者は署名スカラー$k_{L}k\_L$（特定アドレスの秘密鍵）と、同じ鍵素材に関連付けられた秘密ナンスプレフィックス$k_{R}k\_R$を保持します。与えられたメッセージ$MM$（トランザクションペイロード）に対して、署名ナンスは$r=\mathrm{SHA-512}(k_R\mathrm{\parallel }M)Lr\; =\; \backslash operatorname\{SHA-512\}(k\_R\; \backslash mathbin\backslash Vert\; M)\; \backslash bmod\; L$として計算されます。$k_{R}k\_R$は秘密であるため、$MM$がブロードキャスト後に公開されても、$rr$はオブザーバーには不明なままです。

ナンスポイント$R=r\cdot BR\; =\; r\; \backslash cdot\; B$（$BB$は固定のEd25519基点）と署名スカラー$s\equiv r+H\cdot k_L(\mathrm{m}\mathrm{o}\mathrm{d}L)s\; \backslash equiv\; r\; +\; H\; \backslash cdot\; k\_L\; \backslash pmod\{L\}$（$H=\mathrm{SHA-512}(R\mathrm{\parallel }A\mathrm{\parallel }M)LH\; =\; \backslash operatorname\{SHA-512\}(R\; \backslash mathbin\backslash Vert\; A\; \backslash mathbin\backslash Vert\; M)\; \backslash bmod\; L$はナンス、公開鍵、メッセージを結びつける）が最終的な署名$(R,s)(R,\; s)$を形成します。この方式のセキュリティは$rr$が予測不可能であることに依存しています。オブザーバーが$rr$を計算できれば、署名方程式は$k_{L}k\_L$について解くことができる一変数線形方程式になります。

脆弱性の分析

この脆弱性はスマートコントラクトではなく、SecondFiのウォレット署名ソフトウェアにあります。

既存の分析 [2] と独自調査を組み合わせた結果、v10.0.3からv10.0.6（2026年6月8日から稼働、v10.0.6.2で修正済み）が影響を受けることがわかりました。脆弱な実装では署名ナンスを次のように計算していました：

$$r=\mathrm{SHA-512}(M)Lr\; =\; \backslash operatorname\{SHA-512\}(M)\; \backslash bmod\; L$$

正しい計算式は：

$$r=\mathrm{SHA-512}(k_R\mathrm{\parallel }M)Lr\; =\; \backslash operatorname\{SHA-512\}(k\_R\; \backslash mathbin\backslash Vert\; M)\; \backslash bmod\; L$$

これによりナンス導出から唯一の秘密入力（$k_{R}k\_R$）が除去されました。$MM$は公開されているため、誰でも影響を受けるアドレスによって署名されたトランザクションの$rr$を再計算できます。

$rr$が判明すれば、署名方程式$s\equiv r+H\cdot k_L(\mathrm{m}\mathrm{o}\mathrm{d}L)s\; \backslash equiv\; r\; +\; H\; \backslash cdot\; k\_L\; \backslash pmod\{L\}$は解くことができます：

$$k_L\equiv (s-r)\cdot H^{-1}(\mathrm{m}\mathrm{o}\mathrm{d}L)k\_L\; \backslash equiv\; (s\; -\; r)\; \backslash cdot\; H^\{-1\}\; \backslash pmod\{L\}$$

右辺のすべての値は公開されているか、オンチェーンの署名とトランザクションデータから計算できます。これはハッシュの逆算や$A=k_L\cdot BA\; =\; k\_L\; \backslash cdot\; B$からの離散対数問題の解決ではありません。欠陥のある実装が$rr$を直接露出させたことで、鍵の復元は単純なモジュラー演算に帰着します。

影響はアドレスレベルの鍵の漏洩です。脆弱な実装を通じて署名を生成したアドレスはすべて漏洩したものとして扱うべきです。

同じニーモニックをパッチ済みウォレットにインポートしても、すでに露出しているアドレスは保護されません。脆弱な署名実装を通じて一度も署名していない、新たに生成した鍵に資金を移動する必要があります。

攻撃の分析

この攻撃は、追跡可能なスマートコントラクトのインタラクションを伴う典型的なオンチェーンエクスプロイトのシーケンスには従いません。この脆弱性は公開データと署名鍵の間に決定論的な関係を露出させるため、鍵の復元はオフラインで行われます。

• ステップ1: SecondFi v10.0.3からv10.0.6を使用してトランザクションに署名したターゲットアドレスを特定する。

• ステップ2: 各ターゲットについて、トランザクションの公開署名コンポーネント（$RR$、$ss$）を取得し、オンチェーントランザクションペイロードからメッセージ$MM$を再構成する。

• ステップ3: 脆弱な署名実装が秘密ナンスプレフィックス$k_{R}k\_R$を省略していた事実を利用して、署名ナンス$r=\mathrm{SHA-512}(M)Lr\; =\; \backslash operatorname\{SHA-512\}(M)\; \backslash bmod\; L$を計算する。

• ステップ4: チャレンジスカラー$H=\mathrm{SHA-512}(R\mathrm{\parallel }A\mathrm{\parallel }M)LH\; =\; \backslash operatorname\{SHA-512\}(R\; \backslash mathbin\backslash Vert\; A\; \backslash mathbin\backslash Vert\; M)\; \backslash bmod\; L$を計算する。

• ステップ5: 署名スカラーを解く：$k_L\equiv (s-r)\cdot H^{-1}(\mathrm{m}\mathrm{o}\mathrm{d}L)k\_L\; \backslash equiv\; (s\; -\; r)\; \backslash cdot\; H^\{-1\}\; \backslash pmod\{L\}$。

• ステップ6: 復元した$k_{L}k\_L$を使用して漏洩したアドレスから任意のトランザクションに署名し、攻撃者が管理するウォレットに資金を送金する。

2人の別々の攻撃者がこの脆弱性を独立して悪用しました。1人は2波に分けて171のウォレットを侵害し、もう1人は別の一斉攻撃で203のウォレットを引き出し、合計約1,600万ADA（約240万ドル）を抽出しました [2]。EMURGOはその後、攻撃者が到達する前にさらに1億2,900万ADAを救出しました。

まとめ

根本原因は、Ed25519のナンス導出から秘密ナンスプレフィックスを除去した暗号実装の欠陥であり、署名ナンスが公開データの決定論的関数に帰着しました。影響を受けたすべての署名が一方程式の鍵復元問題となりました。

このインシデントは、ウォレット開発者がカスタム署名実装ではなく、十分に監査された標準的なEd25519ライブラリを使用すべきであることを強調しています。仕様からのいかなる逸脱も、単一のハッシュ入力を省略するような一見軽微に見えるものであっても、鍵全体を危殆化させる可能性があります。本番の署名ソフトウェアは、特に鍵導出と署名操作を扱う場合、デプロイ前に独立した暗号監査を受けるべきです。

参考文献

• [1] SecondFiインシデント後の開示
• [2] Tibane Labs: SecondFi Cardanoフォレンジック分析

BlockSecについて

BlockSecはフルスタックのブロックチェーンセキュリティおよび暗号資産コンプライアンスプロバイダーです。私たちは、プロトコルやプラットフォームのライフサイクル全体にわたって、コード監査（スマートコントラクト、ブロックチェーン、ウォレットを含む）、リアルタイムの攻撃遮断、インシデント分析、不正資金の追跡、AML/CFT義務の遵守を支援する製品とサービスを構築しています。

BlockSecは権威ある学会で複数のブロックチェーンセキュリティ論文を発表し、DeFiアプリケーションのゼロデイ攻撃を複数報告し、2,000万ドル以上を救出するための複数のハッキングをブロックし、数十億ドルの暗号資産を保護してきました。

• 公式ウェブサイト：https://blocksec.com/

• 公式Twitterアカウント：https://twitter.com/BlockSecTeam

• 🔗 BlockSec監査サービス : リクエストを送信

• 🔗 Phalcon Security APP: デモを予約

• 🔗 Phalcon Compliance