暗号化されたチャネルを介した中間者攻撃
私は中間者攻撃について最近知り、この質問を思いつきました。
ネットワークを介して通信しようとする2台のコンピューターがあるとします。各コンピューターには、暗号化機能と復号化機能があります。また、2台のコンピューターで使用されている暗号が解読不能であり、コンピューターが事前共有キーを使用していると仮定します。
たとえば、あるコンピュータから別のコンピュータにパケットを送信する場合、最初のコンピュータの暗号化機能によって最初に暗号化され、次に他のコンピュータの暗号化解除機能によって復号化されます。
ここで中間者攻撃は可能ですか？もしそうなら、どうすればそれを行うことができますか？データが両側で暗号化されているという事実を考慮してください。
この場合、どのようにして自分自身を守ることができますか？この通信を介して他の方法でパケットを傍受することは可能ですか？
用語：a secure channel は、中間者攻撃や盗聴から保護されている通信チャネルです。暗号化だけでは安全なチャネルは作成されません。安全なチャネルを確立する簡単な方法は SSL/TLS を使用することです。しかし微妙です。
トラフィックの暗号化は、中間者攻撃に対する保護の一部にすぎません。これにより、攻撃者は復号化キーを知らないため、トラフィックをデコードできなくなります。また、暗号化キーがわからないため、攻撃者が任意のトラフィックを注入することも防止できます。
暗号化のみの場合、中間者は何らかの暗号文を作成することでsomeトラフィックを注入できます。彼は平文が何であるかを知らないかもしれませんが、それでも問題を引き起こす可能性があります—受信者は文字化けしたデータを受け取り、それがパーサーのバグをトリガーすることさえあります。安全なチャネルは、暗号化だけでなく認証も提供します。これは、データが正当なソースからのものであることの確認です。
通信プロトコルがパケットに基づいている場合、各パケットには、誰がそれを送信したかを示すタグ（攻撃者が一方の当事者からそれ自体にトラフィックを送り返せないようにするため）と、ある種のシーケンス番号（攻撃者が攻撃できるようにするため）が必要です古いパケットを再送信します。これにより、効果が異なる場合があります）。
もちろん、攻撃者がリッスンとインジェクトに加えてトラフィックを抑制できる場合、攻撃者は完全に遮断し、パケットを並べ替えるなどして通信を妨害することができます。シーケンスを適切に使用することにより、パケットの並べ替えを検出（およびパケットの並べ替えまたは破棄）できます。通信を認証するための番号（これは、個々のパケットを認証するよりも強力です）。パケットを削除できる場合でも、攻撃者が暗号化を行っても、すべてのトラフィックをブロックする能力は失われません。物理的な手段が必要です。武装した宅配便、敵の妨害装置よりも強力な無線送信機、…
暗号化によって、通信の機密性が保証されるとは限りません。通信は サイドチャネル を許可します。特に、パケットのサイズとタイミングが明らかになる場合があります。例えば：
- 1944年6月5日、BBCが突然コード化されたメッセージを大量に送信した場合、メッセージがデコード不可能であったとしても、何かが進行中であったことを示していました。対処法：コード化されたメッセージを常に送信し、送信するものがない場合は、有用なメッセージと区別がつかないランダムなメッセージを送信します。
- メッセージのサイズは指示であるかもしれません。たとえば、軍事命令がmcouzjooybではなくrnpwbhmに送信された場合、ランクを復号化できなかったとしても、中尉ではなく船長を関与させるためにスコープが十分に重要であることがわかります。対処法：関連する概念には固定長コードを使用してください。二重に、潜在的に認識可能な用語の長さをランダムに変化させます（たとえば、固有名詞の異なるスペルを通じて、またはより体系的にランダムな長さのゴミを追加します）。 （私がここで引用する攻撃と救済策はどちらも第二次世界大戦の歴史からのものですが、手元に参照はありません。）
- 音声トラフィックは通常、圧縮されてリアルタイムで送信されるため、 再構築 に対して特に脆弱です。パケットのリズムだけでも、実験室の状況で音声を再現するのに十分な場合があります。対処法：より少ない圧縮でより多くの遅延を受け入れます。たとえば、Nミリ秒ごとに固定サイズのパケットを送信します。
中間者攻撃からの保護に関するもう1つの問題は、通信の開始です。事前共有キーを使用する場合、これは問題ではありませんが、2つのパーティが事前にお互いを知らない場合、攻撃者は直接的な中間者になる可能性があります。アリスがボブとチャネルを確立しようとすると、イブはすべてのパケットを傍受し、アリスに彼女とのチャネルを確立させ、次にボブとのチャネルを確立し、好きなようにトラフィックを中継します。これが、SSLが証明書の検証を必要とする理由です。クライアントは、設定しているチャネルが目的のサーバーに対するものであることを検証します（オプションで、サーバーが対称検証を実行します）。