8.5 セキュリティシステムの例

本章ではセキュリティの様々な要素を提供する部品を見てきた。例えば暗号アルゴリズム、鍵の事前配布方式、認証プロトコルはどれも部品と言える。本節では、こういった部品を利用する完全なシステムをいくつか見ていく。

本節で見るシステムはセキュリティが提供されるプロトコル層で大まかに分類できる。アプリケーション層にセキュリティを提供するシステムとしては、メールで利用される PGP (Pretty Good Privacy)、そしてリモートログインで利用される SSH (Secure Shell) がある。トランスポート層向けのセキュリティシステムとしては、IETF が策定する TLS (Transport Layer Security)、および TLS の起源となった古い規格 SSL (Secure Socket Layer) がある。IPsec (IP Security) は名前が示すように IP 層 (ネットワーク層) で用いられる。IEEE 802.11i は無線ネットワークのリンク層にセキュリティを提供する。本節ではこういったアプローチのそれぞれについて、その特筆すべき機能を説明していく。

多くの異なる層でセキュリティが提供されるのはどうしてだろうと自然な疑問を持ったかもしれない。一つの理由は「異なる脅威には異なる防御措置が必要であり、そのためにセキュア化すべきプロトコル層が異なるから」である。例えば、PC から IEEE 802.11 アクセスポイントまでのトラフィックを覗き見られることが主な懸念事項なら、おそらくリンク層にセキュリティが必要になる。一方で、アクセスしている銀行のウェブサイトが本物であることを保証し、そのウェブサイトに送信する任意のデータが ISP の好奇心旺盛な従業員によって読まれないようにしたいなら、PC から銀行のサーバーまでの全行程 ── 例えばトランスポート層 ── におけるトラフィックのセキュア化が必要になるだろう。よくあることだが、どんな場合にも利用できる万能の解答は存在しない。

これから説明する全てのセキュリティシステムは利用する暗号アルゴリズムを切り替える機能を持つ。セキュリティシステムと暗号アルゴリズムを切り離すのは非常に優れたアイデアと言える: 開発者が選択した暗号アルゴリズムがユーザーの望む安全性を持たないと将来証明されるかもしれない。プロトコルの仕様や実装を変えずに暗号アルゴリズムを変更できるようにすれば、そういった状況にも簡単に対処できる。このアイデアと「暗号アルゴリズムを変えずに鍵を変える」というアイデアとのアナロジーに注目してほしい。使用中の暗号アルゴリズムに欠陥が見つかった場合にセキュリティアーキテクチャ全体を再設計しなくてはいけないのは望ましくない。

8.5.1 Pretty Good Privacy (PGP)

PGP (Pretty Good Privacy) はメールにセキュリティを提供するアプローチの一つであり、広く利用されている。PGP は認証、機密性、完全性、否認防止を提供する。元々は Phil Zimmerman によって考案され、その後 OpenPGP と呼ばれる IETF 規格となった。第 8.3 節で見たように、鍵の配布モデルとして「信頼の輪 (web of trust)」を利用し、木の形をした階層構造を用いないことが PGP の大きな特徴である。

PGP が機密性と受信者の認証を提供するにはメールの送信者が受信者の公開鍵を知っている必要があり、送信者の認証と否認防止を提供するにはメールの受信者が送信者の公開鍵を知っている必要がある。公開鍵は信頼の輪ベースのPKI と公開鍵証明書によって事前配布される。PGP は公開鍵証明書用の暗号アルゴリズムとして RSA と DSS をサポートし、公開鍵証明書には鍵の所有者がサポートする (あるいは優先する) 暗号アルゴリズムを指定するオプションが存在する。公開鍵証明書はメールアドレスと公開鍵の対応付けを提供する。

例として、PGP が送信者の認証とメッセージの機密性を提供するシナリオをこれから説明する。メールの送信者と受信者をそれぞれアリスとボブとするとき、アリスの PGP アプリケーションは次のステップを実行する:

メッセージに対するアリスの電子署名を作成する。電子署名では MD5, SHA-1, SHA-2 ファミリーといったアルゴリズムが利用できる。
現在のメッセージ送信でのみ利用するセッション鍵を生成し、そのセッション鍵でアリスの署名付きメッセージを暗号化する。さらに、ボブの公開鍵を使ってセッション鍵を暗号化する。
ボブの公開鍵に対する信頼度をアリスに通知する。この信頼度は保持しているボブの公開鍵証明書の個数、およびそれらの証明書に署名した人物の信頼度から計算される。
ステップ 2 で生成したメッセージを base64 符号化して全体を ASCII 互換な表現に変換する。この処理はセキュリティのためではなくメールがテキスト形式のデータしかサポートしないために必要となる。
base64 符号化されたメッセージをボブに送信する。

以上のステップを図 207 に示す。このメッセージを受け取ったボブの PGP アプリケーションはこれらのステップを逆順に行い、オリジナルの平文メッセージに対するアリスのデジタル署名を検証する ── さらに、アリスの公開鍵の信頼度をボブに通知する。

人間に向けてメッセージを一度だけ送信するメールというプロトコルに適切な認証プロトコルを埋め込む上で、PGP はメールの持つ好都合な特徴を活用することで事前のメッセージ交換を行う必要性を排除している (加えて、前節で触れた複雑な問題の一部を回避している)。例えば、メールを使うときアリスの認証はアリスのデジタル署名だけで十分となる。メッセージが適時性を持つ証明が存在しないのもの、メールでは本物のメッセージでも適時性を持つとは限らない。同様にメッセージの独自性に対する保証も PGP は持たない。しかしメールの受信者ボブはおそらく知能を持った人間であり、メールが二重に送られたとしても柔軟に対処できる。セッション鍵はボブの公開鍵で暗号化されるので、アリスはメッセージを読めるのはボブだけであることを確信できる。PGP はボブという人物が存在してメールを受け取ったことをアリスに伝える手段を提供しないものの、ボブからアリスに認証されたメールを送らせることで同じ処理を行える。

以上の議論はアプリケーション層でセキュリティを提供する仕組みが有用である理由を示す優れた例と言える: アプリケーションの動作が完全に理解できれば、防御が必要な攻撃と無視して構わない攻撃を正しく見分けることができる。具体的に言えば、PGP は偽造したメールを送信する攻撃に対する防御は提供するものの、遅延されたメールや再送されたメールなどの攻撃に対する防御は提供しない。

8.5.2 Secure Shell (SSH)

