ナンスの実装は簡単だと思いますか?もう一度考えてください。 オンチェーン プロトコルを構築する場合でも、オフチェーン インフラストラクチャを構築する場合でも、適切なナンス実装は暗号化セキュリティの最も難しい部分の 1 つです。 リプレイ保護が見た目👇よりも難しい理由を詳しく見てみましょう

2/ まず、デジタル署名を理解しましょう。公開鍵暗号 (BLS など) には、メッセージに署名する秘密鍵と、メッセージを確認する公開鍵があります。 イーサリアムの場合: アドレス = 公開鍵ハッシュ メッセージ = トランザクションハッシュ 署名 = 64 バイトの暗号化証明

3/ 問題は、ほとんどの公開鍵暗号プロトコルの計算では、同じメッセージに対して署名を検証できる回数を制限していないことです。有効な署名を取得したら、無限に再生できます。これにより、攻撃をリプレイする扉が開かれます。

4/ ナンスを入力します: リプレイ攻撃を防ぐ「一度使用された番号」。コンシューマーは、nonceを含むメッセージを受信すると、そのnonceが以前に使用されたかどうかを確認します。「はい」の場合、→拒否します。イーサリアム トランザクションはこのパターンを使用します。

5/ しかし、ノンスの実装は一見複雑です。主な要件: - ナンスは(このチェーンまたは他のチェーンで)再利用可能であってはなりません。 - リプレイ攻撃を永久に防止する必要があります - ストレージの増加に対応するメカニズムが必要 - フロントランニング攻撃に耐性がある必要があります

6 /素朴な解決策:すべてのナンスをデータベースに永久に保存します。これには2つの大きな問題があります。 a) ストレージの無制限の増加 (特にスパム攻撃の場合) b) フロントランニング攻撃に対する脆弱性 問題(a)は(b)よりも解きやすいです。まずはストレージに取り組みましょう...

7/ タイムスタンプベースのナンスでストレージの増加を解決!タイムスタンプ + 有効期限を使用します。5 分より古いナンスはデータベースから削除されます。しかし、同じアカウントからの同時メッセージはどうでしょうか?タイムスタンプを共有します。解決策: タイムスタンプ + きめ細かな一意性のためのrandom_bytes。

8/フロントランニングは難しい部分です。悪意のある攻撃者は有効な署名を傍受し、それらをフロントランしてナンスが使用されたものとしてマークし、正当なユーザーの呼び出しが拒否されます。これは、1 つの不正な署名がバッチ全体を拒否した場合、バッチ操作のオンチェーンで問題になります。オフチェーンの場合: TLS 暗号化を使用します。悪意のある攻撃者にナンスや署名を見させないでください。

9/ 粘り強さを忘れないでください!ノンス キャッシュがメモリ内のみにある場合、攻撃者はシステムの再起動後に古いナンスを再生できます。常に nonce 状態を永続ストレージに保持し、起動時にリロードします。メモリのみのキャッシュ = リプレイの脆弱性ウィンドウ。

10/ 消費者ごとにユニークなナンス!複数のユーザーにブロードキャストする場合、それぞれが異なるメッセージ/署名を取得する必要があります。そうしないと、1 人の受信者が元の送信者になりすましてメッセージを転送する中間者攻撃に対して脆弱になります。

11/ 増分ナンス (イーサリアムのように、nonce = prev nonce + 1) にはその場所がありますが、注意してください。これらは、オフチェーン インフラストラクチャに、順序がずれたメッセージ、同期の問題、複雑な回復シナリオなど、大きな課題を引き起こします。メッセージが順番に届く (または届く必要がある) と確信できる場合にのみ使用してください。

概要 - Nonce 実装チェックリスト: ✅ nonces を使用してリプレイ攻撃を防ぐ ✅ 再起動後もnonce状態を保持する ✅ 有効期限メカニズムの実装 (タイムスタンプ + クリーンアップ) ✅ ナンスを受信者ごとに一意にする ✅ 暗号化されたチャネルでフロントランニングから保護 ✅ 順序が保証されていない限り、増分ナンスは避けてください セキュリティは細部に宿ります!🛡️