IPSECアンチリプレイ
暗号化されたパケットでもリプレイになり得るのはなぜか？
コピーされた暗号文は、改変されずに再び届くことがあります。ESPのアンチリプレイは、シーケンス番号をセキュリティアソシエーションに関連付け、範囲が限定された受信ウィンドウで確認し、認証後に状態を確定します。保護が適用されるのは、選択されたトンネルの両端です。アプリケーションコマンドには、重複とタイミングに関する独自のルールが引き続き必要です。
トンネルの両端
両端のゲートウェイがトラフィックを認証し、中間のスイッチは転送します。
シーケンスウィンドウ
ウィンドウ内の未受信のシーケンス番号は検証対象となり、重複は破棄されます。
検証後に確定
認証済みのパケットだけが、信頼できる受信状態を進めます。
両端と保護範囲を明確にします。
実際のプロトコルと設定を確認します。
許可を得たうえで無害なデータを使用してテストします。
選定・検証チェックリスト — 展開
両端とSAを特定し、リプレイ対策の設定を確認します。許可を得たうえで無害なデータを使用し、順序が入れ替わったパケット、重複パケット、不正なパケットをテストします。
遠隔データリンクが暗号化されているのに、セキュリティゲートウェイはなぜパケットのシーケンス番号を記録するのでしょうか。第三者にメッセージを読ませないことと、同じメッセージを再び受理しないことは、異なる目的です。内容を理解しなくても、正規のパケットをコピーして再送することは可能です。アンチリプレイにより、受信側はすでに受理したパケットを記録できます。
改変されていないパケットでも重複になり得る
封印された作業指示書を想像してください。封印は内容が改変されていないことを示す助けにはなりますが、それだけでは同じ指示書がすでに届けられていないことは示せません。同様に、取得された暗号化パケットは、攻撃者が復号したり、新たな有効なコマンドを作成したりしなくても再送できます。
この例えが説明するのは、繰り返し届けられることだけです。実際のプロトコルでは鍵と認証アルゴリズムを使用します。機密性、完全性、アンチリプレイは、それぞれ異なる要件に対応します。Ethernetの誤り検出は、暗号学的認証の代わりにはなりません。伝送エラーの検出と、適切な鍵を持つ者がパケットを作成したかどうかの確認は、別の処理です。
製品説明に暗号化の記載があるだけでは、古いパケットをどのように拒否するかは分かりません。プロトコル、実際のセキュリティ処理の終端、ネゴシエーションで決定された設定、受信側の確認処理を特定してください。本記事ではIPsec ESPを例に取り上げますが、経路上のすべての産業用機器にアンチリプレイ機能があるとするものではありません。
記録を保持する両端を特定する
IPsecはIPネットワーク上のトラフィックを保護でき、ESPはそのパケット保護機構の1つです。セキュリティアソシエーション（SA）は、関連する鍵、アルゴリズム、状態などを含む、片方向の保護の取り決めです。双方向の記録を、1つの共有カウンターとして扱ってはいけません。
送信側は、あるSAに属するパケットに番号を付けます。受信側は対応するアソシエーションを選び、自身の記録を確認します。ネットワーク上のすべての機器と番号を比較するわけではありません。ESPのSecurity Parameters Index（SPI）はアソシエーションの識別に役立ち、シーケンス番号はアンチリプレイの確認に使用されます。これらのフィールドには、対応する完全性保護が適用されなければなりません。
同じリンク内に、シリアルサーバー、産業用Ethernetスイッチ、外部セキュリティゲートウェイが存在する場合があります。飛暢のFCT-1100-F1S1シリアルデバイスサーバーは、シリアル通信をネットワークに接続する実製品の例ですが、IPsecを実装していると主張するものではありません。外部ゲートウェイがトンネルを終端する場合、終端での確認処理はそれらが実行します。通常の転送スイッチに、アンチリプレイウィンドウが自動的に備わるわけではありません。
最後の番号より大きい番号だけを受理しないのはなぜか？
パケットは必ずしも送信順に届くとは限りません。経路、キュー、並列処理により、後のパケットが先に届く場合があります。受信側が、それまでの最大番号より小さい番号をすべて拒否すると、遅れて届いた正規のトラフィックまで破棄するおそれがあります。確認処理では、ある程度の順序入れ替わりを許容しながら、重複を認識する必要があります。
スライディングウィンドウを、番号付きのスロットとして考えてみてください。各スロットは、そのシーケンス番号のパケットがすでに認証され、受理されたかどうかを記録するもので、パケット全体を保存するものではありません。上端は認証済みの最大番号を追跡し、下端は未受信のパケットについて、どこまで順序の前後を許容するかを制限します。古すぎるパケットは破棄されます。
説明用の例として、ウィンドウが101から108までの番号を含み、106がすでに受理されているとします。2つ目の106は重複です。105が未受信なら、認証に進めます。8スロットはあくまで説明用であり、標準のウィンドウサイズでも飛暢製品の仕様でもありません。
認証成功後にのみウィンドウを移動する
パケット109が届いたとき、受信側は番号が大きいという理由だけで記録を進めてはいけません。そうしなければ、攻撃者が非常に大きな番号を偽装し、正規のトラフィックをウィンドウの外に追いやることができてしまいます。「ウィンドウをスライドする」という言葉を覚えることよりも、確認処理の順序が重要です。
実装によっては、まず予備的なシーケンス確認を行い、明らかな重複や古いパケットを破棄することがあります。通過したパケットも、適切な完全性確認または認証に合格する必要があります。成功した後にのみ受信済みとして記録し、必要に応じてウィンドウを進めます。予備的な確認だけで、パケットが信頼できるようになるわけではありません。
認証に失敗したパケットが、新しいスロットを占有したり、認証済みの最大番号を進めたりしてはいけません。アルゴリズムや実装によって、内部処理の構成は異なる場合があります。重要なのは、初期フィルタリング、暗号学的検証、状態の確定を区別することです。番号が大きいというだけでは、引き渡しを許可する理由にはなりません。
損失、順序の入れ替わり、リプレイは似て見えることがある
ウィンドウは範囲内に届いた未受信の番号を受理できますが、どれほど遅れたトラフィックでも受理できるわけではありません。順序の入れ替わりが大きいと、正規のパケットが下端より下になる場合があります。したがって、破棄数が増えたというだけでは、攻撃、光ファイバーの損傷、スイッチポートの故障の証拠にはなりません。
時刻、方向、セキュリティアソシエーション、アプリケーションの記録を照合してください。同じ時期に、経路変更、キューの滞留、ゲートウェイ負荷の変化がなかったかを確認します。ウィンドウの拡大は万能な対策ではありません。実装上の制限、処理コスト、許容できる遅延を検証してください。アラームを隠すためだけに保護を無効にしてはいけません。
ウィンドウは失われたパケットを復元しません。パケットを次の処理に進められるかどうかを判断するものです。再送、セッション復旧、アプリケーションのタイムアウト動作は、対応するトランスポートまたはアプリケーションの仕組みが担います。アンチリプレイウィンドウは、信頼性のある配送プロトコルでも、汎用的なパケット並べ替えバッファーでもありません。
新しいトンネルパケットに、古いアプリケーションコマンドが含まれることがある
アプリケーションは同じ操作を再送することがあります。セキュリティ処理の終端は、その2回目の要求を、新しいシーケンス番号を持つ新しい外側パケットにカプセル化できます。トンネル層では以前に受理したESPパケットではありませんが、アプリケーション層では重複した操作である可能性があります。
したがって、アンチリプレイはすべてのコマンドが1回だけ実行されることを保証しません。実際のプロトコルに応じて、重要な操作には、トランザクション識別子、重複要求の処理、有効期限、権限、現在の状態との照合が必要になる場合があります。こうした機能には、両端での合意と検証が必要です。フィールドを追加するだけで完全なセキュリティが成立するわけではありません。
ウィンドウ内の有効な未受信パケットであっても、業務上の操作にとって適時であるとは限りません。遅延したコマンドを実行すべきかどうかは、アプリケーションが判断します。パケットの重複、送信者の真正性、その操作を今行うことが適切かどうかは、分けて考えてください。
仕組みを検証可能なプロジェクト記録に落とし込む
トンネルの両端と、実際に保護する範囲を明示してください。プロトコル、ネゴシエーション、対応するウィンドウ、ログの意味を検証します。シリアルインターフェース、Ethernet転送、セキュリティ処理は、異なる層です。光ファイバー、VLAN、シリアルネットワークへの対応は、特定の暗号アルゴリズムへの対応や認証取得を示すものではありません。
許可されたテスト環境で、隔離した無害なデータを使用し、通常の順序、許容される順序の入れ替わり、パケットの重複、認証失敗を観察してください。文書の版、設定、結果を記録します。実際の本番制御コマンドをリプレイしたり、図中の説明用の数値を測定値として提示したりしてはいけません。
3つの役割を覚えておきましょう。暗号化は内容を保護し、リプレイウィンドウは受理済みのパケット番号を記録し、アプリケーションは引き続き操作の重複とタイミングを処理します。認証は、でっち上げたシーケンス番号だけで信頼できる記録が進められることを防ぎます。これらの役割の境界を明確にすることで、産業用通信の設計を評価しやすくなります。
主な参考資料
RFC 4303：IP Encapsulating Security Payload、第2.1節、第2.2節、第3.4.3節; RFC 6479：IPsecアンチリプレイアルゴリズム （情報提供を目的とする文書であり、必須のインターネット標準ではありません）。製品の例： FCT-1100-F1S1シリアルデバイスサーバー。これは、その製品のIPsec対応を主張するものではありません。
以下の中国語技術記事から翻訳： 中国語の原文記事を読む.
実務上のよくある質問
暗号化だけでリプレイを防げるか？
いいえ。リプレイ対策には、シーケンスの追跡、認証、正しい受信側状態も必要です。
古いシーケンス番号はすべて拒否されるか？
いいえ。ウィンドウ内の未受信の番号は認証に進めます。重複した番号と古すぎる番号は拒否されます。
トンネルのアンチリプレイは、コマンドが1回だけ実行されることを保証するか？
いいえ。新しい外側パケットに、繰り返されたアプリケーションコマンドが含まれることがあります。アプリケーションには独自のルールが必要です。
適用範囲と参考資料
汎用的なESPアンチリプレイの概念であり、特定製品についての主張ではありません。