SSH (Secure Shell) プロトコルはリモートログインサービスを提供する。SSH は Telnet を置き換えるものとして開発された。Telnet はインターネットの初期から使われてきたプロトコルであり、セキュリティ機能は少ない (SSH はコマンドのリモート実行やファイルの転送にも利用できるが、ここでは SSH のリモートログイン機能を最初に議論する)。SSH は強力なクライアント/サーバー認証やメッセージ完全性の提供に最もよく利用される ── そのような場合、ユーザーの PC では SSH クライアントが実行され、ログイン先のマシンでは SSH サーバーが実行される。加えて、SSH は機密性の提供もサポートする。Telnet はこういった機能をどれも持たない。なお、「SSH」という言葉が SSH プロトコルを指して使われることもあれば SSH プロトコルを利用するアプリケーションを指して使われることもあるので注意してほしい。どちらを意味しているかは文脈から読み取るしかない。

現代のインターネットにおける SSH の重要性を理解するために、SSH が利用されるシナリオをいくつか示す。例えば在宅勤務をしている従業員は、自宅まで引かれた回線を利用して自社のコンピューターに接続する。インターネットに接続するときは従業員が契約した ISP (そしておそらくは他にもいくつかの ISP) のネットワークが利用されるので、従業員が自社のコンピューターとやり取りするパスワードをはじめとした全ての情報は信頼できないネットワークを通過することになる。こういった場合に SSH はデータを暗号化して通信を行う手段、およびログイン時に強固な認証を行う仕組みを提供する (同様の問題は従業員がスターバックスの Wi-Fi から自社のコンピューターに接続するときにも生じる)。もう一つの SSH の用途として、ルーターへのリモートログインがある (例えば設定の変更やログの確認のために行われる)。ネットワーク管理者は自身がルーターにセキュアにログインでき、認証されていない主体はログインできないことを当然期待する。また、ルーターに送られたコマンドやルーターの返答を第三者が横取りできてはいけない。

最新の SSH は SSH version 2 であり、次の三つのプロトコルから構成される:

SSH-TRANS: トランスポートプロトコル
SSH-AUTH: 認証プロトコル
SSH-CONN: 接続プロトコル

ここではリモートログインに関係する最初の二つのプロトコルに注目する。SSH-CONN の役割は最後に少し触れる。

SSH-TRANS は TCP 接続の上で動作し、クライアントとサーバーの間に暗号化されたチャンネルを提供する。ユーザーが SSH アプリケーションを使ってリモートマシンにログインを試みるときは必ず、二つのマシン間で SSH-TRANS チャンネルを確立することが最初のステップとなる。SSH-TRANS チャンネルの確立は次のように行われる。まずクライアントが RSA を使ってサーバーを認証する。認証が終わると、クライアントとサーバーは新しいチャンネルでやり取りされる任意のデータに対する暗号化で使われるセッション鍵を共有する。この説明は詳細を省略しており、実際には利用する暗号アルゴリズムの交渉などの処理も行われる。暗号アルゴリズムとしては AES がよく選択される。また、SSH-TRANS はチャンネルでやり取りされる全てのデータに対して完全性の検査を行う。

本書が無視できない問題に「サーバーを認証するときに必要なサーバーの公開鍵をクライアントはどのように得るのか」という問題がある。奇妙に思えるかもしれないが、サーバーは接続してきたクライアントに公開鍵を伝える。クライアントが特定のサーバーに初めて接続すると、SSH アプリケーションは「このマシンには接続したことがない」とユーザーに警告を出し、処理を続けるべきかどうかを質問する。この質問に対して多くのユーザーは「yes (処理を続けて構わない)」と答えるものの、これは事実上サーバーを認証しないで通信を行うのに等しいのでリスクが伴う。その後 SSH アプリケーションはサーバーの公開鍵を記憶し、ユーザーが次に同じマシンに接続しようとしたときはサーバーが応答した公開鍵と記録された公開鍵を比較する。もし両者が一致するなら、SSH アプリケーションはサーバーの認証に進む。もし両者が異なるなら、ここでも何かがおかしいことを伝える警告をユーザーに表示し、接続を中断する機会を与える。

慎重なユーザーはサーバーの公開鍵をアウトオブバンドな手段で入手し、それをクライアントマシンに保存しておくことで「このマシンには接続したことがないが、接続するのか？」の質問に yes と答えるリスクを回避できる。

SSH-TRANS チャンネルが作成されると、実際にマシンにログインすることがユーザーにとっての次のステップとなる。具体的に言えば、ユーザーはサーバーに自身を認証してもらう必要がある。ここで使わるのが SSH-AUTH プロトコルであり、このプロトコルは三つの認証の仕組みをサポートする。第一に、SSH-TRANS チャンネルを通してパスワードを送信する方式がある。二つのマシンの間にはセキュアなチャンネルが既に存在するので、そのチャンネルを通してパスワードを送っても問題はない。これは暗号化の機能を持たない Telnet で行ったとすれば安全ではないものの、SSH では SSH-TRANS チャンネルのおかげでパスワードが暗号化される。第二に、公開鍵暗号を用いる方式がある。この方式を使うにはユーザーの公開鍵を事前にサーバーにアップロードしておく必要がある。第三に、信頼されたホストの集合に属するユーザーにはパスワードによる認証をせずにログインを許可する方式がある。この方式はホストベース認証 (host-based authentication) と呼ばれる。ホストベース認証を使うときは、最初に接続したときにクライアントの認証が必要となる (デフォルトだと SSH-TRANS はサーバーの認証しか行わない)。

SSH は本章で説明してきたプロトコルとアルゴリズムの非常に単純な応用である事実を以上の議論から理解してほしい。ただし SSH の利便性を損ねる点として、ユーザーが鍵を作成・管理しなければならず、そのインターフェースが OS ごとに異なる点がある。例えば、多くの Unix マシンでは OpenSSH パッケージを使って公開鍵と私有鍵の組を作成でき、作成された鍵はユーザーのホームディレクトリの決められた場所に保管される。例えば ~/.ssh/known_hosts にはユーザーがログインしたことのあるホストの一覧が記録され、~/.ssh/authorized_keys には自身にログインするユーザーを認証するための公開鍵 (自身がサーバー側のとき利用される) が記録され、~/.ssh/id_rsa にはリモートマシンが自身を認証するときに必要な私有鍵 (自身がクライアント側のとき利用される) が記録される。

SSH はセキュアなリモートログインを提供するシステムとして大きな成功を収めたので、メールの送受信といった他の種類のアプリケーションをサポートできるように拡張されたことを最後に紹介する。基本的なアイデアは SSH で作成した「トンネル」を通して他のアプリケーションを通信させるというものであり、この機能はポートフォワーディング (port forwarding) と呼ばれる。SSH のポートフォワーディングでは SSH-CONN プロトコルが用いられる。

