リプレイ攻撃

リプレイ攻撃（リピート攻撃、プレイバック攻撃とも呼ばれる）は、有効なデータ送信が悪意を持って、あるいは不正に繰り返されたり遅延されたりするネットワーク攻撃の一種である。[ 1 ]これは、攻撃元自身、あるいは攻撃者がデータを傍受して再送信することで実行される。攻撃者はIPパケットの置換によるなりすまし攻撃の一環として行われる場合もある。これは中間者攻撃の下位バージョンの一つである。リプレイ攻撃は通常、受動的な性質を持つ。

このような攻撃を別の言い方で説明すると、「異なるコンテキストからのメッセージを意図した（または元の期待された）コンテキストに再生してセキュリティプロトコルを攻撃し、正直な参加者を騙してプロトコルの実行を正常に完了したと思わせる攻撃」となります。[ 2 ]

例

リプレイ攻撃の図解。アリス（A）はハッシュ化されたパスワードをボブ（B）に送信します。イブ（E）はハッシュを盗聴し、リプレイします。

アリスがボブに自分の身元を証明したいとします。ボブは身元証明としてアリスのパスワードを要求し、アリスは忠実にそれを提供します（パスワードはハッシュ化、あるいはソルト化などの何らかの処理を経て提供される場合もあります）。一方、イヴは会話を盗聴しており、パスワード（またはハッシュ）を保管しています。やり取りが終わると、イヴ（アリスとして行動）はボブに接続します。身元証明を求められると、イヴは前回のセッションで読み取ったアリスのパスワード（またはハッシュ）を送信し、ボブはそれを承認することでイヴのアクセスを許可します。[ 2 ]

予防と対策

リプレイ攻撃は、暗号化された各コンポーネントにセッションIDとコンポーネント番号をタグ付けすることで防ぐことができます。 [ 2 ]このソリューションの組み合わせでは、相互に依存する要素は一切使用されません。相互依存性がないため、脆弱性は少なくなります。これは、プログラムの実行ごとに一意のランダムなセッションIDが生成されるためです。これにより、以前の実行を再現することがより困難になります。この場合、新しい実行ではセッションIDが変更されているため、攻撃者はリプレイを実行することができません。[ 2 ]

セッションID（セッショントークンとも呼ばれる）は、リプレイ攻撃を回避するために使用できるメカニズムの一つです。セッションIDの生成方法は以下のとおりです。

  1. ボブはアリスにワンタイムトークンを送信します。アリスはそれを使ってパスワードを変換し、結果をボブに送信します。例えば、アリスはこのトークンを使ってセッショントークンのハッシュ関数を計算し、使用するパスワードに追加します。
  2. 一方、ボブはセッション トークンを使用して同じ計算を実行します。
  3. アリスとボブの両方の値が一致する場合にのみ、ログインは成功します。
  4. ここで、攻撃者のイヴがこの値をキャプチャし、別のセッションで使用しようとしたとします。ボブは別のセッショントークンを送信します。イヴがキャプチャした値を返すと、ボブの計算結果とは異なるため、ボブはそれがアリスではないと判断できます。

セッショントークンはランダムプロセス（通常は疑似ランダムプロセス）によって選択される必要があります。そうでない場合、イヴはボブになりすまし、将来予測されるトークンを提示し、アリスにそのトークンを変換に使用させるように説得できる可能性があります。その後、イヴは後ほど（ボブが実際に予測したトークンを提示した時点で）返答を再現することができ、ボブは認証を受け入れます。

ワンタイムパスワードは、使用後または非常に短い時間で有効期限が切れるという点でセッショントークンに似ています。セッションに加えて、個々のトランザクションの認証にも使用できます。また、認証プロセス中に使用することで、通信する2者間の信頼関係を確立するのにも役立ちます。

ボブもnonceを送信できますが、その場合はメッセージ認証コード(MAC)を含める必要があり、アリスがそれをチェックする必要があります。

タイムスタンプは、リプレイ攻撃を防ぐもう一つの方法です。[ 3 ]同期は安全なプロトコルを使って実現されるべきです。例えば、ボブは自分の時計の時刻を MAC と一緒に定期的にブロードキャストします。アリスがボブにメッセージを送信したい場合、アリスはボブの時計の時刻の最良の推定値をメッセージに含め、これも認証します。ボブは、タイムスタンプが妥当な許容範囲内にあるメッセージのみを受け入れます。タイムスタンプは、ボブとアリスの両方がユニークなセッション ID を使用してお互いを認証する相互認証中にも実装され、リプレイ攻撃を防止します。[ 4 ]この方式の利点は、ボブが (疑似) 乱数を生成する必要がなく、アリスがボブに乱数を求める必要がないことです。一方向または一方向に近いネットワークでは、これは利点になります。トレードオフは、リプレイ攻撃が十分に速く、つまり「妥当な」制限内で実行された場合、成功する可能性があります。

Kerberosプロトコルの防止

