リプレイ攻撃

読み：りぷれいこうげき　／　英語表記：Replay Attack

• セキュリティ

正規の通信で送られたデータを盗聴などで入手し、後でそのまま再送することで、正規の利用者になりすましたり同じ処理を繰り返させたりする攻撃である。データを解読しなくても成立するため、使い捨ての値や時刻などを使ってデータの鮮度を確かめることで防ぐ。

イマシルちゃんの解説

リプレイ攻撃は、正規の通信を記録して送り直し、本人になりすましたり同じ処理を繰り返させたりする攻撃だよ。
たとえば送金の指示を受け取る側が再送だと見抜けなければ、同じ送金が二度行われるおそれがあるんだ。
暗号化されていても、攻撃者は中身を解読せずにデータを使い回せる場合があるよ。
対策の一つは、認証のたびに使い捨ての値「ナンス」を渡し、秘密の情報とその値から計算した応答を求めることなんだ。
受け取る側は応答が正しく作られたかと今回の値を使っているかを確認し、使用済みの値も拒否するよ。
値を付けるだけでなく、受け取る側が確かめるところまでが大切なんだ。

より深い解説

定義と位置付け

リプレイ攻撃は、過去に送られた正規のデータを記録しておき、後で送り直して受信者をだます攻撃である。攻撃者は暗号を解いたりデータを書き換えたりする必要がない。正規の送信者が作った本物のデータをそのまま使うため、暗号化や改ざん検知だけでは見破れない点に特徴がある。

情報セキュリティの三要素で考えると、盗聴は機密性を、改ざんはデータの正しさを脅かす。リプレイ攻撃は、データそのものは正しいまま「いつ、何回送られたか」という性質を悪用する。そのため、機密性やデータの正しさを守る仕組みとは別に、データが新しいことと一度しか受け付けないことを確かめる仕組みが必要になる。

認証の分野では、NISTのデジタル認証ガイドラインが、認証のやり取りを記録して再送しても認証に成功しない性質をリプレイ耐性として求めている（NIST SP 800-63B）。

攻撃の流れ

リプレイ攻撃は、次のような段階で進む。

1. 攻撃者が、正規の利用者とサーバの間の通信を盗聴して、認証や処理要求のデータを記録する。
2. 攻撃者は、そのデータの意味を理解できなくても、そのまま保存しておく。
3. 攻撃者が後で、記録したデータをサーバへ送る。
4. サーバがそのデータを正規のものとして受け付けると、攻撃者は利用者になりすませる。または、処理が二度実行される。

例えば、パスワードをハッシュ化して送るだけの認証方式を考える。パスワードそのものは通信に現れないが、ハッシュ値は毎回同じになる。攻撃者はハッシュ値を記録して送り直すだけで、パスワードを知らなくても認証に成功してしまう。パスワードを平文で送るPAPは、さらに盗聴そのものにも弱い。

暗号化や改ざん検知だけでは防げない理由

暗号化はデータの中身を読ませない仕組みであり、メッセージ認証符号（MAC）は、データが改ざんされていないことと、鍵を持つ相手が作ったことを確かめる仕組みである。どちらもデータの完全性や機密性を守るが、同じデータが二度届いたことは区別できない。

共通鍵を使ってMACを付けた送金指示を例に考える。攻撃者が送金指示とMACの組を記録して再送しても、データは改ざんされていないため、受信者のMACの検証は成功する。MACの検証が成功したという事実だけでは、その指示が今回送られたものか、以前の記録を送り直したものかは判断できない。

したがって、メッセージの複製や再送を検知するには、MACで保護する範囲に、毎回変わる値を含める必要がある。毎回変わる値がMACで保護されていれば、攻撃者がその値を書き換えると検証に失敗し、書き換えなければ古いデータだと判定できる。

主な対策

リプレイ攻撃への対策は、どれもデータに「一度だけ有効な情報」を組み込み、受信者がそれを確かめるという考え方に基づく。

一度だけ使う値をナンスと呼ぶ。サーバがこの値を問いかけとして送り、クライアントが秘密の情報とこの値から計算した結果を応答として返す方式をチャレンジレスポンス認証という。問いかけの値は毎回変わるため、以前の応答を記録して送り直しても、今回の問いかけに対する正しい応答にはならない。

タイムスタンプ方式は、サーバから値を受け取る往復が不要になる。その代わり、送受信者の時計が大きくずれていると正規のデータも拒否してしまう。また、許容する時間差の範囲内であれば、記録したデータを素早く再送する攻撃は時刻の確認だけでは防げない。そのため、一定時間内に受け取ったデータを記録しておき、同じデータを拒否する仕組みと組み合わせる。