SSH を使ったポートフォワーディングの様子を図 208 に示す。ここでは、ホスト A 上のクライアントが SSH 接続を通してホスト B 上のサーバーと間接的に通信している。この仕組みが「ポートフォワーディング」と呼ばれるのは、サーバーを実行するホストのウェルノウン SSH ポートに到着したメッセージがまず復号され、それからサーバーがリッスンするポートにフォワード転送されるためである。SSH を使ったポートフォワーディングは機密性と認証が提供される特別なトンネルと言える。この SSH トンネルを利用して VPN (virtual private network, 仮想プライベートネットワーク) を構築することもできる。

図 208.

SSH のポートフォワーディングを利用して TCP ベースのアプリケーションをセキュア化する。

8.5.3 TLS, SSL, HTTPS

TLS (Transport Layer Security) および TLS の前身 SSL (Secure Socket Layer) の設計目標と要件は、この二つの規格が解決しようとした主な問題を考えると理解しやすい。ワールドワイドウェブの利用者が増え、商用利用に興味を持つ企業が現れ始めると、ウェブ上の商取引で一定のセキュリティが必要なことは誰の目にも明らかになった。分かりやすい例としてクレジットカードを使った商品の購入がある。クレジットカードの情報をウェブ越しに他の PC (サーバー) に送信するとき、懸念すべき事項がいくつかある。まず、送信した情報が第三者によって読み取られ、知らないうちに商品を購入されてしまう危険性がある。次に、注文した商品の個数といった取引内容が変えられる可能性がある。さらに、クレジットカード情報の送信相手が確かに販売業者のマシンであり、第三者のマシンではないことも確信できなければならない。このように、ウェブにおける商取引が少なくとも機密性、完全性、認証を必要とすることは明らかである。この問題の解決策として最初に広く使われたシステムが Netscape によって開発された SSL であり、SSL は IETF によって策定された TLS の基礎となった。

SSL と TLS の設計者は上述の問題がウェブにおける商取引に特有なものではないと気付いていた。そのため彼らは商取引特有のプロトコルではなく、HTTP といったアプリケーションプロトコルと TCP といったトランスポートプロトコルの間に入り込む汎用プロトコルを作成した。このプロトコルを「transport layer security」と呼ぶのはなぜかと言えば、アプリケーションの視点から見るとき、このプロトコルはセキュアになったことを除けば通常のトランスポートプロトコルと変わらないためである。つまり送信者が接続を開いて転送したいデータを渡すと、SSL/TLS が提供する「セキュアトランスポート層」が機密性、完全性、認証を提供しつつデータを受信者まで送り届ける。このセキュアトランスポート層は TCP の上に構築されているので、TCP が持つ通常の機能 (信頼性、フロー制御、輻輳制御など) もアプリケーションに提供される。

図 209.

アプリケーション層と TCP 層の間に「セキュアトランスポート層」が入り込む。

SSL/TLS の上で実行される HTTP は HTTPS (Secure HTTP) と呼ばれる。なお、HTTP と比べたときの HTTPS の違いはデータをやり取りする相手が TCP 層ではなく SSL/TLS 層である点だけで、HTTPS 自身が行う処理は HTTP と特に変わらない。利便性のため、HTTPS にはデフォルトの TCP ポートとして 443 が割り当てられている。つまり、サーバーの TCP ポート 443 に接続しようとすると、SSL/TLS を前提とした認証や鍵の交換といった処理が行われる。スタンドアローンの SSL/TLS 実装も利用可能ではあるものの、SSL/TLS 実装は利用されるアプリケーション (主にウェブブラウザ) の一部として配布される場合が多い。

トランスポート層セキュリティに関する以降の議論では、TLS に議論を集中させる。SSL と TLS は残念ながら互換性を持たないものの、似ている部分が多いので、ここからの TLS の説明の大部分は SSL の説明としても読むことができる。

TLS ハンドシェイクプロトコル

TLS 通信の両参加者は、利用する暗号アルゴリズムを実行時に交渉する。交渉される要素の一部を示す:

データ完全性を保証するための HMAC を計算するハッシュアルゴリズム (MD5, SHA-1 など)
機密性を保証するための秘密鍵暗号アルゴリズム (DES, 3DES, AES など)
セッション鍵を作成・共有する手法 (Diffie-Hellman 鍵交換、DSS を使った公開鍵認証など)

興味深い点として、TLS のハンドシェイクでは圧縮方式の交渉も行われる。圧縮はセキュリティではなくパフォーマンスのために行われる: 暗号化と復号はデータに含まれる各バイトに重い計算を行うので、データ圧縮の恩恵は通常よりも大きい。圧縮方式の交渉は他の交渉を行うハンドシェイクで一緒に行うのが理にかなっている。

TLS では、機密性を提供する秘密鍵暗号アルゴリズムが二つの鍵と二つの初期化ベクトル (それぞれ各方向に一つずつ) を用いる。また、HMAC の計算でもそれぞれの参加者が異なる鍵を用いる。そのため、暗号アルゴリズムとハッシュアルゴリズムの選択に関わらず、TLS は実質六つの鍵を必要とする。これらの六つの鍵はマスターシークレット (master secret) と呼ばれる共有の値から計算される。マスターシークレットは 384 ビット (48 バイト) の値であり、セッション鍵作成プロトコルで作成される「セッション鍵」などから計算される。

TLS が通信方式を交渉し、最終的に共有のマスターシークレットを作成するときに使われるプロトコルを TLS ハンドシェイクプロトコル (TLS handshake protocol) と呼ぶ。これに対して、実際にデータを転送するときに使われるプロトコルを TLS レコードプロトコル (TLS record protocol) と呼ぶ。TLS ハンドシェイクプロトコルの中心部にあるのはセッション鍵生成プロトコルである (最終的にはセッション鍵ではなくマスターシークレットが作成される)。TLS は様々なセッション鍵作成手法をサポートするので、ハンドシェイクプロトコルはそれだけ複雑になる。さらに、TLS ハンドシェイクプロトコルは両参加者を相互に認証するケース、片方の参加者だけの認証するケース、そして両者とも認証しないケース (匿名 Diffie-Hellman 鍵交換) をサポートする (二番目のケースが最もよく使われる。例えばユーザーがウェブサイトを認証する場合など)。そのため、TLS ハンドシェイクプロトコルは様々なセッション鍵作成プロトコルを一つにまとめたものと言える。

