EIP-712の向こう側：署名リプレイ攻撃を根絶するアーキテクチャの極意
SCADAシステムのシリアル通信を解析していた頃、私は「信頼できる通信経路」など存在しないという教訓を骨の髄まで叩き込まれた。パケットが物理層で傍受され、フラグが反転させられる。Web3のスマートコントラクトも同じだ。署名データという「バイナリの断片」は、一度流出したり傍受されたりすれば、悪意あるアクターにとっての「再利用可能な鍵」へと変貌する。
今回は、EIP-712を用いた署名検証の先にある、真の防御アーキテクチャについて語ろう。
1. なぜ「署名の再利用」は防ぎきれないのか？
多くの開発者は ecrecover で署名者のアドレスを特定すればセキュリティが担保されると勘違いしている。しかし、それは「誰が署名したか」を証明しているに過ぎない。「いつ、どこで、何回使われたか」というコンテキストが欠如しているのだ。
攻撃者はオフチェーンで生成された署名を、別のコンテキスト（例えば異なるチェーンIDや、別のコントラクトアドレス）へ持ち込み、リプレイ攻撃を仕掛ける。これを防ぐには、単なる nonce 管理以上の「境界定義」が必要となる。
2. EIP-712の実装：構造化データの「意味」を刻む
EIP-712は、ただのバイト配列に過ぎなかった署名データに、ドメイン分離という「文脈」を付与する。ここで重要なのは、DOMAIN_SEPARATOR の定義をいかに厳格に行うかだ。
// EIP-712のドメイン分離用構造体
bytes32 public constant DOMAIN_TYPEHASH = keccak256(
"EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"
);
// 署名検証用の構造体定義
bytes32 public constant PERMIT_TYPEHASH = keccak256(
"Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)"
);
function _verify(
address owner,
uint256 nonce,
bytes memory signature
) internal view returns (bool) {
// コンテキストが一致しない場合は即座に棄却
bytes32 domainSeparator = keccak256(abi.encode(
DOMAIN_TYPEHASH,
keccak256("MyProtocol"), // プロトコル名
keccak256("1"), // バージョン
block.chainid, // チェーンIDでクロスチェーンリプレイを遮断
address(this) // 契約アドレス自身を指すことで、他コントラクトへの転用を防ぐ
));
// ...以降、署名のハッシュ化と ecrecover による照合...
}ここで注目すべきは block.chainid と address(this) のハードコーディングではない動的な組み込みだ。これらが一つでも漏れれば、攻撃者はチェーン間を跨いだリプレイ攻撃を試みる。
3. シーケンシャルNonceの脆弱性と「非同期インデックス」への転換
単調増加する nonce は、オフチェーンでの署名生成順序とオンチェーンでのトランザクション実行順序がずれた際、UXを阻害する。さらに、DoS攻撃に近い手法で特定ユーザーの nonce を枯渇させることも可能だ。
最先端のアーキテクチャでは、単なるインクリメントではなく、BitMap を用いた「ノンシーケンシャルNonce管理」を推奨する。
// 非同期実行を許容するNonce管理の概念コード
mapping(address => uint256) public usedNonces; // ビットマップで管理
function _useNonce(address owner, uint256 nonce) internal {
// 256個のNonceを1つのuint256で管理し、順序に関係なく検証
uint256 bucket = nonce / 256;
uint256 bit = 1 << (nonce % 256);
require((usedNonces[owner] & bit) == 0, "Nonce already used");
usedNonces[owner] |= bit;
}この手法は、並列処理やオフチェーン署名の非同期性を確保しつつ、リプレイを防ぐ。物理レイヤの通信におけるシーケンス番号管理と概念は同じだが、ブロックチェーンでは「状態の永続性」が守られているため、より強固な防御層となる。
4. 未来への備え：耐量子暗号（PQC）への移行
現在、我々が使用している ECDSA は、将来的にショアのアルゴリズムを用いた量子コンピュータによって解読される可能性がある。署名リプレイ攻撃の防衛は重要だが、署名アルゴリズムそのものの脆弱性も無視できない。
現在、セキュリティアーキテクトとして推奨するのは、「署名検証ロジックをモジュール化しておくこと」だ。将来的に ECDSA から Dilithium などの耐量子署名アルゴリズムへ移行できるよう、コントラクトの検証部分を delegatecall によるアップグレード可能な設計にするか、抽象化レイヤーを設けておくことが必須となる。
5. 生成AIによるプロンプトインジェクションへの防御
最後に、UI/UX側での盲点にも触れておく。最近ではスマートコントラクトを操作するための生成AIエージェントが普及しているが、このAIが「不正なパラメータ」を含むEIP-712署名リクエストをユーザーに提示するリスクがある。
防御策として、フロントエンド側の Guardrail として、署名内容を解析し、ユーザーに対して「何のための署名か」を自然言語で再確認させる層を必ず実装せよ。AI任せの署名は、現代の「フィッシング」の入り口である。
—
結び：
セキュリティとは、ツールを導入することではない。システムがいかに「意図しない文脈」で利用される可能性を潰し続けるかという、終わりのないチェスゲームだ。EIP-712を実装しただけで満足しているようでは、まだ攻撃者の射程圏内にいる。常に「コンテキストの分離」を意識し、メモリのビット単位まで疑い抜く姿勢こそが、最高峰の防衛技術へと繋がる。
コメント