ブラインド署名トランザクションとは何ですか?

定義とコアメカニズム

1. ブラインド署名トランザクションとは、ユーザーが完全な内容やコンテキストを知らずにデータにデジタル署名する暗号化プロセスを指します。

2. これは、ウォレットのソフトウェアまたはハードウェア デバイスがアドレスや金額などの部分的な情報のみを提示し、宛先コントラクト ロジック、関数呼び出し、埋め込みパラメーターなどの重要なフィールドを省略した場合に発生します。

3. 署名は数学的には有効ですが、意味論的な理解から切り離されているため、署名者は承認前に意図や結果を検証することができません。

4. ブラインド署名は、入力を生のバイトとして扱う低レベルの暗号化プリミティブに依存し、イーサリアム ABI、EVM オペコード、またはトークン転送標準にエンコードされた構造的意味を無視します。

ウォレット実装のリスク

1. 多くのモバイルおよびブラウザベースのウォレットでは、特にデリゲートの呼び出しやプロキシのアップグレードを含む複雑なスマート コントラクトの対話の場合、切り詰められたトランザクション プレビューが表示されます。

2. ユーザーは、ペイロードがトークン転送、所有権放棄、または自己破壊シーケンスを引き起こす可能性があることに気づかずに、「不明な契約相互作用」または「カスタム データ」というラベルの付いたトランザクションを日常的に承認しています。

3. ハードウェア ウォレットはネストされた呼び出しデータのデコードに失敗することがあり、関数セレクターの最初の 8 ～ 16 バイトのみが表示され、動作を決定する後続の引数は非表示になります。

4. 悪意のある dApp は、欺瞞的な UI レイヤーを埋め込むことでこれを悪用し、画面上に 1 つのアクションを表示しながら、まったく異なる通話データをブロックチェーンに送信します。

イーサリアムおよびEVM固有の脆弱性

1. 無限の許容量を持つ ERC-20 承認は、多くの場合、ウォレット インターフェイスでは無害であるように見えますが、承認されたコントラクトに再入可能の欠陥や悪意のある所有者機能が含まれている場合、サイレント ドレインが可能になります。

2. CALLCODEまたはDELEGATECALLオペコードを含むトランザクション ペイロードは、呼び出し元のストレージ コンテキストで任意のコードを実行する可能性があります。この事実は、標準の確認画面ではほとんど表面化されません。

3. プロキシ契約によりロジックの場所がわかりにくくなります。プロキシ アドレスをターゲットとするトランザクションに署名しても、基礎となる実装がユーザーの期待と一致することは保証されません。

4. Chainlink オラクルの更新、ガバナンス提案、およびマルチシグ実行ペイロードでは、サイズの制約や ABI デコード サポートの欠如により、ブラインド署名が必要になることがよくあります。

実際のエクスプロイト事例

1. 2023 年初頭、ウォレット拡張機能が Uniswap V3 プール移行における動的なコールデータ長の解析に失敗したため、ユーザーは自分のポジションに対するフラッシュ ローン清算を可能にする承認に署名することになりました。

2. 人気のある DeFi アグリゲーターは、permit2 署名とボールトへの入金指示をバンドルしながら、簡素化された「スワップ」ボタンを提示しました。ユーザーは 1 つのアクションを確認しましたが、複数の不可逆的な操作を承認しました。

3. いくつかのフィッシングキャンペーンでは、ユーザーに「認証メッセージ」への署名を促す偽のウォレット回復ツールを配布しましたが、これは実際には攻撃者が管理するアドレスに対する事前署名された引き出し承認でした。

4. クロスチェーンブリッジの UI は、オフチェーンで検証できないペイロードにユーザーが盲目的に署名することに依存し、偽のソースチェーン識別子を使用して中継されたメッセージを送信しました。

よくある質問

Q: ハードウェア ウォレットはブラインド署名を防ぐことができますか? A: 本質的にはそうではありません。ファームウェアに完全な ABI 解析、契約検証、またはデバイス上のバイトコード検査が欠けている場合、エアギャップのあるデバイスであっても、誤って解釈された通話データに対して脆弱なままになります。

Q: ブラインド署名はメッセージ ハッシュに署名することと同じですか? A: いいえ。メッセージのハッシュには、署名前に検証される人間が読める形式の入力が含まれます。ブラインド署名は、ハッシュもコンテンツも意味のある形で表示されない、不透明なバイナリ ペイロードに適用されます。

Q: すべての EVM 互換チェーンは同様にブラインド署名のリスクに悩まされますか? A: リスクの重大度は異なります。標準化されたトランザクション エンコードを使用したチェーン (例: EIP-2718 を使用したイーサリアム) は、一部のアプリケーション固有のロールアップのようなカスタム シリアル化を使用したチェーンよりも一貫したデコードの機会を提供します。

Q: なぜウォレットは署名されていない通話データを単純に拒否しないのでしょうか? A: 互換性を確保するには、レガシー コントラクト、未検証のプロキシ、および非標準インターフェイスを強制的にサポートする必要があります。このようなペイロードを拒否すると、展開された DeFi インフラストラクチャの大部分へのアクセスが遮断されてしまいます。