TLS ハンドシェイクプロトコルの概観図を図 210 に示す。最初クライアントは自身がサポートする暗号アルゴリズムの組み合わせを優先度が高い順に並べて送信する。サーバーはクライアントが提示した暗号アルゴリズムの組み合わせの中から今回の通信で利用するものを選択して返答する。最初に交わされる二つのメッセージにはそれぞれクライアントノンス (client nonce) とサーバーノンス (server nonce) が含まれ、この値はマスターシークレットの生成で利用される。

図 210.

TLS セッションを確立するための TLS ハンドシェイクプロトコル

この時点で交渉フェーズが完了する。続いてサーバーは交渉で決定したセッション鍵生成プロトコルを開始するメッセージを送信する。このメッセージには例えば公開鍵認証や Diffie-Hellman 鍵交換のパラメータが含まれる。サーバーがクライアントの認証を要求する場合は、それを伝える別のメッセージも送信される。クライアントはセッション鍵生成プロトコルに基づいた返答を行う。

鍵交換が完了すると、クライアントとサーバーの双方がマスターシークレットを生成するのに十分な情報を保持することになる。前段落の説明で交換された「セッション鍵」には実際には鍵としての役割はなく、この交換された値を TLS ではプリマスターシークレット (pre-master secret) と呼ぶ。マスターシークレットはプリマスターシークレット、クライアントノンス、サーバーノンスから (公開されたアルゴリズムを使って) 計算される。その後クライアントはマスターシークレットから計算される鍵を使って、これまでのハンドシェイクメッセージ全てのハッシュをサーバーに送信する。これに対する応答として、サーバーも同様のハッシュをクライアントに送信する。このやり取りによって、両者は送信および受信したハンドシェイクメッセージに不一致がないことを確認する。例えば最初の暗号化されていないクライアントメッセージが中間者によって改変され、弱い暗号アルゴリズムが強制的に選択される事態を防ぐことができる。

TLS レコードプロトコル

TLS ハンドシェイクプロトコルによってセッションが確立すると、続いて TLS レコードプロトコルが下位のトランスポートサービスに機密性と完全性を提供する。アプリケーション層から渡されたメッセージには次の処理が行われる:

以降のステップが扱いやすいサイズに分割あるいは結合する。
圧縮する (省略可能)。
完全性を保証するために HMAC を付ける。
機密性を保証するために秘密鍵暗号を使って暗号化する。
実際の転送を行う下位のトランスポートプロトコル (通常は TCP) にメッセージを渡す。

TLS レコードプロトコルは HMAC を認証子として用いる。この HMAC は交渉で決定したハッシュアルゴリズム (MD5, SHA-1 など) を使って計算される。偽造を困難にするため、HMAC の計算ではクライアントとサーバーがそれぞれ異なる鍵を用いる。さらに、レコードプロトコルの各メッセージにはシーケンス番号が付与され、このシーケンス番号とメッセージから HMAC が計算される ── ただしシーケンス番号は送信されるメッセージには含まれない。暗黙のシーケンス番号を用いることで、メッセージの再送や順序変更を行う攻撃が効力を失う。この対策が必要な理由は、確かに TCP は順序を保った一度限りのメッセージ転送サービスを上の層に提供するものの、そのサービスはメッセージの横取りや改変、あるいは不正なメッセージの送信を行う攻撃者がいないという仮定の元で提供されるからである。しかし一方で、正当な TLS メッセージに付けられた暗黙のシーケンス番号が正しく伝わることを TLS が確信できるのは TCP の転送保証があるためである。

TLS プロトコルが持つもう一つの興味深い特徴として、セッションを再開する機能がある。この機能が追加された元々の動機を理解するには、まずオリジナルの HTTP が TCP 接続をどのように利用するかを理解しなければならない (HTTP は次章で詳しく説明する)。「サーバーからウェブページを取得する」といった HTTP の操作を行うには、そのたびに新しく TCP 接続を開く必要がある。そのため大量の画像が埋め込まれたページを素早く開くには、多くの TCP 接続が必要になる。TCP 接続を開くにはスリーウェイハンドシェイクを行わなければならない。そして TCP 接続の準備が整ったとしても、TLS を使う場合クライアントは TLS ハンドシェイクプロトコルを開始するので、さらに二度のラウンドトリップが必要となる (このとき時間だけではなく処理能力とネットワーク帯域も消費される)。ここまでの処理の間、アプリケーションのデータは一切送信されない。この「データ送信を開始するまでに必要な処理が多すぎる」という問題を軽減するために TLS のセッション再開機能は設計された。

セッション再開のアイデアは「クライアントとサーバーが過去にセッションを確立していて、その状態を保持しているならハンドシェイクを省略する」というものである。実装はクライアントが過去に確立したセッションを表すセッション ID を最初のハンドシェイクメッセージに含めるという単純な方法で行われる。もしクライアントが提示したセッション ID に対応する状態をサーバーが保持 (キャッシュ) していて、そのセッションを最初に確立したときセッションを継続させるオプションが (交渉を通じて) 設定されていれば、ハンドシェイクは省略されてセッションが再開される。このときサーバーはセッション再開の成功を伝えるメッセージを返答し、この時点で以前の交渉で決定したアルゴリズムとパラメータを用いたデータ転送が可能になる。クライアントが提示したセッション ID に対応するセッション状態がサーバーにキャッシュされていない場合、サーバーは通常のハンドシェイクにフォールバックする。

ここで、「データ送信を開始するまでに必要な処理が多すぎる」という問題はセッション再開が TLS に追加された「元々の」動機であることを強調しておく。ウェブページに埋め込まれたオブジェクトのそれぞれに対する TCP ハンドシェイクで大きなオーバーヘッドが発生する問題は TLS と独立した HTTP の問題であり、後に HTTP はこの問題への解決策として持続的接続 (persistent connection) を導入した。HTTP の改善により TLS のセッション再開の重要性が下がったこと、そしてセッション ID とマスターシークレットの使いまわしはセキュリティリスクであることが理由となり、最新の TLS 1.3 ではセッション再開のアプローチが変化している。

TLS 1.3 において、セッション再開を望むクライアントはサーバーによって暗号化されクライアントからは解読不能なセッションチケット (session ticket) をサーバーに送信する。このセッションチケットにはセッション再開に必要な全ての情報が含まれる。ハンドシェイクでは以前のセッションと同じマスターシークレットが用いられるものの、セッション再開時にセッション鍵を交換するのがデフォルトの振る舞いとなっている。

教訓