Kerberos認証プロトコルには、いくつかの対策が講じられています。典型的なリプレイ攻撃では、攻撃者がメッセージを傍受し、後日リプレイすることで何らかの効果を発揮します。例えば、ある銀行がこの攻撃に対して脆弱であれば、資金移動につながるメッセージが何度もリプレイされ、当初の意図よりも多くの資金が移動される可能性があります。しかし、Microsoft Windows Active Directoryに実装されているKerberosプロトコルでは、タイムスタンプを用いた手法が採用されており、リプレイ攻撃の効果を大幅に制限しています。「TTL（Time to Live）」を過ぎたメッセージは古いものとみなされ、破棄されます。[ 5 ]

トリプルパスワード方式の採用を含む改善案も提案されています。これらの3つのパスワードは、認証サーバー、チケット交付サーバー、およびTGSで使用されます。これらのサーバーは、異なるサーバー間で秘密鍵を用いてメッセージを暗号化するためにパスワードを使用します。これらの3つの鍵による暗号化は、リプレイ攻撃の防止に役立ちます。[ 6 ]

アドホックネットワークにおける安全なルーティング

無線アドホックネットワークもリプレイ攻撃の影響を受けやすい。この場合、AODVプロトコルを拡張することで認証システムを改善し、強化することができる。アドホックネットワークのセキュリティを向上させるこの方法は、わずかなオーバーヘッドでネットワークのセキュリティを向上させることができる。[ 7 ]オーバーヘッドが大きすぎると、ネットワークの速度が低下し、パフォーマンスが低下するリスクがある。オーバーヘッドを比較的低く抑えることで、ネットワークはセキュリティを向上させながら、より高いパフォーマンスを維持することができる。

チャレンジハンドシェイク認証プロトコル

ポイントツーポイントプロトコル（PPP）を用いたクライアントによる認証とサインオンは、パスワード認証プロトコル（PAP）を用いて本人確認を行う際に、リプレイ攻撃の影響を受けやすくなります。認証を行うクライアントはユーザー名とパスワードを「通常のテキスト」で送信し、認証を行うサーバーはこれに対する確認応答を送信するためです。そのため、傍受するクライアントは送信データを自由に読み取り、クライアントとサーバーの双方を偽装することが可能です。また、クライアントの資格情報を保存しておき、後でサーバーに偽装することも可能です。チャレンジハンドシェイク認証プロトコル（CHAP）は、認証フェーズにおいてこの種のリプレイ攻撃からクライアントを保護します。認証者は「チャレンジ」メッセージを使用し、クライアントは共有秘密（クライアントのパスワードなど）に基づいてハッシュ計算された値で応答します。認証者は、このハッシュ計算された値と、自身で計算したチャレンジおよび共有秘密を比較することでクライアントを認証します。 CHAPは、送信されていない共有秘密と、認証子によって制御されるチャレンジの繰り返し、識別子とチャレンジ値の変更などの他の機能に依存することで、リプレイ攻撃に対する限定的な保護を提供します。[ 8 ]

リプレイ攻撃に対する脆弱性の実例

リプレイ攻撃がどのように使用され、さらなる攻撃を防ぐためにどのように問題が検出され修正されたかを示す実際の例がいくつかあります。

車両用リモートキーレスエントリーシステム

路上を走る多くの車両は、ユーザーの利便性のためにリモートキーレスシステム（キーフォブ）を使用しています。現代のシステムは単純なリプレイ攻撃に対しては強化されていますが、バッファリプレイ攻撃に対しては脆弱です。この攻撃は、標的の車両の範囲内に無線電波を送受信できる装置を設置することで実行されます。送信機は、RF車両ロック解除信号を受信する際にそれを妨害し、後で使用するためにバッファに格納します。さらに車両のロック解除を試みた場合、送信機は新しい信号を妨害してバッファリングし、古い信号を再生することで、車両より一歩先を行くローリングバッファを作成します。後ほど、攻撃者はこのバッファリングされたコードを使用して車両のロックを解除する可能性があります。[ 9 ] [ 10 ]

テキスト依存型話者検証

様々なデバイスが話者認識を用いて話者の身元を検証しています。テキスト依存型のシステムでは、攻撃者はシステムによって正しく認証された対象者の発話を録音し、その録音を再度再生してシステムによって認証することができます。認証済みのユーザーの保存された発話からスペクトルビットマップを取得する対抗策が考案されました。このシナリオでは、再生された発話は異なるパターンを示すため、システムによって拒否されます。[ 11 ]

IoTデバイスへのリプレイ攻撃

スマートホーム環境の分野では、モノのインターネット(IoT) デバイスがリプレイ攻撃に対してますます脆弱になっています。リプレイ攻撃では、攻撃者が IoT デバイスとそのコンパニオン アプリ間の正当な通信信号を傍受して再生します。これらの攻撃によって、スマート プラグ、セキュリティ カメラ、さらには家電製品など、さまざまなデバイスが侵害される可能性があります。最近の調査[ 12 ]では、消費者向け IoT デバイスのかなりの部分がリプレイ攻撃を受けやすいことが実証されています。研究者らは、テストされたローカル接続をサポートするデバイスの 75% がこのような攻撃に対して脆弱であることを発見しました。これらの脆弱性により、攻撃者は正当なコマンドを模倣し、スマート ケトルをオンにする、ドアのロックを解除する、セキュリティ システムを操作するなどの不正なアクションを実行できる可能性があります。このような侵害は、悪意のある人物が重要なホーム システムを制御できるため、安全性、セキュリティ、プライバシーに重大なリスクをもたらします。