ワンタイムパスワードのうち、時刻をもとに値を計算する方式（TOTP）では、値は一定の時間間隔で変わる。RFC 6238では、この時間間隔の既定値として30秒を推奨している。同じ時間間隔の中では同じ値が有効になるため、検証側は使用済みの値を拒否する必要がある。

プロトコルでの実装例

リプレイ攻撃への対策は、多くのセキュリティプロトコルに組み込まれている。

Kerberosでは、クライアントとサーバの時計のずれを一定の範囲に収める必要がある。MIT Kerberosでは許容する時刻差の既定値が300秒（5分）であり、この範囲を超えると正規の利用者も認証に失敗する。詳しい仕組みはKerberosの記事で扱う。

TLSでは、ハンドシェイクのたびにクライアントとサーバが生成した乱数を鍵の計算に使う。そのため、以前のセッションのデータを別のセッションへ送り込んでも復号や検証に失敗する。また、同じセッション内でも各レコードに暗黙の通し番号を割り当てて保護するため、レコードの再送や並べ替えを検出できる。

IPsecで重複パケットを拒否する仕組み

IPsecのESPとAHでは、送信者がパケットごとに1ずつ増えるシーケンス番号を付ける。受信者は受け取った番号を記録し、同じ番号のパケットを拒否する。この機能をアンチリプレイという。

ただし、ネットワークでは経路の違いやQoSの優先制御によって、パケットの到着順が入れ替わることがある。そのため受信者は、受け取った最大の番号から一定の幅の範囲で、まだ受け取っていない番号を受け付ける。この幅をリプレイ防止用のウィンドウと呼ぶ。RFC 4303では、ウィンドウの幅として最低32を実装すべきとし、既定値として64を推奨している。

次は、ウィンドウの幅を64とした独自の計算例である。受信済みの最大のシーケンス番号を1,000とする。

ウィンドウの下端 ＝ 最大の番号 − ウィンドウ幅 ＋ 1 ＝ 1,000 − 64 ＋ 1 ＝ 937

受信者の判定は次のようになる。

1,005を受け付けた後のウィンドウの下端は、1,005 − 64 ＋ 1 ＝ 942になる。この仕組みにより、到着順の入替えは一定の範囲で許しながら、同じパケットの再送は拒否できる。

似た攻撃との区別

リプレイ攻撃は、なりすましを目的とする他の攻撃と混同されやすい。攻撃者が通信のどこに、いつ介入するかで区別する。

中間者攻撃やリレー攻撃は、実時間の中継なので、ナンスによる対策だけでは防げない場合がある。正規のチャレンジをそのまま正規の利用者へ中継し、返ってきたレスポンスを使えるためである。これらには、サーバとクライアントが互いの証明書を確認するTLSの相互認証や、通信にかかる時間を測る対策を組み合わせる。

設計と障害対応の観点

リプレイ対策は、正しく動いていても正規の通信を拒否することがある。障害の切り分けでは、この対策が原因になっていないかも確かめる。

アプリケーションの設計でも同じ考え方が必要になる。ネットワークの再送やクライアントの再試行で同じ要求が二度届くことは珍しくない。決済などの処理では、要求ごとに一意な番号を付け、処理済みの番号を受け付けないようにする。

TLS 1.3には、再接続時の最初の送信で、ハンドシェイクの完了を待たずにデータを送れる0-RTTという機能がある。RFC 8446は、この方式で送るデータはリプレイ攻撃から保護されないと明記している。そのため、この方式では何度実行しても結果が変わらないべき等な要求だけを送るように設計する。

午後での問われ方

• 認証方式の手順を示し、盗聴したデータを再送されたときに認証が成功してしまう理由を説明させる。
• チャレンジレスポンス認証やタイムスタンプがリプレイ攻撃を防げる理由を、やり取りの内容に基づいて記述させる。
• Kerberosや時刻ベースのワンタイムパスワードで時刻同期が必要な理由を答えさせる。
• IPsecのシーケンス番号の役割や、パケットの順序の入替えとアンチリプレイ機能の関係を問う。
• メッセージ認証符号で検知できることとできないことを区別させる。

実際の試験ではここに出る！全1問

ネットワークスペシャリスト

午前Ⅱ

• H27秋 問16

この用語が出てくる記事

• IPsec
• ESP
• AH
• OSPF認証
• SAML
• WPA2
• CHAP
• TLS
• DTLS
• PAP