この TLS の変更を紹介したのは、特定の問題をどの層で解くべきかを見定めることの難しさを示す良い例だからである。個別に考えれば、以前のバージョンの TLS で実装されていたセッション再開は良いアイデアに思える。しかし機能の良し悪しは支配的なユースケースを念頭に置いて考えなければならない。TLS の支配的なユースケースは HTTP である。大量の TCP 接続によるオーバーヘッドという問題が HTTP で解決されたなら、TLS でセッション再開をどのように実装すべきかも変化する。より一般的な教訓としては、優れた設計を手に入れるために総体的な (層をまたいだ) 視点が必要なときに特定の機能を実装する層を固定して考えることは避けなければならない ── 正しい解答は時間が経ってネットワークが進化すると変化する ── と言えるだろう。

8.5.4 IP Security (IPsec)

インターネットにセキュリティを統合する試みの中でおそらく最も野心的なのは IP 層にセキュリティを提供する IPsec (IP Security) である。IPsec は本章で議論してきたセキュリティサービスの全てを提供するフレームワークであり、単一のプロトコルあるいはシステムではない。IPsec は三つの自由度をユーザーに提供する。第一に、ユーザー (システム管理者の可能性が高い) は暗号アルゴリズムや特殊化されたセキュリティプロトコルを様々な選択肢から選択できる。第二に、IPsec では適用するセキュリティサービス (アクセス制御、完全性、認証、独自性、機密性など) をユーザーが選択できる。第三に、IPsec は幅の狭いストリーム (特定の TCP 接続に属するパケット) を保護することも、幅の広いストリーム (二つのルーター間を流れる全てのパケット) を保護することもできる。

高い視点から見ると、IPsec は二つの部分からなる。一つ目の部分には利用可能なセキュリティサービスを実装する二つのプロトコルが含まれる。具体的には、コネクションレスのメッセージ完全性、再生攻撃に対する耐性、アクセス制御、認証を提供する AH (Authentication Header) と、同様の機能に加えて機密性を提供する ESP (Encapsulating Security Payload) がある。AH はほとんど使われないので、本書では ESP を中心に解説する。二つ目の部分には鍵の管理をサポートする ISAKMP (Internet Security Association and Key Management Protocol) と呼ばれる包括的プロトコルが含まれる。

この二つの部分をまとめた論理的な単方向接続を SA (Security Association) と呼ぶ。つまり SA があると一つ以上のセキュリティ機能が利用可能な単方向通信が行える。ホスト間の双方向通信 ── 例えば TCP 通信 ── をセキュア化するには、二つの SA が必要になる。IP はコネクションレスのプロトコルであるものの、セキュリティを提供するには鍵やシーケンス番号といった状態を保持しなければならない。そのため SA を作成するとき、受信側のマシンには SPI (Security Parameters Index) と呼ばれる ID が割り当てられる。この SPI と宛先 IP アドレスによって SA は一意に識別される。ESP ヘッダーには SPI が含まれているので、受信側のホストは受け取ったパケットが属する SA およびそのパケットに適用すべきアルゴリズムを知ることができる。

SA の確立、交渉、変更、削除は ISAKMP を通して行われる。ISAKMP は鍵や認証データの交換で使われるパケットフォーマットを定義する。このフォーマットはフレームワークを提供するだけなので、あまり興味深くはない ── 暗号化鍵や認証データの形式は鍵生成の手法、暗号アルゴリズム、認証方式によって異なる。また、ISAKMP は鍵交換プロトコルも指定しない。ただし仕様では IKE (Internet Key Exchange) が選択肢の一つとして言及されており、実際の運用では IKE v2 が使われている。

確立された SA を通じてセキュアにデータを転送する役割を担うプロトコルが ESP である。IPv4 で ESP ヘッダーは IP ヘッダーの後ろに続き、IPv6 で ESP ヘッダーは拡張ヘッダーとして転送される。図 211 に示すように、ESP フォーマットにはヘッダーとトレイラーが存在する。SPI フィールドは受信側ホストにパケットの属する SA を伝えるために存在する。SeqNum フィールドは再送攻撃への耐性を提供する。パケットの PayloadData の部分には NextHdr フィールドが記述するデータが含まれる。例えば機密性が選択されたなら、PayloadData は SA に関連付けられた暗号アルゴリズムで暗号化されたデータとなる。PadLength フィールドはデータに付けられたパディングの長さを表す。一部の暗号アルゴリズムでは入力あるいは出力の長さが特定の数の整数倍であることが要求され、パディングが避けられない場合がある。最後に、AuthenticationData の部分には認証子が含まれる。

IPsec は二つのモードをサポートする: トンネルモード (tunnel model) と、それより簡単なトランスポートモード (transport mode) である。各 SA はいずれかのモードで動作する。トランスポートモードの SA では、ESP のペイロードデータがそのまま UDP あるいは TCP といった上位層のメッセージとなる。トランスポートモードの IPsec は SSL/TLS と同様の中間プロトコル層として振る舞う。この種類の ESP メッセージを受け取った受信側ホストは、そのペイロードをそのまま上位層に受け渡す。

これに対してトンネルモードの SA では、ESP のペイロード自体が一つの IP パケットとなる (図 212)。内部の IP パケット (ESP のペイロード) の送信元と宛先は外側の IP パケットのものと一致しなくても構わない。トンネルモードの SA では、ESP メッセージを受け取った受信側ホストはそのペイロードを通常の IP パケットとして転送する。ESP は二つのルーターの間に「IPsec トンネル」 (たいていはファイアウォール) を構築するために最もよく利用される。例えば、ある企業がインターネット越しに二つの拠点をセキュアに接続したいと思っているとしよう。これは、二つの拠点にルーターを設置し、そのルーター同士をトンネルモードの SA で結べば行える。このとき、一方の拠点内のホストからもう一方の拠点内のホストに宛てて送信されたパケットが送信元拠点のルーターに到着すると、ルーターはそのパケットをもう一方の拠点のルーターを宛先とした ESP メッセージに変換してから転送する (元々のパケットは転送される EPS メッセージのペイロードとなる)。そして ESP メッセージを受け取ったもう一方の拠点のルーターはペイロードの IP パケットを本当の宛先に転送する。

図 212.

トンネルモードの SA では、IP パケットが入れ子になる。内側のパケットと外側のパケットは異なる宛先を持てる。

トンネルを構築するときに機密性と認証を提供するよう ESP を設定しておけば、作成される仮想回線に第三者が勝手にアクセスできないこと、そしてトンネルの両端が偽造されたデータを受けとらないことが保証される。加えて、このトンネルはトラフィック機密性も提供する: 複数のフローが同一のトンネルを使って多重化されるので、特定のエンドポイント間で交わされた通信の量は分からなくなる。こういったトンネルは完全な VPN (virtual private network, 仮想プライベートネットワーク) を実装するのに利用できる。VPN 越しに通信を行うホストは VPN が存在することにさえ気が付かない。

8.5.5 無線セキュリティ (IEEE 802.11i)

