セキュアコンパニオンICを使用したTLS実装の保護

要約

このアプリケーションノートでは、TLS実装のセキュリティ上の課題について説明し、TLS実装をセキュアコンパニオンICによりセキュリティ侵害から保護する方法について検討します。

はじめに

多数のコネクテッドスマート機器とクラウドの間で収集され、共有される機密データを保護することは、かつてないほど重要になっています。産業用センサー、家庭用電化製品、ウェアラブル医療機器などは、いずれも漏洩すれば重大な事態を招く恐れがあるデータを利用します。

トランスポートレイヤセキュリティ(TLS)プロトコルは、かつてはセキュアソケットレイヤ(SSL)と呼ばれていましたが、伝送データの保護に最もよく利用されるプロトコルです。TLSプロトコルは当初、インターネット上でコンピュータとウェブサイトとのセキュアな双方向通信を実現するために開発されましたが、今では伝送データの盗聴や改ざんを防止することで、インターネット上のIoT機器の通信のセキュリティを確保する上でも極めて重要な役割を果たしています。このプロトコルは非常によく研究されており、実際に攻撃も受け、修正が加えられているため、強固であると考えられ、広く採用されています。デバイス側でTLSプロトコルの信頼性が確保されるためには、流出や改ざんの許されない秘密鍵、プライベート鍵、および証明書が機器内に保管され、プロトコルの実行過程で使用される必要があります。しかし、IoT機器は開かれた環境で運用されるため、それらのセキュリティ資産が侵襲攻撃や非侵襲攻撃を試みる攻撃者に漏洩する可能性があります。侵襲攻撃では、サイバー攻撃者が機器の筐体を開いて、メモリ内容の改ざん、ファームウェアの置き換え、PCBトレースの信号解析などを行います。非侵襲攻撃は通常、通信ポート経由で実行され、機器のファームウェアに存在する論理的バグを標的にします。セキュアICの補助なしでは、TLS実装の保護は不可能になります。

このアプリケーションノートでは、機器のアプリケーションプロセッサに対する負荷を軽減しつつ、コネクテッドエンベデッドシステムでのTLS実装のセキュリティを確保するための、低コストで難易度の低いソリューションについて説明します。

概要：TLSプロトコル

TLSはクライアントとサーバの間で実行されます。このアプリケーションノートでは、｢クライアント｣とはエンベデッドシステム(IoT機器など)であり、｢サーバ｣とは、インターネットを使用してアクセス可能なクラウド内のリモート機器ですⁱ。

そうした前提で、センサーとアクチュエータを備えた｢クライアント｣機器が、｢サーバ｣の提供するウェブサービスに接続されている場合を考えてみましょう。このシナリオ上で、ユーザーはスマートフォンを使用し、サーバ経由でセンサーデータの表示や機器へのコマンド送信を実行することができます。クライアント機器はTLSを使用してデータをレポートしたり、サーバとコマンドをやり取りしたりします。

TLSプロトコルでは、主に次の2つのフェーズがあります。

確立(ハンドシェイク)
セキュア通信(認証と暗号化を伴うアプリケーションデータのセキュアな伝送)

確立(ハンドシェイク)フェーズ

ハンドシェイクフェーズは、セキュア通信のコンフィギュレーションについてネゴシエーションを行う段階です。このフェーズでは、サーバおよびクライアントの認証や共有秘密鍵の計算などが行われます。このフェーズは、次のような4つのステップで進行します。

