WATS Wallet logoWATS Wallet
技術8 分で読めます

ブラインド署名とは?読めないものに絶対署名してはいけない理由

ブラインド署名とは、ウォレットが読める形で表示できないトランザクションやメッセージを承認してしまうことです。生のcalldata、不透明な16進数の塊、剥き出しのハッシュなどが該当します。eth_signを決して承認してはいけない理由、ドレイナーが読めないリクエストに依存する仕組み、そしてクリアサイニングとシミュレーションで署名前に読む方法を解説します。

ブラインド署名とは、その署名が何を認可するのかを平易な言葉で示す代わりに、生のcalldata、不透明な16進数の塊、あるいは32バイトの剥き出しのハッシュしか出てこない状態で、ウォレットが人間に読める形で表示できないトランザクションやメッセージを承認してしまうことです。これは暗号技術の失敗ではありません。署名そのものは完全に有効で、オンチェーンでは完全な権限を持ちます。だからこそ、読めないデータに署名することは、一度も確認していない権限を与えることになり、ほぼすべてのウォレットドレイナーがこの一点を土台に作られています。処方箋はクリアサイニング(clear signing)です。ウォレットがリクエストを、確認できる一文へと解読し、実際にどの資産が動くのかをシミュレーションで先に見せること。そこに、どんなソフトウェアも代わりに用意できない習慣を一つ加えます。読めないものは拒否する、という習慣です。署名は権限が移る、まさにその瞬間なので、その署名を生み出す鍵があなただけのものであることも重要になります。WATS Hot WalletはEthereum、Arbitrum、Optimism、Base、Polygon、BNB Chain、Solana、TONにわたってノンカストディアルであり、あなた自身が承認した署名なしに資産が動くことはありません。

ブラインド署名とは何か

ブラインド署名とは、リクエストとその表示が乖離したまま行われる承認すべてを指します。チェーンは署名されたバイト列が命じるとおりに実行します。そして、あなたの意図と実際の中身を突き合わせられる場所は、画面のほかにありません。画面に16進数が並んでいれば、その突き合わせは不可能です。攻撃者は、まさにその不可能さを狙って作り込んできます。

ここにある溝は情報の溝であって、数学の溝ではありません。署名は「100 USDCのスワップに同意した」とは書き込みません。書き込まれるのは「この鍵はこれらのバイト列を認可する」だけです。そのバイト列がスワップを意味するのか、無制限のアプルーブを意味するのか、それともあなたのNFTをタダ同然で売り渡すオフチェーンの注文を意味するのか。それに答えられるのはインターフェースだけであり、インターフェースが答えを拒んだときに起きるのがブラインド署名です。

ブラインド署名はどこに現れるか

ブラインド署名は単一の機能ではなく、表示がデータに追いついていない状況の総称です。よくある容疑者は次のとおりです。

リクエストの種類たいてい表示されるものリスク
eth_sign生のハッシュか16進数の塊致命的。設計上検証不能であり、常に拒否する
生の型付きデータ(EIP-712)構造化されたフィールド(spender、金額、期限)意味が不明瞭なら高い。読めるフィールドは、理解したフィールドではない
コントラクトへのトランザクション解読された動作、またはウォレットが解読できない場合は生のcalldataウォレットの解読能力に全面的に依存する
ハッシュしか出ないハードウェア画面端末のディスプレイにハッシュのみ高い。端末が確かめているのは在席であって、理解ではない

4行すべてに共通するパターンは、リスクが読みやすさに連動するということです。表示が薄くなるところで、危険は濃くなります。

eth_signはなぜそこまで危険なのか

署名メソッドのなかで、eth_signはこの問題の最も純粋な形です。任意の32バイトの値に署名するようウォレットに求め、それは生の16進数として表示され、「これはただのメッセージだ」と示すプレフィックスは一切付きません。入力にドメイン分離がないため、その中身は何でもあり得ます。あなたの口座から資産を移すトランザクションのハッシュであっても構わないのです。注意深い専門家であっても、確認画面だけからリクエストを検証する方法はありません。設計上、検証不能なのです。主要なウォレットがこのメソッドを非推奨にしたり完全に削除したりしてきたのはそのためであり、実務上のルールに例外がないのもそのためです。2026年時点で、eth_signを要求してくるサイトは危険なほど時代遅れか、明確に敵対的かのどちらかであり、どちらの答えも「拒否」を意味します。

ハードウェアウォレットは実際に何を見せているのか