無線回線は媒体 (空間) が物理的なセキュリティを持たないので、特にセキュリティ脅威に晒される。利便性の高い IEEE 802.11 は広く受け入れられたものの、セキュリティの欠如という問題は繰り返し指摘されてきた。例えば、企業の建物内にある PC が IEEE 802.11 アクセスポイントを経由して企業ネットワークに接続している状況を考えよう。電波はたいていの壁を貫通するので、そのアクセスポイントがセキュリティ対策を行っていないと、攻撃者が企業の建物に入ることなく企業ネットワークへのアクセスを得てしまう可能性がある。同様に、企業の建物内にある PC が建物の外にある企業と関係ないアクセスポイントに接続すると、その PC は攻撃に晒されるかもしれない。さらに、その PC がイーサネット接続などを持っていれば、企業ネットワーク全体が攻撃に晒される可能性がある。

このため、Wi-Fi 回線をセキュア化するために多くの取り組みが行われてきた。信じ難いかもしれないが、IEEE 802.11 に対して開発された初期のセキュリティ技術の一つである WEP (Wired Equivalent Privacy) には深刻な問題が発見されており、非常に簡単に突破できることが知られている。

IEEE 802.11i 規格は認証、メッセージ完全性、機密性を IEEE 802.11 (Wi-Fi) にリンク層で提供する。IEEE 802.11i の同義語として WPA3 (Wi-Fi Protected Access 3) が使われることもあるものの、正確に言うと「WPA3」は製品の IEEE 802.11i 準拠を認証するために Wi-Fi Alliance が利用する商標である。

後方互換性のため、IEEE 802.11i の仕様には深刻な欠陥が知られている第一世代のセキュリティアルゴリズム (WEP など) の定義が含まれている。ここでは IEEE 802.11i が持つ新しい強固なアルゴリズムを説明する。

IEEE 802.11i の認証は二つのモードをサポートする。両方のモードで、認証が終了すると両参加者は PMK (Pairwise Master Key) と呼ばれる共有の鍵を手にする。一つ目のモードはパーソナルモード (personal mode) あるいは PSK モード (Pre-Shared Key mode) と呼ばれる。このモードが提供するセキュリティは弱いものの、家庭の IEEE 802.11 ネットワークで使うのであれば利便性と経済性に優れる。PSK モードでは無線デバイスとアクセスポイントがパスフレーズ (passphrase) ── 長いパスワード ── を事前に共有するものとされ、そこから PMK が暗号学的に計算される。

IEEE 802.11i が提供するもう一つの認証モードはパーソナルモードより強力なセキュリティを持ち、LAN に対するアクセスを制御する方式を定めた IEEE 802.1X 規格のフレームワークをベースとしている。その概観図を図 213 に示す。アクセスポイント (AP) と認証サーバー (AS) は論理的に異なっていても構わないものの、セキュアなチャンネルで結ばれている必要がある。認証が行われる間、AP は無線デバイスと AS の間で交わされる認証メッセージを転送する。認証では EAP (Extensible Authentication Protocol) というプロトコルが用いられる。EAP は複数の認証方式 ── スマートカード (smart card)、Kerberos、ワンタイムパスワード、公開鍵認証 ── および単方向認証と相互認証の両方をサポートできるように設計されている。EAP はプロトコルというよりは認証フレームワークと考えた方がいいだろう。EAP に準拠するプロトコルは EAP メソッド (EAP method) と呼ばれ、様々なものが存在する。例えば EAP-TLS は TLS 認証をベースとした EAP メソッドである。

IEEE 802.11i は EAP メソッドが認証で用いる方式に制限を加えない一方で、EAP メソッドが相互認証を行うことは要求する。これは攻撃者が AP を通してネットワークに接続できないようにするだけでは不十分であり、攻撃者が偽造 AP となって無線デバイスを騙せないようにしなければならないためである。認証が成功すると無線デバイスと AS が PMK を共有するので、その後 AS は (セキュアな接続を通じて) PMK を AP に伝える。

強力なセキュリティを持つ AS ベースのモードとセキュリティの弱いパーソナルモードの重要な違いの一つに、AS ベースのモードではクライアントごとに一意な鍵を容易に生成できることがある。このため、AS は全てのクライアントに保存された秘密の値を変更せずとも認証するクライアントの集合を変更できる。例えば、特定のクライアントのアクセスを一方的に取り消すことができる。

PMK が共有されると、無線デバイスと AP はフォーウェイハンドシェイク (four-way handshake) と呼ばれるセッション鍵作成プロトコルを実行し、PTK (Pairwise Transient Key) を作成する。PTK は正確には鍵の集合であり、その中に Temporal Key と呼ばれるセッション鍵が含まれる。このセッション鍵は機密性と完全性の提供するために IEEE 802.11i が利用するプロトコル CCMP で用いられる。

CCMP は「CTR with CBC-MAC Protocol (Counter Mode with Cipher-Block Chaining and Message Authentication Code protocol)」を意味する。CCMP は AES による暗号化をカウンターモード (counter mode) で用いることで機密性を提供する。繰り返しておくと、カウンターモードとは平文のブロックを暗号化するときカウンターの値をブロックに付け足す方式である。

CCMP は認証子として MAC (message authentication code, メッセージ認証符号) を用いる。MAC の計算では CBC モード (cipher-block chaining mode, 暗号ブロック連鎖モード) をベースとしたアルゴリズムが使われる (ただし先述の通り CCMP は暗号化で CBC モードを使わない)。つまり、出力を捨てながら CBC モードの暗号化を行い、最後に手に入る CBC ブロック (の最初の 8 バイト) を MAC とする。乱数の初期化ベクトルは用いられず、その代わりパケット番号 (シーケンス番号) などから計算された 48 ビットの値が最初のブロックとして使われる。こうするとパケット番号が最終的な暗号文には組み込まれ、再送攻撃を検知する印として機能する。計算された MAC は平文と共に暗号化され、誕生日攻撃 (同じ認証子を持つ異なるメッセージを利用する攻撃) への防御として機能する。

8.5.6 ファイアウォール

本章の大部分では暗号アルゴリズムを使って認証や機密性といったセキュリティ機能を提供する方法を説明してきた。しかし、セキュリティに関する問題の中には暗号で解決できないものも存在する。例えば、ワームやウイルスは OS やアプリケーションプログラムのバグ (そしてときには人間の騙されやすさ) を悪用して拡散する。パッチ未適用のプログラムが持つ脆弱性に対しては、どんな暗号アルゴリズムも役に立たない。そのため、様々な形をした有害な可能性のあるトラフィックを遮断するための対策が暗号化とは別に取られる場合が多い。この対策ではファイアウォール (firewall) がよく使われる。

