こんにちは！スマートコントラクトの開発に挑戦している皆さん、日々のコーディングお疲れ様です。「ブロックチェーンの世界は楽しそうだけど、セキュリティの話になると急に難しくなるな…」と感じていませんか？
今回は、Web3開発で絶対に避けて通れない「署名リプレイ攻撃の防止とNonce（ノンス）管理」について、身近な防犯の例えを交えながら、一歩ずつ優しく紐解いていきたいと思います。
難しい専門用語が出てきても置いてけぼりにしませんので、リラックスして読み進めてくださいね！
—
1. 家の鍵の「合鍵」と「使い回し」の危険な関係
突然ですが、みなさんのご自宅の玄関の鍵を想像してみてください。
ある日、宅配便を受け取るために、家族の誰かが紙に「〇〇です、この署名があれば荷物を渡してOKです」とサイン（署名）を書いて、置き配の箱に貼り付けたとします。泥棒がそのサインをこっそりスマホでパシャリと写真に撮ったらどうなるでしょうか？
もし、そのサインに「日付」や「何回目の使いか」という数字が書かれていなければ、泥棒は何度でもその写真を貼り付けて、あなたの大切な荷物を盗み出すことができますよね。
ブロックチェーンの世界でも、これとまったく同じことが起こります。これが「署名リプレイ攻撃」と呼ばれるものです。
Web3における署名とは？
ユーザーがウォレット（MetaMaskなど）を使って、「このトランザクション（処理）に賛成します！」と秘密鍵で暗号学的なサインをすることを指します。スマートコントラクト側は、「おっ、本人のサインだからこの処理を実行していいんだな」と信頼して動きます。
しかし、この署名データがネットワーク上にむき出しで流れてしまうため、悪意ある攻撃者がそれをコピーし、別の場所や別のタイミングで「使い回し（リプレイ）」てしまうのです。
—
2. 泥棒を防ぐ魔法の数字「Nonce（ノンス）」とは？
この「署名の使い回し」を防ぐために用意された最強の防犯アイテムが、Nonce（ノンス）です。
Nonceとは、「Number used once（1度だけ使われる数字）」の略で、要するに「使い捨てのカウンター（回数券）」のことだと思ってください。
カウンター付きの合鍵のイメージ
先ほどの宅配便の例で考えてみましょう。今度は、サインと一緒に「今回は【3回目】の受け取りです」と毎回違う数字を書くルールにしました。
1. 1回目のサイン（Nonce: 1）→ 無事に荷物を受け取る。
2. 2回目のサイン（Nonce: 2）→ 無事に荷物を受け取る。
3. 攻撃者が「1回目のサイン（Nonce: 1）」の写真を盗み出して、もう一度使おうとする。
さて、システム側はどう判断するでしょうか？
「おや？このユーザーの現在のNonceはすでに『3』なのに、持ってきたサインは『1』古いよ。これは使い回しだ！エラー！」と、泥棒を瞬時に撃退してくれます。
このように、「一度使ったNonceは二度と使えないように記録し、次に使う時は数字を増やす」という仕組みをコントラクトに実装するのが、安全なNonce管理の基本になります。
—
3. 実装で学ぶ！堅牢なNonce管理と署名検証コード
それでは、実際にSolidityという言語を使って、署名リプレイ攻撃を防ぐためのスマートコントラクトの書き方を見ていきましょう。
今回は、ユーザーからのメッセージに「Nonce」と「有効期限」を含め、安全に処理するサンプルコードを用意しました。日本語のコメントを丁寧に書いているので、じっくり読んでみてくださいね。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
import "@openzeppelin/contracts/utils/cryptography/MessageHashUtils.sol";
/**
* @title 署名リプレイ攻撃を防ぐNonce管理のサンプルコントラクト
* @notice 初心者の方でも理解しやすいよう、最低限の機能に絞っています
*/
VersatileSignatureReplayPrevention {
using ECDSA for bytes32;
// ユーザーごとの現在のNonceを記録するマッピング (アドレス => Nonceの数値)
mapping(address => uint256) public nonces;
// 署名が実行されたときに発生させるイベント
event ActionExecuted(address indexed user, uint256 nonce);
/**
* @notice ユーザーの署名を検証し、リプレイ攻撃を防ぎながら処理を実行する関数
* @param amount 処理する金額やデータなどのパラメータ
* @param deadline 署名の有効期限（タイムスタンプ）
* @param signature ユーザーがウォレットで作成した署名データ
*/
function executeWithSignature(
uint256 amount,
uint256 deadline,
bytes calldata signature
) external {
// 1. 署名の有効期限が切れていないかチェック
require(block.timestamp <= deadline, "Signature has expired");
// 2. ユーザーの現在のNonceを取得
uint256 currentNonce = nonces[msg.sender];
// 3. 署名データの中に「誰の」「いくらか」「どのNonceか」「いつまでか」をギュッと詰め込む
// これにより、他の文脈でこの署名が使われるのを完全に防ぎます
bytes32 messageHash = keccak256(
abi.encodePacked(msg.sender, amount, currentNonce, deadline, block.chainid)
);
// 4. Ethereumの標準的なプレフィックスを付与してハッシュ化
bytes32 ethSignedMessageHash = MessageHashUtils.toEthSignedMessageHash(messageHash);
// 5. 署名したのが本当に本人（msg.sender）かどうかを復元して確認
address signer = ethSignedMessageHash.recover(signature);
require(signer == msg.sender, "Invalid signature");
// 6. 【超重要】リプレイ攻撃を防ぐため、処理の実行前にNonceを必ずインクリメント（+1）する
// これにより、同じ署名をもう一度使おうとしても、nonceのズレで弾かれるようになります
nonces[msg.sender] = currentNonce + 1;
// 7. 本来実行したかった処理をここに記述する
// 例: トークンの送金や、重要なデータの更新など
// 8. 実行完了のイベントを通知
emit ActionExecuted(msg.sender, currentNonce);
}
}コードのポイント解説
block.chainidをハッシュに含めているのはなぜ？- これは「チェーンID」と言って、イーサリアムの本番ネットワーク（Ethereum Mainnet）と、テスト用のネットワーク（Sepoliaなど）を区別するためです。これを入れておかないと、テストネット用の署名が本番ネットで悪用されるという恐ろしい事態（クロスチェーン・リプレイ攻撃）を防げなくなってしまいます。
- Nonceを増やすタイミングは？
- 必ず「署名の検証が成功した後、処理を実行する前（または同時）」に行います。処理の前に値を更新しておかないと、万が一の再入可能性攻撃などの隙を突かれる原因になります。
—
4. フロントエンド（JavaScript）側での実装のコツ
コントラクト側でNonceを厳格に管理するようになったら、それを使うアプリ側（フロントエンド）でも正しいNonceを渡してあげる必要があります。
// 【参考】フロントエンド側でコントラクトから現在のNonceを取得する流れ
async function signMessage(userAddress, amount, contract, signer) {
// 1. コントラクトから現在のNonceをコントラクトに問い合わせる
const currentNonce = await contract.nonces(userAddress);
// 2. 有効期限を設定（例: 5分後に切れるようにする）
const deadline = Math.floor(Date.now() / 1000) + 300;
// 3. チェーンIDを取得
const network = await signer.provider.getNetwork();
const chainId = network.chainId;
// 4. コントラクト側と同じルールでハッシュを生成して署名してもらう
// （※実際のプロジェクトでは ethers.js の solidityPackedKeccak256 等を使用します）
console.log("現在のNonce:", currentNonce.toString());
console.log("安全な署名プロセスを開始します...");
}アプリを作る際、「あれ？なんかトランザクションが失敗するぞ…？」となった時は、大抵この「フロントエンド側が持っているNonceの数字」と「スマートコントラクト側が記録しているNonceの数字」がズレてしまっていることが原因です。エラーが出たら、まずはコントラクトの nonces(address) を覗いてみるのがデバッグの第一歩ですよ！
—
まとめ
今回は、署名リプレイ攻撃の仕組みと、それを防ぐためのNonce管理のベストプラクティスについて解説しました。
- 署名リプレイ攻撃とは、過去のサインを盗まれて何度も悪用される攻撃のこと。
- Nonce（使い捨ての数字）をコントラクトで管理し、利用するたびに数字をカウントアップさせることで、使い回しを完全にシャットアウトできる。
- ハッシュには「ユーザーアドレス」「パラメータ」「Nonce」「有効期限」「チェーンID」をしっかりと含めよう。
セキュリティの世界は最初は難しく感じるかもしれませんが、こうした「現実世界の防犯対策」と紐付けていくと、とても論理的でスッキリと理解できるようになります。
一歩ずつ、確実に堅牢なコードが書けるエンジニアを目指して一緒に頑張っていきましょう！質問や感想があれば、ぜひコメント欄で教えてくださいね。
コメント