ハードウェアウォレットは鍵をオフラインに保ち、マルウェアが改ざんできない画面にリクエストを表示します。しかしその画面は、そこに描画される内容の分しか役に立ちません。端末が理解できないコントラクト操作については、多くの機種が歴史的に、ハッシュだけを表示する挙動へフォールバックしてきました。しかもその挙動は、設定項目としてそのまま blind signing と名付けられていたのです。信頼できる画面でハッシュを承認しても、証明されるのはボタンを押したという事実だけで、何を承認したのかについては何も証明されません。ハードウェアセキュリティの約束は見たものが、署名するものであるはずですが、見えているものが32バイトのノイズであれば、その約束は静かに崩れます。ハードウェアの隔離が守るのは鍵であって、判断ではありません。

ドレイナーはブラインド署名をどう悪用するのか

ドレイナーキットは何よりもまず、署名体験に対する攻撃です。サイトはミントページやエアドロップの請求ページ、サポート窓口のように見えます。しかし飛んでくるリクエストは、無制限のトークンアプルーブ、NFTコレクション全体を対象とするsetApprovalForAll、あるいは後から追加の確認画面なしに資産を動かすオフチェーンのPermitや注文の署名です。これらに共通するのは見せ方です。被害者は読めなかった、あるいは読んでも理解できなかったリクエストに署名し、そのあとでドレインが起きました。手口の全体像はウォレットドレイナーとは何かで、アプルーブの仕組みは、ガス不要の署名1つでトークン残高が空になり得る理由も含めてトークンアプルーブとPermitの解説で扱っています。どちらも同じ根本原因にたどり着きます。盗みが起きるのは署名の瞬間であり、その瞬間を攻撃者にとって切り抜け可能なものにしているのがブラインド署名なのです。

クリアサイニングとは何か、そしてどこまで進んだのか

業界の答えがクリアサイニング(clear signing)です。署名を求める前に、ウォレットはすべてのリクエストを人間が検証できる言葉へ翻訳しなければならない、という原則です。2026年時点で、これは二つの仕組みに支えられています。解読(デコード)。ウォレットが呼び出されるコントラクトと関数を認識し、「トークンXをアプルーブ、スペンダーはY、金額は無制限」といった一文として描画します。ERC-7730のような取り組みがオープンなメタデータのレジストリを整備しており、ハードウェアウォレットの画面でさえ、ハッシュではなく人間の言葉でコントラクト呼び出しを表示できるようになりつつあります。シミュレーション。ウォレット、またはウォレットが呼び出すサービスが、署名前に現在のチェーン状態に対してトランザクションを実行し、結果をプレビューします。どの資産が出ていき、どれが入ってきて、どのアプルーブが変わるのか。シミュレーションは予測であって保証ではありません。プレビューとブロック取り込みの間に状態は変わり得ますし、敵対的なコントラクトは取り込まれた後に別の振る舞いをすることもあります。それでも、自分のNFTが見知らぬアドレスへ出ていくと示すプレビューは、大半のドレインをその場で止めます。2026年時点でも普及状況はウォレットやチェーンによってまちまちなので、警告を当てにする前に、日常的な操作で自分のウォレットが実際に何を描画するのかを確かめてください。

実践ルール:読めないものは信用しない

安全でいるためにcalldataを読める必要はありません。必要なのは、読めないリクエストが自動的に不成立になる習慣です。

  • eth_signのリクエストは絶対に承認しない。まっとうな主流の用途はもう残っていません。そのリクエストが来たこと自体を危険信号とみなしてください。
  • 解読とシミュレーションに対応したウォレットを選ぶ。日常的な操作で生の16進数しか出ないなら、それは乗り換えるに値するウォレット側の問題です。
  • 重要なフィールドを読む。型付きデータのリクエストなら、spender、金額、期限、オペレーターです。無制限の金額や見覚えのないスペンダーは、そこで止まるべき合図です。
  • ハードウェアのブラインド署名モードはオフのままにする。特定の1件のトランザクションになぜそれが必要なのかを正確に理解している場合を除きます。使ったら必ずオフに戻してください。
  • 接続は意識的に行う。まずいリクエストの多くは、急いだ接続から入ってきます。ウォレットをdAppへ安全に接続する方法で紹介している手順が、玄関を守ってくれます。
  • 読めないものは信用できない。署名を拒否しても、かかるコストはやり直しの手間だけです。間違った署名は、すべてを失わせることがあります。この非対称性が答えを決めてくれます。

