盲目署名は、よく耳にする「承認フィッシング」（approval phishing）と同じものなのか？
同じものではないが、両者はしばしば重なり合って発生する。承認フィッシングとは、攻撃者が偽サイトや悪意あるリンクを通じて、ユーザーに資産の操作権限を攻撃者へ渡してしまう承認取引に署名させる手口を指し、核心は「署名すべきでない内容に署名させて騙す」ことにある。一方、盲目署名はより根本的な技術的状態を表すもので、「署名するその瞬間、デバイスあるいは本人が本当に自分が何に署名しているのかを理解していたか」を問うものであり、その取引がフィッシングによるものかどうかとは無関係だ。
両者の関連性はこうだ——盲目署名の状態こそ、承認フィッシングが最も成功しやすい温床である。あらゆる取引の実際の内容が明確に読み取れる状態であれば、承認フィッシングが密輸しようとする悪意ある権限は、読めない16進数データの中に隠れる場所を失う。逆に言えば、たとえ能動的なフィッシング行為がなかったとしても、単なる盲目署名の状態そのものがすでにリスクを構成している。なぜならユーザーは、署名するその瞬間に「この取引はなんだかおかしい」と気づく能力を失っているからだ。
EIP-712規格が何年も前から存在するのに、なぜハードウェアウォレットのベンダーは盲目署名モードを全面的に廃止できていないのか？
最も核心的な技術的制約は、明瞭署名を実現するにはデバイスがあらかじめ「ディスクリプタ」を持っていなければ、生データを人間が読める形式のフィールドに正しく解析できないという点にある。このディスクリプタは、コントラクトごと、取引構造ごとに個別に作成する必要があり、ブロックチェーン上では毎日新しいコントラクトがデプロイされ、新しいやり取りのパターンが登場するため、ディスクリプタのデータベースは常にオンチェーン上に実際に存在するコントラクトの総数に追いつけない。データベースに登録されていないコントラクトに直面すれば、デバイスには盲目署名に戻る以外の選択肢がない。
もう一つの現実的な要因は、商業的・スケジュール的な圧力だ。明瞭署名を完全にサポートするには、ウォレットベンダー、アプリケーション開発者、規格策定者の三者が協調して取り組む必要があり、どれか一者でも進捗が遅れれば、ユーザーが実際に体験するのは依然として盲目署名のインターフェースのままになる。これこそが、近年業界がERC-7730のような「構造化データ明瞭署名フォーマット」規格の推進を始めた理由だ。ディスクリプタの生成と検証プロセスを標準化・非中央集権化することで、より多くのコントラクトをより早く明瞭署名の対象範囲に含めようとしているが、これは依然として進行中であり、完全には解決していない業界全体の課題である。
盲目署名を求める取引に直面したとき、一般ユーザーはその場でリスクを減らすために具体的に何ができるのか？
最初のステップは、その取引の緊急性が意図的に演出されたものではないかを見極めることだ。盲目署名のリスクの多くは、ユーザーが操作を急いでいる状況（限定販売の駆け込み購入、間に合わないエアドロップの締め切りなど）で発生する。速度を落とすこと自体が最も基本的な防御線となる。第二に、取引シミュレーションツール（MetaMaskやRabbyなど主流のソフトウェアウォレットの多くにすでに内蔵されている）を活用し、正式に署名する前に「この取引に署名したら、実際に自分のウォレットの資産にどんな変化が起きるか」というシミュレーション結果を確認する。このシミュレーションは署名インターフェースとは異なる独立した計算経路を使うため、ある程度「画面に表示される内容」と「実際に実行される内容」との乖離を検知できる。
第三に、特に金額が大きい、あるいは不慣れなコントラクトが絡む操作については、取引の生の呼び出しデータをブロックチェーンエクスプローラー（Etherscanなど）のデコードツールにコピーして、ウォレットのインターフェースとは完全に独立した別の情報源で改めて確認する価値がある。ウォレットの表示、シミュレーションツール、ブロックチェーンエクスプローラーのデコード結果という3つの経路すべてが一致して初めて、その取引が期待通りのものであると信じる本当の根拠が得られる。単一の画面表示だけを頼りに署名の判断を下すことは、常に最もリスクの高いやり方だ。
ハードウェアウォレットをたまに少額の取引にしか使わないのだが、これらを学ぶ価値はあるのか？
価値はある。しかもその理由は金額の大小とはあまり関係がない。盲目署名のリスクが最も危険なのは、単一の取引の金額の大小ではなく、「承認」という行為そのものの性質にある。多くのDeFi操作が求めているのは一回限りの固定額の送金ではなく、コントラクトが将来にわたって無制限に、上限なくあなたのウォレット内の特定トークンを動かせるようにする承認だ。この種の承認に一度署名してしまうと、たとえその時は新しいプロトコルを少額でテストするだけのつもりだったとしても、盲目署名の画面に隠された無制限承認の条項に気づかなければ、そのトークンに対するウォレット全体の制御権を渡してしまうことになりかねない。
より現実的な理由としては、盲目署名のリスクを見抜く力は一度身につければ一生使える判断力であり、操作のたびに新しく学び直す必要がないという点だ。必要なのは、決まったチェック習慣を一つ確立することだけだ——16進数の生データを見たらまず立ち止まり、取引シミュレーションツールで一度実行してみる。特に「承認」（approve）タイプの操作については、承認額が無制限になっていないかを追加で確認する。この習慣さえ身につけてしまえば、その後の操作が10ドルであろうと10万ドルであろうと、同じプロセスでリスクを下げることができる——ある日突然大きな資産を動かすことになってから慌てて学ぶ必要はない。
ハードウェアウォレットを購入し、これで資産が守られたと感じたとしよう。あるDeFiプラットフォームで「承認」をクリックすると、ハードウェアウォレットの画面に長い16進数の文字列が表示される。0x6a76120200000000000000000000000087870bca3f3fd6335c3f4ce8...。意味がわからないまま、あなたは確認ボタンを押す——インターフェースがこれは通常の操作だと表示しており、ウォレット自体も暗号学的には何の欠陥もなく本当に安全だからだ。これはまさにBybit事件で3人の署名者が直面した状況そのものであり、ほぼすべてのハードウェアウォレットユーザーが毎日繰り返している動作でもある——自分には読めない文字列に確認を押すこと。この動作には名前がある。「盲目署名」（ブラインドサイニング）だ。
盲目署名とは、ハードウェアウォレットが十分な文脈情報のないまま、生の16進数データやハッシュ値に署名することを指す。デバイス自体には、そのデータを「誰に、いくら、何を承認しようとしているのか」という人間が理解できる情報に復号する手段がない。イーサリアム初期のeth_signメソッドはまさにこのパターンの原型だった——ユーザーが最初から最後まで目にするのは、その意味を検証できないハッシュ値だけであり、ハードウェアデバイスはそのハッシュ値に忠実に署名するだけで、その背後にどんな取引内容があるのかはまったく把握していなかった。ユーザーには、画面の向こう側のソフトウェアインターフェースが伝える内容を信じる以外の選択肢がなかった。まさにここに問題がある——「この取引が実際に何をしているのか」を判読する本来の作業が、ハードウェアデバイスの外にあるソフトウェア層に丸ごと外部委託されてしまっており、そしてその層こそが、攻撃者が最も好んで狙う標的なのだ。
この問題に対処するため、イーサリアムコミュニティは2017年にEIP-712を提案した。これは「構造化データ署名」の規格を定義し、開発者が取引データにフィールド名と型を固定フォーマットで付与できるようにすることで、ウォレットデバイスがそのデータを「金額：100 USDC」「送金先：0x1234...」といった人間が読める形式に解析できる可能性を開いた。ハードウェアウォレットのベンダーはこれを基に3つの署名レベルを構築した——盲目署名（生データがまったく読めない）、透過署名（完全な技術フィールドは表示されるが、ほとんどのユーザーには理解しづらい詳細で埋め尽くされている）、そして明瞭署名（クリアサイニング、デバイスが取引の実際の意図を解析して明確に表示する）だ。問題は、明瞭署名を実現するには、デバイスが特定のコントラクトや取引種別についての「ディスクリプタ」をあらかじめ持っていなければ正しく解析できないという点にある。新しくデプロイされたコントラクト、複雑なネスト構造の操作（Safeマルチシグウォレットでよく使われるMultiSendのバッチ取引など）、あるいはまだどのディスクリプタデータベースにも登録されていないプロトコルに直面すると、デバイスは盲目署名モードに戻らざるを得ないことが多い。これこそが、EIP-712が登場してから何年も経った今でも、実際の利用シーンの多くで「盲目署名」が本当の意味で姿を消していない理由だ。
さらに警戒すべきなのは、たとえデバイスが明瞭署名に対応しており、画面に明確でわかりやすいフィールドが表示されていたとしても、それが目にしている内容が真実であることを保証するわけではないという点だ。ハードウェアデバイスもソフトウェアを実行する機械である以上、画面に表示される「解析結果」は何らかのコードによって計算されている。もしその表示内容を生成する責任を負うソフトウェア自体が侵害されていれば、デバイスが忠実に表示するのは改ざんされた偽りの姿にすぎない。これこそがBybit事件の最も根本的な教訓だ——問題は署名者が生データを読めずに盲目署名してしまったことではなく、彼らが目にした「明確でわかりやすい画面」そのものが、攻撃者によって周到に偽造されていたことにある。解読された画面は、自分が読めない内容に署名してしまうリスクを狭めることはできても、その画面自体が嘘をついていないことを証明するものではない。
注目すべきは、このリスクが業界内でまったく認識されていなかったわけではないという点だ——一部のウォレットベンダーでは関連するセキュリティ問題が報告されてから、実際の修正完了まで1年以上を要したケースもあり、主流のソフトウェアウォレットの中にも、既知のリスクを持つ署名方式の削除を発表してから実際に削除を完了するまで数ヶ月の間隔があったケースもある。対照的に、Bybit事件の発生後、Safeチームはこの事件で露呈したリスクへの対応策を極めて短期間で打ち出した。この対比は一つのことを明確に物語っている——この種のリスクの多くは、実は業界内部ではとっくに知られていたということであり、修正の速度を実際に押し上げるのは、リスクが発見された瞬間ではなく、大きな損失が実際に発生した後の圧力であることが多いのだ。
ハードウェアウォレットを使っているなら、次に取引に署名する前に、画面に完全に読み取れるフィールド（金額、送金先、操作の種類）が表示されているか、それとも理解できない16進数の文字列が表示されているかを確認してほしい。後者は明確な盲目署名の警告サインであり、特に取引金額が大きい場合や不慣れなコントラクトとのやり取りの際には、操作を一時停止し、公式チャンネルやブロックチェーンエクスプローラーを通じて別途確認する価値がある。しかしそれ以上に重要なのは、Bybit事件の教訓を忘れないことだ——たとえ画面が明確で読みやすい内容を表示していたとしても、それだけでは万全とは言えない。結局のところ、その「明確でわかりやすさ」自体も、改ざんされうる何らかのソフトウェアによって計算されたものだからだ。リスクを実際に減らす方法は、特に金額の大きな操作については主要な署名インターフェースとは完全に独立した別のツールを使って取引内容を改めて確認することであり、画面に表示された表面的な文字だけを見て確認ボタンを押すことではない。