リプレイ攻撃
送信されたデータを傍受して再送信することで、不正に繰り返したり応答を遅延させる攻撃
From Wikipedia, the free encyclopedia
リプレイ攻撃（英:Replay attack、再送攻撃、リピート攻撃やプレイバック攻撃とも呼ばれる）は、有効なデータを伝送する際に、悪意を持って不正に繰り返したり遅延させたりするネットワーク攻撃の一種である[1]。これは、送信元、またはデータを傍受して再送信する攻撃者によって行われ、IPパケットの置換によるスプーフィング攻撃の一部として行われることもある。これは、中間者攻撃にも分類され、低レベルなバージョンの一つである。リプレイ攻撃は通常、受動的な性質を持つ。
このような攻撃を言い換えると、 「ある状況（コンテキスト）で送られたメッセージを、別の状況で再送することで、安全なセキュリティプロトコルを破り、システム側に正常な処理が行われたと誤認させる攻撃」である[2]。
例
アリスがボブに対して自分のデジタルアイデンティティを証明したいと仮定する。ボブは身元証明としてパスワードを要求し、アリスはそれに応じる（パスワードはハッシュ化・ソルトが付与されたりする場合もある）。その間、イブ（攻撃者）は通信を傍受し、パスワード（またはハッシュ）を傍聴し保存している。やり取りが終わった後、イブ（攻撃者）はアリスになりして、ボブに接続する。身元証明を求められると、イブ（攻撃者）は前のセッションで読み取ったアリスのパスワード（またはハッシュ）を送信し、ボブ（攻撃者）はそれを受け入れ、イブにアクセス権を与えてしまう[2]。
予防と対策
リプレイ攻撃は、暗号化された各データコンポーネントにセッションIDとデータコンポーネント番号を付加することで防ぐことができる[2]。この対策で用いるセッションIDとデータコンポーネント番号は、それぞれが独立して機能する仕組みになっており、相互依存性がないため、脆弱性が少なくなる。プログラムの実行ごとに一意でランダムなセッションIDが作成されるため、前回の実行した内容を複製することがより困難になる。この例では、なりすまし時に実行するときには、セッションIDが変更されるため、攻撃者はリプレイを実行できない[2]。
セッショントークンとも呼ばれるセッションIDは、リプレイ攻撃を回避するために使用できるメカニズムの一つである。セッションIDを生成する方法は以下の通りである。
- ボブはアリスにワンタイムトークンを送信し、アリスはそのトークンを使用してパスワードを変換し、結果をボブに送信する。たとえば、アリスはトークンを使用してセッショントークンのハッシュ関数を計算し、使用するパスワードに付加する。
- ボブは自分の側で、セッショントークンを使用して同じ計算を実行する。
- アリスとボブの両方の値が一致する場合にのみ、ログインは成功する。
- ここで、攻撃者のイブがこの値をキャプチャし、別のセッションで使用しようとしたとする。ボブは異なるセッショントークンを送信するため、イブ（攻撃者）がキャプチャした値で応答しても、ボブの計算結果とは異なるものになり、ボブはそれがアリスではないと気付く。
セッショントークンはランダムなプロセスで選択する必要がある（通常は擬似乱数プロセスが使用される）。ランダム化しない場合、イブ（攻撃者）がボブになりすまし、予測されたトークンを提示し、アリスに変換でそのトークンを使用させることができる恐れがあるからである。その後、イブは後で（予測されたトークンが実際にボブによって提示されたときに）応答を再送でき、ボブは認証を受け入れてしまう。
ワンタイムパスワードは、パスワードが使用された後、または非常に短い時間経過後に期限切れになるという点で、セッショントークンと似ている。これらは、セッションに加えて個々のトランザクションを認証するためにも使用できる。これらは認証プロセス中にも使用でき、相互に通信している2者間の信頼を確立するのに役立つ。
ボブは使い捨ての数字であるノンスを用いることもできるが、その場合はメッセージ認証コード (MAC) を含める必要があり、アリスはそれを確認する必要がある。
タイムスタンプは、リプレイ攻撃を防ぐためのもう一つの方法である[3]。安全なプロトコルを使用して同期を達成する必要がある。たとえば、ボブは時計の時刻とMACを定期的にブロードキャストする。アリスがボブにメッセージを送信したい場合、アリスはボブの時計の時刻の最良の推定値をメッセージに含め、それも認証される。ボブは、タイムスタンプが妥当な許容範囲内にあるメッセージのみを受け入れる。リプレイ攻撃を防ぐために、ボブとアリスの両方が一意のセッションIDを使用して互いを認証する相互認証中にも、タイムスタンプが実装される[4]。この手法の利点は、ボブが（擬似）乱数を生成する必要がなく、アリスがボブに乱数を要求する必要がないことである。単方向ネットワークやそれに近いネットワークでは、これが利点となる。トレードオフとして、リプレイ攻撃が十分に速く、つまりその「妥当な」制限内で実行されれば、成功する可能性がある。
Kerberosプロトコルの予防
Kerberos認証プロトコルには、いくつかの対策が含まれている。リプレイ攻撃の典型的な例では、メッセージが敵対者によってキャプチャされ、後日攻撃のために再送される。たとえば、銀行のシステムがこの攻撃に対して脆弱であった場合、資金移動をもたらすメッセージが何度も再送され、本来意図された以上の資金が移動される可能性がある。しかし、Microsoft WindowsのActive Directoryに実装されているKerberosプロトコルには、タイムスタンプを含む仕組みが含まれており、リプレイ攻撃の有効性を大幅に制限している。「Time to Live（TTL）」を過ぎたメッセージは古いと見なされ、破棄される[5]。
トリプルパスワード方式の使用など、改善案も提案されている。これら3つのパスワードは、認証サーバー、チケット付与サーバー (TGS)、およびTGSで使用される。これらのサーバーはパスワードを使用して、異なるサーバー間の秘密鍵でメッセージを暗号化する。これら3つの鍵によって提供される暗号化は、リプレイ攻撃を防ぐのに役立つ[6]。
アドホックネットワークのルーティング
ワイヤレスアドホックネットワークもリプレイ攻撃を受けやすい。この場合、AODVプロトコルを拡張することで、認証システムを改善し、より強力にすることができる。アドホックネットワークのセキュリティを向上させるこの方法は、少量のオーバーヘッドでネットワークのセキュリティを向上させる[7]。大規模なオーバーヘッドが発生すると、ネットワークが遅くなり、パフォーマンスが低下するリスクがある。オーバーヘッドを比較的低く保つことで、ネットワークはセキュリティを向上させながらもより良いパフォーマンスを維持できる。
CHAPの活用
Point-to-Point Protocol (PPP) を使用するクライアント認証とサインオンにおいて、身元を検証するためにPassword Authentication Protocol (PAP) を使用する場合、リプレイ攻撃の影響を受けやすい。これは、認証するクライアントがユーザー名とパスワードを「ノーマルテキスト」で送信し、認証サーバーがこれに応じて確認応答を送信するためである。したがって、傍受したクライアントは送信されたデータを自由に読み取り、クライアントとサーバーの両方になりすまして相手と通信できるだけでなく、クライアントの資格情報を保存して後でサーバーになりすますこともできる。Challenge-Handshake Authentication Protocol (CHAP) は、認証フェーズ中のこの種のリプレイ攻撃に対して保護を提供する。これは、認証システムからの「チャレンジ」メッセージを使用し、クライアントが共有シークレット（たとえば、クライアントのパスワード）に基づくハッシュ計算値で応答し、認証システムがそれをチャレンジと共有シークレットの独自の計算と比較してクライアントを認証するという仕組みである。送信されていない共有シークレットに依存することに加え、認証システムによって制御されるチャレンジの繰り返し、識別子とチャレンジ値の変更などの他の機能により、CHAPはリプレイ攻撃に対する限定的な保護を提供する[8]。
リプレイ攻撃の例
リプレイ攻撃がどのように使用され、さらなる攻撃を防ぐためにどのように問題が検出され修正されたかを示す現実世界の例がいくつか存在する。
リモートキーレスシステム
路上を走る多くの車両は、ユーザーの利便性のためにリモートキーレスシステム、つまりキーフォブを使用している。現代のシステムは単純なリプレイ攻撃に対しては強化されているが、バッファリングされたリプレイ攻撃には脆弱である。この攻撃は、標的の車両の範囲内に電波を受信および送信できるデバイスを配置することによって実行される。送信機は、RF車両ロック解除信号を受信しながら妨害しようとし、後で使用するためにバッファに配置する。さらに車両をロック解除しようとすると、送信機は新しい信号を妨害してバッファリングし、古い信号を再生することで、車両より一歩先を行くローリングバッファを作成する。後で、攻撃者はこのバッファリングされたコードを使用して車両のロックを解除できる[9][10]。
テキスト依存の話者照合
さまざまなデバイスが、話者の身元を検証するために話者認識を使用している。テキストに依存するシステムでは、攻撃者はシステムによって正しく検証されたターゲット個人の音声を録音し、その録音を再度再生してシステムに検証させることができる。検証されたユーザーの保存された音声からのスペクトルビットマップを使用する対策が考案された。このシナリオでは、リプレイされた音声は異なるパターンを持つため、システムによって拒否される[11]。
IoTデバイスへの攻撃
スマートホーム環境の分野では、モノのインターネット (IoT) デバイスがリプレイ攻撃に対してますます脆弱になっている。この攻撃では、敵対者がIoTデバイスとそれに付随するアプリ間の正当な通信信号を傍受して再送する。これらの攻撃は、スマートプラグ、セキュリティカメラ、さらには家電製品など、幅広いデバイスを危険にさらす可能性がある。 最近の研究は、消費者向けIoTデバイスのかなりの部分がリプレイ攻撃を受けやすいことを実証した[12]。研究者らは、ローカル接続をサポートするテスト済みデバイスの75%が、そのような攻撃に対して脆弱であることを発見した。これらの脆弱性により、攻撃者は正当なコマンドを模倣することができ、スマートケトルをオンにする、ドアのロックを解除する、セキュリティシステムを操作するなどの不正なアクションを可能にする恐れがある。悪意のある行為者が重要なホームシステムの制御を奪う可能性があるため、このような侵害は安全性、セキュリティ、およびプライバシーに重大なリスクをもたらす。
民話において
民話『アリババと40人の盗賊』では、盗賊の頭が「開けゴマ」というパスフレーズを使用して、略奪品の保管庫のドアを開けた。これを盗み聞きしたアリババは、後でそのパスフレーズを再利用してアクセスし、運べるだけの略奪品を集めた[13]。