メッセージへの署名：「ウォレットでサインイン」が本当に証明していること
遅かれ早かれ、サイトから取引を送る代わりに「メッセージに署名してください」と求められる日が来ます。ガス代はかからず、オンチェーンでの承認もなく、履歴にも何も残りません。無害に感じられますし、実際その多くは無害です。しかし署名とは、あなたの鍵が何かを保証するということです。毎回問うべきことはシンプルです。いったい何を保証しているのか？
署名が証明すること
デジタル署名が証明するのはただ一つ、特定の秘密鍵を管理している人物が、特定のデータに同意したということです。誰でもあなたの公開アドレスを使って検証できますが、それによって鍵について何かが知られることはありません。
そのため署名は、コインの送金以外にも幅広く役立ちます。サイトは、手数料を払わせることなく、あなたがあるアドレスの所有者であることを確認できます。開発者は、あるリリースを自分が公開したことを証明できます。ノード運営者は、あるサーバーが自分のものであることを証明できます。いずれもブロックチェーンには触れず、すべて同じ保証に基づいています。つまり、その鍵がまさにこのバイト列に署名した、ということです。
落とし穴は「まさにこのバイト列」という部分にあります。署名は意図を運びません。あなたがログインしているつもりだったのか、支払いを承認しているつもりだったのかを署名は知りません。署名はあなたの鍵をデータに結び付けるだけです。そして、その署名を手にした人は、データが許す範囲のあらゆる用途にそれを使えます。
「ウォレットでサインイン」
最もよく目にするメッセージはログインです。サイトはパスワードの代わりにテキストを送ってきて、あなたがそれに署名し、サイトはあなたのアドレスで署名を検証します。一致すればログイン完了です。
よくできたログインメッセージは小さな契約書のように読めます。イーサリアムの標準形式（EIP-4361、通称 SIWE、「イーサリアムでサインイン」）はその中身を次のように定めています。
- 要求元のドメイン——アドレスバーに表示されているサイトと一致しているはずです。
- サインインするアドレス。
- 平易な言葉による声明、たとえば「Example にサインイン」。
- ノンス——一度きりのランダムな値で、署名が後から再利用されるのを防ぎます。
- 発行日時と有効期限——古い署名が失効するようにするためのものです。
これらがすべてそろい、互いに一致していれば、ログイン署名のリスクは低いものです。一つのサイトでセッションを開くだけで、それ以上のことはしません。メッセージ内のドメインが、いま開いているサイトと一致しない場合は、そこで手を止めてください。その食い違いこそ、あなたの署名を別の場所で使い回そうとするフィッシングページが生み出すものです。
資金を動かせる署名
「ガス代がかからないから無害」という考えが崩れるのはここです。オフチェーン署名の中には、後から他人が提出してあなたの資金を動かせるものがいくつかあります。
- トークンのパーミット。 多くのトークンでは、オンチェーンの承認の代わりに署名で支出許可を与えられます。許可を受けた側がそれを提出すれば、許可された額まで送金できます。あなたの側からは、ただメッセージに署名したようにしか見えませんでした。名前以外はすべて承認そのものです。
- マーケットプレイスの注文。 署名済みの出品やオファーは、それを持っている人なら誰でも、あなたが署名した条件で約定できます。悪意のあるサイトがあなたの代わりに書き込んだ条件も含めてです。
- 生ハッシュへの署名。 古い方式の中には、読める内容がなく「ただのメッセージ」であることを示す接頭辞もない、任意の 32 バイトのハッシュに署名するものがあります。ハッシュは実際の取引の指紋である可能性があります。読めないハッシュに署名することは、最も純粋な形のブラインド署名です。
ここから導かれるルールは短いものです。何に署名しているのか読めないなら、それが何を許可するのかも分かりません。
署名リクエストの読み方
どんなメッセージを承認する前にも、同じ四つの質問を確認しましょう。
- 誰が求めているのか？ 要求元のサイトが、使うつもりだったサイトと同じかを確認します。
- どのアドレスで、どのネットワークか？ 想定と異なるアドレスやチェーンへのリクエストは警告サインです。
- 読めるか？ 理解できる平文なら一つの話です。16 進数、ハッシュ、説明のない長い JSON はまったく別の話です。
- 誰かに何を許すことになるのか？ ログイン、所有権の証明——問題ありません。支出、出品、送金、承認——取引として扱ってください。実際にそれは取引なのですから。
SSP が表示するもの
WalletConnect 経由で接続した dApp が SSP にメッセージへの署名を求めると、リクエストには要求元のサイト、アドレスとネットワーク、そしてメッセージ本体が表示されます。16 進数でエンコードされたメッセージはまず読めるテキストにデコードされ、確認したい場合は元のバイト列を展開表示で見られます。
通常のテキストメッセージには、イーサリアム標準の「署名済みメッセージ」接頭辞が付きます。これによって取引ではなくメッセージであることが示されるため、取引として再利用されることはありません。構造化された型付きデータのリクエストは、承認する前にその元の内容がすべて表示されます。
SSP のあらゆる操作と同じく、ウォレットからのメッセージ署名には両方の鍵が必要です。SSP Wallet で承認し、続いて SSP Key で確認します。この二つ目のステップは、別のデバイスで行う本物の「二度目の確認」であり、そのつもりで活用する価値があります。
SSP にできないのは、サイトが署名を使って何をするつもりなのかを教えることです。SSP はデータを忠実に表示します——それを読むのは、やはりあなたの役目です。
正直なまとめ
メッセージへの署名は、何も支払わずに鍵で物事を証明する方法であり、ほとんどの場合は見た目どおり無害です。例外は、支出や出品、送金を許可する署名です——そしてそれらは、読むまではまったく同じに見えることがよくあります。
だからこそ、読んでください。ドメイン、アドレス、チェーン、内容を確認しましょう。理解できるものにだけ署名し、読めないものはすべて「ノー」として扱ってください。