暗号スイートに関するアグリーメント。暗号スイートは、後続のフェーズで使用される暗号アルゴリズムの集合です。サーバとクライアントは、共有秘密鍵のネゴシエーションやアプリケーション通信のセキュリティ保護のために、どの暗号プロトコルセットを使用するかを決定します。
クライアントによるサーバの認証。このフェーズでは、クライアントはランダムなバイト列で構成されるメッセージをサーバに送信します。応答として、サーバは自らの証明書を、受け取ったランダムメッセージにサーバのプライベート鍵を使用して計算したデジタル署名とともにクライアントに返信します。その後、クライアントはサーバの証明書の有効性を確認した上で、この証明書を使用して、ランダムメッセージのデジタル署名を検証します。
サーバによるクライアントの認証(オプション)。このステップはエンベデッドシステムに有用であり、ステップ2と同じプロセスで実行されます。ウェブサイトの一般的な運用では、スタンドアロンのクライアント機器は、サーバとの認証に“パスワード入力”をすることができません。TLSハンドシェイクでは、クライアントのプライベート鍵を使用したデジタル署名による身元証明をクライアントに要求するオプションによって、この問題に対処します(ステップ2のサーバ認証の場合とまったく同じ方式に従います)。
共有通信秘密鍵(AESキーなど)のネゴシエーション。セキュア通信フェーズのためのやり取りです。このステップでは、パブリック鍵(公開鍵)に基づく複雑な鍵交換プロトコル(ECDHEなど)を使用して秘密鍵を交換します。これらのプロトコルでは、クライアント側とサーバ側の両方で同じ秘密鍵(対称鍵)を計算可能であり、秘密鍵を実際に送信する必要はありません。鍵交換で得られた秘密鍵は、その後、次のフェーズでサーバとクライアントがやり取りするメッセージの暗号化や署名に使用されます。これらの秘密鍵は、いわゆる対称暗号方式で使用されます(AESを使用したアルゴリズムに基づき、サーバ側、クライアント側両方で、暗号化と復号、または署名や検証に同一の鍵が使用されます)。メモリ使用量の低減や高速性が求められる場合は、対称暗号方式の利用が必要です。AESに比べて、RSAまたはECパブリック鍵(公開鍵)に基づくアルゴリズムは極めて低速な場合や、リソースが足りない場合があります。しかし、秘密鍵を配信してセキュア通信を実現するには、RSAまたはECに基づくアルゴリズムを使用した、複雑な鍵ネゴシエーションフェーズが必要です。

事前共有(秘密)鍵交換アルゴリズムは、パブリック鍵(公開鍵)に基づく鍵交換アルゴリズムの代替策となります。この方式では、サーバと機器の両方に同一の秘密鍵を格納した上で、機器を現場に設置します。このオプションでは、RSAまたはEC暗号方式を実装する負担がなくなりますが、機器とサーバの両方で長期にわたり同一の秘密鍵を保管する必要があります。しかし、この方式はリスクを伴います。すべてのコネクテッド機器が同一の鍵を共有する場合、1つの秘密鍵が漏洩するだけでネットワーク全体が脆弱化するからです。

セキュア通信フェーズ

上記のプロセスを使用して共有通信秘密鍵が交換されたら、セキュアな通信チャネルが確立されます。通信を行う二者は、アプリケーションレベルのデータ(HTTP要求/応答など)の交換を開始することができます。TLSプロトコル層は自動的に送信パケットの暗号化と署名を行い、受信側では受信パケットの復号化と検証を行います。その際には、暗号化にAES-CBC、署名にAES-CMAC、暗号化と署名の同時処理にはさらに新しい方式のAES-CCMなど、秘密鍵に基づくアルゴリズムを使用します。着信メッセージが破損していた場合、TLSプロトコル層はエラーを返します。

通信が終了した後、共有通信鍵(セッション鍵)は廃棄されます。

TLSの短所