WATSの位置づけ

ブラインド署名は表示の問題です。解読とシミュレーションはリクエストを読める形にできますが、そのリクエストが本当にあなたの望むものかどうかは、WATSを含めどのウォレットにも代わりに判断できません。ウォレットが決められるのは、その判断を権限へ変える鍵を誰が握っているか、という点です。WATS Hot Walletは完全にノンカストディアルです。鍵を保有するのはあなたであり、WATSが鍵を保有することは一切ありません。Ethereum、Arbitrum、Optimism、Base、Polygon、BNB Chain、Solana、TONのいずれでも、あなたが承認した署名なしに送金があなたの口座を出ていくことはありません。これでリスクの一区分がまるごと消えます。誰かがあなたの代わりに署名することはあり得ないからです。そのうえで、上に書いた「読む」規律のほうは、まぎれもなくあなたの担当として残ります。

WATS NFC Metal Cardも同じく正直な立ち位置にあります。秘密鍵は保存しませんし、calldataの解読もしません。固有のカードIDを持ち、ちょうど一台の端末とペアリングされたタップ認証用のデバイスであり、WATSのアプリの中にある鍵に対して認証を行います。これは物理的な要素を足してくれます。画面の上にあるものだけでなく、手に持っているものが加わるわけです。ただし、読めないリクエストを読めるようにすることはできません。それができるのは確認画面そのものだけです。

ですから、この二つの半分は分けて扱ってください。読む側の半分は習慣です。読めないものには決して署名せず、剥き出しの16進数で届いたものはすべて拒否する。カストディ側の半分は一度きりの選択です。鍵はノンカストディアルウォレットに置き、署名の権限をあるべき場所に留めておく。WATS Hot Walletをインストールし、読めない確認画面はすべて自動的に拒否へ回してください。そして、WATSのアプリにある鍵へのアクセスを物理的な要素で認証したいなら、WATS NFC Metal Cardを端末とペアリングしてください。

よくある質問

ブラインド署名とeth_signは同じものですか?

いいえ。eth_signはその最も極端なケースです。ブラインド署名とは、自分が何を認可しているのか読めないまま行う承認すべてを指します。生のcalldata、不透明な型付きデータ、ハッシュしか出ないハードウェアウォレットの画面などです。eth_signはさらに一歩進んで原理的に検証不能であり、だからこそ主要なウォレットは非推奨にするか削除してきました。eth_signのリクエストはすべてブラインド署名ですが、ごく普通のトランザクション確認画面でもブラインド署名は数多く起きています。

ハードウェアウォレットはブラインド署名から守ってくれますか?

部分的にしか守れません。ハードウェアウォレットは鍵をオフラインに保ち、マルウェアが改ざんできない画面にリクエストを表示します。しかし端末がコントラクト呼び出しを解読できなければハッシュしか表示されないことがあり、ハッシュを承認しても何を認可したのかは分かりません。2026年時点では、クリアサイニングのメタデータ標準が端末の画面に届くにつれて保護は改善しつつあります。ハードウェアが隔離するのは鍵であって、それ自体がトランザクションを説明してくれるわけではありません。

ノンカストディアルウォレットはブラインド署名から守ってくれますか?

守るのは鍵であって、判断ではありません。ノンカストディアルとは、署名を生成できるのがあなただけだという意味です。WATS Hot Walletがその一例で、鍵を保有するのはあなたであり、WATSが鍵を保有することは一切ありません。Ethereum、Arbitrum、Optimism、Base、Polygon、BNB Chain、Solana、TONのいずれでも、あなたの承認なしに資産が動くことはありません。これで第三者があなたの代わりに署名するリスクは消えますが、自分で承認した署名はやはり有効なので、承認前にリクエストを読むことは変わらずあなたの仕事です。WATS NFC Metal Cardは、WATSのアプリの中にある鍵に対してタップ認証という物理的な要素を追加します。秘密鍵は保存せず、calldataの解読も行いません。

ウォレットが生の16進数しか表示しないときはどうすればよいですか?

拒否してください。読めない署名リクエストは評価できないリクエストであり、拒否のコストはやり直しの手間だけです。そのうえで調べましょう。そのdAppは本物か、自分のウォレットはそのチェーンで解読とシミュレーションに対応しているか、その操作が本当にその方式を必要としているか。解読された確認画面やシミュレーションのプレビューといった読める経路があるなら、それを使ってください。どれも存在しないなら、そのリクエストは信用できないものとして、その場を離れてください。