民話『アリババと40人の盗賊』では、盗賊団の頭領が盗品庫の扉を開ける際に「開けろ、ゴマ」という合言葉を使った。これを偶然耳にしたアリババは、後にこの合言葉を再利用して扉を開け、持ち運べる限りの盗品を奪い取った。[ 13 ]

参照

参考文献

  1. ^ a b El Abbadi, Reda; Jamouli, Hicham (2021-01-25). Moreno-Valenzuela, Javier (編). 「リプレイ攻撃にさらされた非線形ネットワークシステムのための高木–菅野ファジー制御」 . Mathematical Problems in Engineering . 2021 : 1– 13. doi : 10.1155/2021/6618105 . ISSN  1563-5147 .
  2. ^ a b c d Malladi, Sreekanth. 「セキュリティプロトコルに対するリプレイ攻撃の防止について」（PDF） . oai.dtic.mil . 2022年1月20日時点のオリジナルよりアーカイブ（PDF） 。
  3. ^ Ferrara, Pietro; Mandal, Amit Kr; Cortesi, Agostino; Spoto, Fausto (2020-11-24). 「IoTの脆弱性を発見するための静的解析」 . International Journal on Software Tools for Technology Transfer . 23 (1): 71– 88. doi : 10.1007/s10009-020-00592-x . hdl : 10278/3734701 . ISSN 1433-2779 . 
  4. ^ Dewanta、Favian、Masahiro Mambo。2019年。「車両ネットワーク環境における安全なフォグコンピューティングサービスのハンドオーバーのための相互認証スキーム」IEEE Access 7:103095–114。
  5. ^ Olsen, Geir (2012年2月1日). 「Kerberos認証101：Kerberosセキュリティプロトコルの基本を理解する」 . Redmond Magazine . 2017年6月13日閲覧。
  6. ^ Dua, Gagan (2013). 「トリプルパスワードを用いたKerberos認証プロトコルにおけるリプレイ攻撃防止」. International Journal of Computer Networks & Communications . 5 (2): 59– 70. arXiv : 1304.3550 . doi : 10.5121/ijcnc.2013.5205 . S2CID 9715110 . 
  7. ^ジェン、ジェーン (2003). 「アドホックネットワークにおけるセキュアルーティングのためのリプレイ攻撃防止」.アドホック、モバイル、ワイヤレスネットワーク. コンピュータサイエンス講義ノート. 第2865巻. pp.  140– 150. doi : 10.1007/978-3-540-39611-6_13 . ISBN 978-3-540-20260-8。
  8. ^ Simpson, William Allen (1996). 「RFC 1994 – PPPチャレンジハンドシェイク認証プロトコル（CHAP）」 . tools.ietf.org . doi : 10.17487/RFC1994 . 2018年9月12日閲覧。
  9. ^ Beek, S. van de; Leferink, F. (2016年8月1日). 「リモートキーレスエントリーシステムのパルス電磁干渉に対する脆弱性と改善策」 . IEEE Transactions on Electromagnetic Compatibility . 58 (4): 1259– 1265. doi : 10.1109/TEMC.2016.2570303 . S2CID 39429975 . 
  10. ^フランシロン、オーレリアン. 「現代の自動車におけるパッシブキーレスエントリーおよびスタートシステムへの攻撃」(PDF) . eprint.iacr.org/ . 2016年12月8日閲覧。
  11. ^ Wu, Z.; Gao, S.; Cling, ES; Li, H. (2014年12月1日).信号情報処理協会年次サミット・会議 (APSIPA), 2014 アジア太平洋. pp.  1– 5. doi : 10.1109/APSIPA.2014.7041636 . ISBN 978-6-1636-1823-8. S2CID  10057260 .
  12. ^ Lazzaro, Sara; De Angelis, Vincenzo; Mandalari, Anna Maria; Buccafurri, Francesco (2024). 「あなたのケトルはハッカーより賢いのか？ 消費者向けIoTデバイスにおけるリプレイ攻撃の脆弱性を評価するためのスケーラブルなツール」2024 IEEE International Conference on Pervasive Computing and Communications (PerCom) . pp.  114– 124. arXiv : 2401.12184 . doi : 10.1109/PerCom59722.2024.10494466 .{{cite conference}}: CS1 maint: 複数の名前: 著者リスト (リンク)
  13. ^アリババと40人の盗賊（Bartleby.comの電子テキスト）
「 https://en.wikipedia.org/w/index.php?title=Replay_attack&oldid=1330615116」より取得