ソフトウェアの観点から見ると、TLSプロトコルはすぐに使えるソフトウェアライブラリ(mbedTLS、https://tls.mbed.orgなど)を使用して、任意のアプリケーションに簡単に組み込むことができます。そうしたライブラリのソフトウェア統合は容易だと思われます。結局のところ、インターネット上でTCP/IPプロトコルを使用して通信する際、アプリケーションではPOSIXソケットAPIの｢connect｣、｢read｣、および｢write｣関数をよく使用します。TLSを使用するためにmbedTLSライブラリを用いる場合は、アプリケーションはそれらの関数呼び出しを、｢mbedtls_net_connect｣、｢mbedtls_ssl_read｣、｢mbedtls_ssl_write｣にリダイレクトする必要があるだけです。アプリケーションのソースコードには、TLSの主要フェーズを実装するコードをすべて含める必要はありません。｢mbedtls_net_connect｣は、認証と鍵のネゴシエーションを自動的に実行します。｢mbedtls_ssl_read｣と｢mbedtls_ssl_write｣は、着信および送出、双方のアプリケーションデータ転送(HTTP要求/応答など)に対し、TLS保護(暗号化と署名)を自動的に追加します。

図1. この図はTLS実装の概要を示しています。詳細については、https://tls.mbed.org/kb/how-to/mbedtls-tutorialを参照してください。

実に簡単と思われるかもしれませんが、TLSライブラリをアプリケーションやそのコンフィギュレーション(サーバ上のコンフィギュレーションを含む)に組み込むことには、不利な点もいくつかあります。バグのないTLSスタック(https://project-everest.github.io参照)を使用した場合でも、TLSライブラリをソフトウェアに組み込んで使用する際に欠陥を伴う可能性があります(https://www.mitls.org/pages/attacks参照)。

このアプリケーションノートの以下のセクションでは、クライアント側(エンベデッド機器など)におけるTLS統合の一般的な弱点について検討します。

証明書検証の欠落

アプリケーションによるTLSライブラリの使用で最もよく見られる問題の1つは、証明書の検証に関係したものです。

サーバ証明書の検証を実施するのはアプリケーションの役割であるため、TLSライブラリでこれを自動的に行うことはあまりありません。TLSライブラリから、証明書の検証を明示的に要求する必要があります。しかし、この根本的な検証ステップが欠落すれば、その通信は｢中間者｣攻撃にさらされる恐れがあります。

図2. 中間者攻撃ⁱⁱ

ネットワークトラフィックが目的のサーバでないコンピュータへと導かれたとしましょう。ピア証明書を検証しないため、クライアントは攻撃者との間で安全と誤認されたTLSチャネルを確立します。こうなるとTLSプロトコルは役に立たなくなるばかりか、セキュリティが保たれているという誤った印象を与えることになります。

脆弱な暗号スイート

TLSの機能不全は、サーバのコンフィギュレーションから生じる場合もあります。たとえば、サーバが脆弱な暗号スイートを受け入れるように構成されている場合です。脆弱な暗号スイートでは、通常、非常に脆弱なため最新型の攻撃に持ちこたえられないような、非推奨または廃止済みの暗号アルゴリズム(RC4など)が利用されています。通常、TLSネゴシエーションフェーズでは、クライアントとサーバの両方でサポートされている、セキュリティの観点から見て最も強力なプロトコル構成を利用します。ただし、サーバが旧式の暗号アルゴリズムをサポートしている場合は、攻撃者がサーバとクライアント間のやり取りのセキュリティレベルを引き下げ、交換データへのアクセス権を取得する恐れがあります。また、一部のアルゴリズムは前方秘匿性を備えているため、秘密鍵やパスワードが将来漏洩しても過去のセッションが保護されます。一時的なDiffie-Hellman (DHE)または楕円曲線暗号(ECDHE)を使用する暗号スイートは、完全前方秘匿性を備えています。サーバでは、こうした暗号スイートを実装する必要があります。完全前方秘匿性を備えていないオプションもあります。暗号スイートの詳細については、下記のページを参照してください。https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices.

脆弱な認証局証明書

サーバの証明書の効果的な検証は、中間者攻撃に対抗する上で不可欠です。サーバの証明書の検証は、エンベデッドシステム内に保管したルート証明書によって行われます。ルート証明書はエンベデッド機器の製造時に格納されるのが普通で、機器およびサーバ証明書の発行元であり、その完全性を保証する認証局に属するものです。このルート証明書が機器の長期メモリ内で不正なものと差し替えられた場合は、セキュリティ侵害の犠牲となる可能性があります。そうした事態が起きると、悪意を持ってクライアント機器に格納された不正なルート証明書によって攻撃者のサーバの証明書が正しく検証されるため、その不正なサーバが有効なサーバとして認証される恐れがあります。このシナリオでは、ある種の中間者攻撃も必要になります。しかし、それを実行するのは難しくはありません。

セッションキーの漏洩

セッションキーは、短期間だけ使用される、セキュリティ対策の切り札です。その有効性は、TLSのセキュア通信チャネルと同じ時間だけ保たれます。ある一組のセッションキーを使用して、別の一組のセッションキーを推測することはできません。ただし、これらのキーが漏洩した場合は、記録された過去のセッションであるか、現在実行中のセッションであるかにかかわらず、なおTLSセッション全体の脆弱化につながります。

クライアント認証鍵の漏洩

TLSネゴシエーションフェーズは、クライアントがサーバに認証されるステップを含む場合があります。クライアントでサーバ認証用のプライベート鍵が漏洩すれば、攻撃者がその鍵を再利用してクライアントになりすます恐れがあります。

脆弱な暗号実装や低品質の乱数

機器の長期メモリがダンプされた場合、この鍵は直接に漏洩すると考えられます。また、使用中の暗号アルゴリズムが(機能的には正常でも)サイドチャネル攻撃に耐えられないために、間接的な漏洩が発生する場合もあります。サイドチャネル攻撃では、機器がプライベートまたは秘密鍵の関わる暗号アルゴリズムを実行する際にその機器のタイミング、消費電力、電磁放射などを測定することにより、攻撃者がそうした鍵を推測することができます。

よりセキュアなクライアント側TLS実装の実現

真にセキュアなTLS方式を維持するとともに、このアプリケーションノートで説明している落とし穴を避けるには、次のような、最低限従うべき一連のルールがあります。

CA証明書は真に変更不可能である必要があります。ルート証明書を置き換えることができるのは、機器のメーカーまたはオペレータのみであることが必要です。そこで問題となるのは、ルート証明書を保管するメモリへのアクセスを保護することです。エンベデッドシステムのアプリケーションプロセッサにソフトウェアを注入することができれば、そのメモリを変更可能だからです。
中間者攻撃を防ぐため、サーバ証明書はクライアントによって常にチェックする必要があります。
クライアントのプライベート認証鍵は安全に保管する必要があります。
セキュアな暗号アルゴリズム実装を使用し、サイドチャネル解析にも対抗可能である必要があります。
TLSライブラリについては、安全に機能させるため、アプリケーションに正しく組み込んで構成する必要があります。

セキュアコンパニオンICでTLS実装を保護する方法

クライアント側のTLSハンドシェイクフェーズには、次の長期セキュリティ資産が関与します。

サーバの証明書
認証局の証明書(ルート証明書の1つ)
クライアントのプライベート鍵(使用される場合)
事前共有鍵(使用される場合)

MAXQ1061のようなセキュアICを使用すれば、上記の脆弱性を設計上防止することにより、アプリケーションプロセッサの負荷を増やすことなく、TLS実装を保護することができます。

MAXQ1061は、内蔵の不揮発性メモリ内にCAのルート証明書を保管します。これらの証明書は、正しいパブリック鍵(公開鍵)に基づく強力な認証によってのみ置き換え可能です。通常、リモート管理者がこの強力な認証を実行でき、この管理者だけが、MAXQ1061へのアクセスを有効にするためのプライベート鍵の所有者となります。
MAXQ1061はTLSハンドシェイクフェーズを管理し、次のことを常に保証します。
- 中間者攻撃は防止されます。サーバ証明書は使用前に必ず検証されます。MAXQ1061は、恣意的なパブリック鍵(公開鍵)または証明書を将来の署名の検証に使用することを拒否します。こうしたパブリック鍵(公開鍵)は、使用前に、MAXQ1061内にすでに存在している有効な証明書を使用して署名される必要があります。
- これらは最先端の暗号方式(高品質の乱数、サイドチャネル漏洩防止)を使用して計算されるため、セッションキーが漏洩することはありません。
- クライアント認証はMAXQ1061の長期メモリ内に保管されたプライベート鍵を使用して実行されるため、クライアントになりすますことはできません。これらの鍵は、常に高品質の乱数発生器を使用して内部生成されます。この鍵をICから取り出すことは設計上、不可能です。
- 脆弱な暗号スイートは使用することができません。利用可能なのは、ECDHE-ECDSAとAES-CCM、またはAES-GCMとSHA-256以上の暗号スイートだけです。
MAXQ1061でクライアント認証が可能なのは、セキュアブートが成功した時だけです。アプリケーションプロセッサのファームウェアおよびコンフィギュレーションの検証が成功しない限り、このセキュアICは認証プライベート鍵を使用不能にすることができます。この手法により、クライアント機器は改ざんがない場合にのみ、真のクライアントとして認証可能となります。さらに、MAXQ1061を内蔵した機器は複製することができません。このセキュアICは一意のプライベート鍵を内蔵しているため、偽造することは不可能です。

mbedTLSに微修正を加えたマキシムが提供するTLSスタックを使用すれば、アプリケーションプロセッサで、設計を大幅に見直すことなくセキュリティレベルを引き上げるMAXQ1061の上記機能の活用を容易にします。この変更を加えたmbedTLSスタックでは、セッションキーの交換、サーバ証明書の検証、およびクライアントの認証にMAXQ1061を活用します。セキュア通信そのものは、MAXQ1061自体、またはメインアプリケーションプロセッサによって実行することができます。

以上の説明は、サーバ側におけるいかなる脆弱性の存在も排除しません。セキュリティ対策を実施してサーバのプライベート鍵と一連の証明書を保護することが必須であることは言うまでもありません。

結論

エンベデッドシステムのセキュリティを確保するには、強固なソフトウェアコーディングを行い、(物理的および論理的に)システムの開口部を封鎖する必要があります。攻撃者を過小評価しないことも有益です。

認証用のプライベート鍵などの長期的な機密データや証明書などの死活的に重要なデータは、セキュアIC内に保管する方がはるかに安全で簡単です。もう1つの方法はこれらの資産を共通のアプリケーションプロセッサ内に保管することですが、こうしたプロセッサは設計上、メモリ内容全体へのアクセスを提供する多くのデバッグ機能を備えているのが普通です。セキュアICをアプリケーションプロセッサとともに使用することのもう1つの利点は、それら2つのICが互いに物理的に隔てられるため、アプリケーションプロセッサのソフトウェアに脆弱性が存在しても、セキュアIC内に保管された資産が危険にさらされることはないという点です。

ⁱパブリック鍵(公開鍵)に基づくデジタル署名の基礎

｢送信者｣がメッセージMを｢受信者｣に送信するというシナリオを考えます。この場合、Mは一連のバイトです。受信者は、このメッセージが真の送信者から変更なく届くようにしたいと考えています。

次のシーケンスでは、｢送信者｣と｢受信者｣とのメッセージ交換を考えます。受信者側では、各種項目の名称の末尾に｢_r｣(｢received｣の意味)を付けます。これは伝送エラーや攻撃者による値の改ざんのため、送信者側と同じでない場合があるからです。送信者側では、すべての項目名の末尾に｢_t｣(｢transmitted｣の意味)を付けます。

署名と署名の検証

送信者側では、次のようにメッセージM_tが送信用に作成されます。

メッセージM_tは、まずSHA-256のような一方向セキュアハッシュ関数を使用してハッシュされます(現在では必須*)。次の検証された重要な事実のもとハッシュ関数は任意のメッセージを一定サイズの値(SHA-256では32バイト長)に｢圧縮｣します。
- 同じハッシュ値を持つ2つの異なるメッセージを見つけたり、計算したりすることは不可能です(コリジョンなし)。
- ハッシュ値がわかっても、対応するメッセージを特定することは不可能です(一方向)。総当たり攻撃は例外ですが、これも実際上は不可能です。
- 特定のメッセージからは常に同じハッシュが生成されます(確定的)。
次に、得られたH_tには、送信者の鍵ペア(プライベート鍵SprivKとパブリック鍵(公開鍵) SPubk_t)が関わる署名アルゴリズム(ECDSAなど)が適用されます。このH_tに対する署名アルゴリズムの実行結果は、メッセージの署名であるS_tです。注：プライベート鍵SPrivKは、送信者によって機密性が保たれ、他者からアクセス不可能である必要があります。そうでなければ、その鍵を送信者に結び付けることは不可能です。
さらに、送信者は3つのデータ(M_t、S_t、SPubk_t)を受信者に送信します。

受信者側では、3つのデータ(M_r、S_r、SPubk_r)が受信されます(メッセージ、署名、パブリック鍵(公開鍵) )。基本的には、このデータは(M_t、S_t、SPubk_t)に等しい必要がありますが、伝送エラーや故意の変更のために、そうはならない場合もあります。

次に、受信者は受信されたメッセージM_rの署名を検証する必要があります。

そのために、M_rは同じハッシュアルゴリズムによって再びハッシュされます。
得られたハッシュH_rには、送信者のパブリック鍵(公開鍵) SPubK_rが関わる署名検証アルゴリズムが適用されます。
このアルゴリズムは、検証結果として｢good｣または｢not good｣を出力します。｢good｣は、M_rが他のプライベート鍵ではなくSprivKを使用して署名されたことを示します。したがって、メッセージの発信者はプライベート鍵SprivKの所有者でしかあり得ません(真正性)。さらに、｢good｣は、M_rがSprivKを使用して署名されたメッセージとまったく同じであることを意味します(完全性)。M_rは署名されてから変更されていません。

SprivKとSPubk_tは数学的に結び付いています(しかし、SPubk_tがわかってもSPrivKを知ることはできません)。したがって、SPubk_tを使用して署名が正しいとわかれば、その署名は他の鍵ではなくSprivKを使用して計算されたことがわかります。

ただし、上記の署名の検証は完全には十分ではありません。メッセージが本物であることを真に保証するには、署名の検証に使用したパブリック鍵(公開鍵) (SPubk_r)は、送信者へとさかのぼって確認される必要があります。実のところ、攻撃者が真の送信者の3つのデータ(M_t、S_t、SPUbk_t)を伝送中に入手し、それを密かに、(攻撃者自身が所有する) SPrivK'を使用して署名した、正しいが悪意のある3つのデータ(M'_t、S'_t、SPubk'_t)で置き換えた場合は、SPubk'_tがS'_tとマッチするため、受信者は3つのデータ(M_r、S_r、SPubk_r) = (M'_t、 S'_t、 SPubk'_t)を本物で、破損していないものと考えます。しかし、そのメッセージは正しい送信者によって送信も署名もされていないのです。

証明書の検証、PKI

SPubk_rが期待される送信者に属するものであると受信者が確認することは不可欠です(SPubk_r = SPubk_t)。送信者が1人だけであれば、これはまったく簡単なことです。SPubk_tを受信者側で保存し、パブリック鍵(公開鍵)の受信したバージョンではなく、この保存したバーションを使用して署名付き着信メッセージを検証すれば十分です。しかし、ネットワーク環境では、多数の送信者が多数の受信者にメッセージを送る場合もあります。こうした事情から、公開鍵基盤(PKI)が登場したのです。PKIでは、パブリック鍵(公開鍵)が証明書に収められ、送信者から受信者に送信されます。証明書は認証局によって発行されます。証明書とは、送信者の完全なID情報(通常、｢www.domainname.org｣のようなサーバのドメイン名、所有組織の名前、住所、国、および電話番号)、その証明書を発行した認証局のID情報、および送信者のパブリック鍵(公開鍵)を含むデータセットです。証明書全体が認証局によってデジタル署名されます(上記の例と同じプロセスに従いますが、メッセージM_tを証明書で置き換え、署名用のプライベート鍵SPrivkは認証局が所有するものと置き換えます)。生成された署名は証明書の末尾に追加されます。

さて、受信者は(M_r、S_r、Cert_SPUbk_r)を受信すると、まず証明書Cert_SPUbk_rが有効であることを確認した上で、SPUbk_rをメッセージの署名の検証に使用する必要があります。そのために、受信者はCert_SPUbk_rの発行者の証明書を使用して、着信メッセージの検証を進めます(メッセージはCert_SPUbk_r)。検証が成功すれば、次のことがわかります。

Cert_SPUbk_r内にある送信者のID情報は改ざんされていません。
証明書に含まれるパブリック鍵(公開鍵) SPUbk_rは、その証明書の所有者のものです。所有者のID情報は証明書に明記されています。

こうなると、恣意的なID情報とパブリック鍵(公開鍵)を含む有効な証明書を偽造するのは不可能になるため、攻撃者が送信者になりすますことはできません。認証局のプライベート鍵は秘密のままです。しかし、認証局の証明書の有効性はどのように確認するのでしょうか。いくつかの中間的な証明書(証明書のチェーン)が使用される場合もありますが、こうした際限のない確認に終止符を打つには、最終的に認証局のルート証明書が信頼の置けるものである必要があります。つまり、検証するには、認証局のルート証明書があらかじめ安全な場所に保管されていなければなりません。

ⁱⁱ ｢中間者｣攻撃では、攻撃者がクライアントとサーバ間のネットワーク通信をリダイレクトします。さらに、攻撃者は一方ではクライアントと、他方ではサーバと、通常のTLSチャネルを確立します。クライアントからトラフィックを受信すると、攻撃者は盗聴や改ざんを行った上で、それをサーバに送信します。サーバからクライアントへのトラフィックについても同様のことを行います。その結果、通信チャネルのセキュリティは失われます。

トラフィックの経路変更は、スイッチやルータのポイズニング(ルータやスイッチはイーサネットカードのMACアドレスとIPアドレスに基づき、イーサネットパケットを適正な受信者に転送します)、またはDNSハイジャック(DNSとは、www.mywebsite.comのようなサーバ名からIPアドレスを取得するプロトコルです)によって実行されます。