典型的なファイアウォールは防御対象の拠点とネットワークの残りの部分を接続する箇所に設置される (図 214)。ファイアウォールは専用の機器あるいはルーターで実装されることが多いものの、エンドユーザーのマシンで「個人用」のファイアウォールを実装することもできる。ファイアウォールはセキュリティを提供する上で拠点と外界を接続する箇所が自身だけであることを要求する: 他のゲートウェイ、無線接続、ダイヤルアップ接続を使ってファイアウォールを迂回できてはいけない。なお、ファイアウォールを使った場合でもトラフィックの大部分はファイアウォールを通り抜けるので、「ウォール壁」という比喩はあまり正確でない。ファイアウォールの役割を簡単に言えば「デフォルトでは全てのトラフィックをブロックし、通り抜けることを許可されたトラフィックだけを通過させる」となる。例えば、特定の IP アドレスや特定の TCP ポートを使わない内向きトラフィックを全て遮断するといった使い方ができる。

図 214.

ファイアウォールが拠点と外部インターネットの間で交わされるパケットをフィルタリングする。

ファイアウォールは事実上インターネットを「壁」の内側 (信頼性の高い区域) と「壁」の外側 (信頼性の低い区域) に分割する。これは拠点内の特定のホストやサービスに外部ユーザーがアクセスできないようにするときに便利である。ファイアウォールに関する複雑性の多くは異なる外部ユーザーに対して異なるアクセス権限を与える必要がある事実から生じる。外部ユーザーの区分としては例えば「リモート従業員」「ビジネスパートナー」「その他の人々」などが考えられる。なお、ファイアウォールは一部の攻撃に対処するため、そして攻撃者がファイアウォール内部へのアクセスを得てしまったときの損害を最小化するために外向きトラフィックに制限をかけることもある。

ファイアウォールの設置場所がグローバルにアドレス可能な領域とローカルアドレスを使う領域の境界線になる場合も多い。そのため、NAT (Network Address Translation) とファイアウォールは (論理的に異なる機能であるにもかかわらず) よく同じ機器で実装される。

ファイアウォールを使うと、複数の信頼領域 (zone of trust) を作成できる。よく使われる設定では次の三つの信頼領域が作成される:

内部ネットワーク
DMZ (demilitarized zone, 非武装領域)
その他のインターネット

DMZ には DNS やメールサーバーといった外部からアクセスできる必要のあるサービスが設置される。内部ネットワークと外側の世界の両方が DMZ にアクセスできるものの、DMZ のホストは内部ネットワークへのアクセスを許されない。そのため、仮に攻撃者が DMZ 内のホストの乗っ取りに成功したとしても、内部ネットワークを攻撃することはできない。DMZ を定期的にクリーンステートにリセットする運用も考えられる。

ファイアウォールは IP, TCP, UDP などの情報に基づいてフィルタリングを行う。ファイアウォールの設定は、転送を行う (あるいは行わない) パケットを特定するアドレスのテーブルとして表される。ここで「アドレス」は宛先の IP アドレス以外の情報を含む可能性がある。よくある設定方法では、テーブルの各エントリーが送信元と宛先の IP アドレスとポート番号 (TCP もしくは UDP) からなる四つ組として表される。

例えば、ファイアウォールは次の四つ組にマッチするパケットを遮断する (転送しない) ように設定されるかもしれない:

(192.12.13.14, 1234, 128.7.6.5, 80)

この四つ組は「ホスト 192.12.13.14 のポート 1234 からホスト 129.7.6.5 のポート 80 宛てに送信されたパケットを破棄せよ」とファイアウォールに伝えている (TCP のポート 80 は HTTP で使われるウェルノウンポートである)。しかし当然、パケットを遮断したいホストを全て指定するのは実用的ではない。そのためファイアウォールの設定ではワイルドカードを利用できる。例えば四つ組

(*,  *, 128.7.6.5, 80)

は、ホスト 128.7.6.5 のポート 80 に宛てのパケットを送信元のホストやポートに関わらず全て遮断するようファイアウォールに指示する。ここで、この四つ組を使った設定は第 3 層 (ネットワーク層) のホストアドレスだけではなく第 4 層 (トランスポート層) のポート番号も利用していることに注目してほしい。これが理由で、ネットワーク層のファイアウォールは L4 スイッチ (L4 switch) と呼ばれることがある。

ここまでの説明では、四つ組によって指定されたパケットをファイアウォールが遮断し、指定されなかった全てのパケットを転送するものとしてきた。これとは逆に、指定されたパケットだけを転送し、指定されなかった全てのパケットを遮断する設定にもできる。また、二つの設定を組み合わせることもできる。例えば、ホスト 128.7.6.5 のポート 80 へのアクセスをブロックするのではなく、メールサーバー 128.19.20.21 のポート 25 (SMTP メールポート) に対するアクセスだけを許可したいとしよう。この場合、次の四つ組が表すパケットだけを転送するようにファイアウォールを設定することになる:

(*,  *, 128.19.20.21, 25)

ファイアウォールが誤って設定され、危険なアクセスが許可されてしまう事態が非常に頻繁に発生することが経験から示されている。この問題の一因はフィルタリングの規則が複雑に重なり合った結果、システム管理者がフィルタリングを意図通りに表現するのが難しくなることである。明示的に指定したパケット以外の全てのパケットを遮断するようにファイアウォールを設定することがセキュリティを最大化する設計原則とされている。当然これは正当なアプリケーションが誤って無効化される可能性があることを意味する。そういったアプリケーションのユーザーはいずれパケットが遮断される事実に気が付き、システム管理者に連絡して適切な変更を依頼することになる。

多くのクライアント/サーバーアプリケーションはクライアントに対するポート割り当てを動的に行う。そういったアプリケーションをファイアウォールの内側にいるクライアントが利用する場合、相手のサーバーは動的に割り当てられたポートに宛ててパケットを送信する。このとき問題が発生する: ファイアウォール内部のクライアントが要求した場合にはアプリケーションサーバーが返すパケットを通過させつつ、クライアントが要求していない場合には遮断するにはどうすればいいだろうか？これは各パケットを独立してフィルタリングするステートレスファイアウォール (stateless firewall) では不可能であり、実現には各接続に対して状態を管理するステートフルファイアウォール (statefull firewall) が必要となる。ステートフルファイアウォールにおいて、動的に割り当てられたポート宛ての内向きパケットは、そのポートの接続の現在状態における正当なレスポンスである場合およびその場合に限って通過を許される。

モダンなファイアウォールには、HTTP をはじめとした数多くのアプリケーション層プロトコルを理解した上でフィルタリングを行う機能が備わっている。そういったファイアウォールはプロトコル固有の情報 (HTTP における URL など) を用いてメッセージを破棄するかどうかを判断する。

ファイアウォールの利点と欠点

ファイアウォールを使うとインターネットの外側からの望まないアクセスからネットワークを守ることができる。しかしファイアウォールにできるのはそこまでであり、ファイアウォールをまたいで交わされる通信にセキュリティは提供されない。これに対して、本章で説明してきた暗号を利用するセキュリティの仕組みは任意の場所にいる任意の参加者に対してセキュアな通信を提供できる。それなのに、どうしてファイアウォールはこれほど広く使われているのだろうか？理由の一端として、ファイアウォールは一方的に設置できること、そして成熟した商用製品が存在することがある。これに対して暗号を利用するセキュリティは通信の両エンドポイントにおけるサポートを必要とする。ファイアウォールの圧倒的なシェアを説明するさらに本質的な理由として、ファイアウォールを使うとセキュリティを中央で一元管理できることがある。これは事実上ネットワークの他の部分からセキュリティの問題が取り除かれるのに等しい。システム管理者が設定を行うファイアウォールによってセキュリティが提供されるので、ファイアウォール内のユーザーやアプリケーションはセキュリティの懸念事項 ── 少なくとも一部の懸念事項 ── に頭を悩ませる必要がなくなる。

しかし残念ながら、ファイアウォールには深刻な欠点がいくつかある。まず、ファイアウォールは壁の内側にあるホストの通信は一切制限しない (できない) ので、拠点内部でコード実行に成功した攻撃者は全てのローカルホストにアクセスできることになる。攻撃者はどのようにファイアウォールの内側に入り込むのだろうか？攻撃者は不満を抱いた正規の従業員かもしれないし、CD やウェブからのダウンロードを通してインストールされたソフトウェアに攻撃者の作成したソフトウェアが仕込まれていたのかもしれない。無線通信やダイヤルアップ接続を使ってファイアウォールを迂回する可能性もある。

もう一つの問題として、ファイアウォールが通過を許可した主体 (ビジネスパートナーやリモートで働く従業員など) が全てセキュリティの脆弱性になる事実がある。彼らのセキュリティが十分でなければ、攻撃者は彼らを踏み台にしてファイアウォールの突破を試みるだろう。

最も深刻なファイアウォールの問題は、ファイアウォールの内側にあるマシンが持つバグを利用した攻撃に弱いことである。ファイアウォールに対する攻撃に利用できるバグは定期的に発見されるので、システム管理者は常に目を光らせ、脆弱性が報告されたらすぐにユーザーに知らせなければならない。しかし、発表からしばらく経過した簡単に解決できる類のセキュリティ脆弱性を利用したファイアウォールに対する攻撃の成功例がたびたび報告されており、ユーザーへの通知を行っていないシステム管理者は多いものと推測される。

ファイアウォールとマルウェア

マルウェア (malware) は「malicious software (悪意あるソフトウェア)」を略した単語であり、ユーザーに気付かれないように望ましくない処理を行うソフトウェアを言う。よく見られるマルウェアとしてウイルス、ワーム、スパイウェアがある (「ウイルス」と「マルウェア」が同義語とされる場合もあるが、本書では特定の種類のマルウェアを指す狭い意味で「ウイルス」という言葉を用いる)。マルウェアのコードがネイティブの実行可能オブジェクトコードである必要はない: インタープリタによって実行されるスクリプト、あるいは Microsoft Word などで使われる実行可能マクロもマルウェアになる可能性がある。

ウイルス (virus) とワーム (worm) は自身のコピーを広める手段によって区別される。ワームは自身を複製する能力を持つ完全なプログラムであるのに対して、ウイルスは他のソフトウェアやファイルの一部として攻撃対象のマシンに入り込み、ソフトウェアの実行やファイルのオープンを通して起動する。典型的なウイルスとワームは自身のコピーを大量に拡散させる副作用としてネットワーク帯域を圧迫する。さらに悪いことに、意図的にシステムを攻撃したり様々な形でセキュリティを脆弱化させたりするように設計されるウイルスやワームも存在する。セキュリティの脆弱化の例としては、通常の認証を行わないリモートアクセスを可能にするバックドア (backdoor) のインストールがある。バックドアがインストールされてしまうと、提供されるべき認証手続きを持たないサービスがファイアウォールを通過して公開される可能性がある。

スパイウェア (spyware) とは、コンピューターシステムあるいはそのユーザーに関するプライベートな情報を (正規の認証を受けずに) 収集・転送するソフトウェアを言う。通常スパイウェアは一見すると便利なプログラムに気付かれないように埋め込まれ、ユーザーが自身の操作でプログラムをインストールすることで拡散する。スパイウェアの行うプライベートな情報の転送が正当な通信に見えることがファイアウォールに対する問題となる。

自然な疑問として、ファイアウォール (あるいは暗号によるセキュリティ) を使ってマルウェアを遮断することは可能だろうか？大部分のマルウェアは突き詰めればネットワークを通じて転送される (それ以外の転送経路としては CD や USB メモリといったポータブルストレージがある)。マルウェアの遮断を考えるとき、ファイアウォールの設定で多くのシステム管理者が採用する「明示的に許可されたもの以外は全てブロックする」のアプローチは説得力を増す。

マルウェアを検出する一つのアプローチとして、マルウェアであることが分かっているコードの断片を検索する方法がある。このアプローチで検索されるコードの断片はシグネチャ (signature) と呼ばれる。ただし、注意深く開発されたマルウェアは自身の表現を様々に変えられるので、このアプローチが完璧なわけではない。さらに、この方法だとネットワークに入ってくる全てのデータに対して込み入った検索処理が行われるので、パフォーマンスへの影響も無視できない。

暗号によるセキュリティを使ったとしてもマルウェアの遮断という問題を完全に解決できるわけではない。ただし、ソフトウェアの配布元を認証する手段、そして配布されたソフトウェアにウイルスが混入されていないことを確認する手段は暗号アルゴリズムによって提供される。

ファイアウォールに関連するシステムに IDS (intrusion detection system, 侵入検知システム) と IPS (intrusion prevention system, 侵入防止システム) がある。IDS と IPS は特異なネットワークアクティビティ (例えば特定のホストとポートに宛てられた通常時と比べて極端に大きなトラフィック) がないかどうかを監視する。そういった活動を発見した場合にネットワーク管理者に警告を出すこともあれば、攻撃の可能性のあるトラフィックを直接制限することさえある。IDS と IPS の商用製品は存在するものの、この分野は現在でも発展が続いている。