Loading article…
コンピュータ分野において、インターネットプロトコルセキュリティ（IPsec）は、インターネットプロトコルネットワーク上で2台のコンピュータ間の安全な暗号化通信を実現するために、データパケットの認証と暗号化を行うセキュアなネットワークプロトコルスイートです。仮想プライベートネットワーク（VPN）で使用されています。
IPsecには、セッションの開始時にエージェント間で相互認証を確立し、セッション中に使用する暗号鍵をネゴシエートするためのプロトコルが含まれています。IPsecは、2つのホスト間（ホスト間）、2つのセキュリティゲートウェイ間（ネットワーク間）、またはセキュリティゲートウェイとホスト間（ネットワーク対ホスト）のデータフローを保護できます。[ 1 ] IPsecは、暗号化セキュリティサービスを使用して、インターネットプロトコル（IP）ネットワーク上の通信を保護します。ネットワークレベルのピア認証、データ発信元認証、データ整合性、データ機密性（暗号化）、およびリプレイ攻撃からの保護をサポートします。
1970年代初頭から、高等研究計画局（ARPANET）は、当初はネイティブARPANETパケット暗号化用、その後はTCP/IPパケット暗号化用の実験的なARPANET暗号化デバイスの開発を支援し、その一部は認証され、実用化された。1986年から1991年にかけて、NSAはセキュアデータネットワークシステム（SDNS）プログラムの下でインターネットのセキュリティプロトコルの開発を支援した。[ 2 ]これにより、1988年にネットワーク暗号化デバイスを製造したモトローラを含むさまざまなベンダーが集まった。この研究は1988年頃からNISTによって公開され、そのうちレイヤ3セキュリティプロトコル（SP3）は最終的にISO標準のネットワークレイヤセキュリティプロトコル（NLSP）へと発展した。[ 3 ]
1992年、米国海軍研究所（NRL）はDARPA CSTOからIPv6の実装と、SPARCおよびx86 CPUアーキテクチャの両方をサポートする4.4 BSDでのIP暗号化の研究と実装の資金提供を受けました。DARPAはMITを通じてその実装を無償で公開しました。NRLのDARPA資金提供による研究活動の下、NRLはIPsecのIETF標準トラック仕様（RFC 1825からRFC 1827）を開発しました。[ 4 ] NRLのIPsec実装は、1996年のUSENIX会議議事録 に掲載された論文で説明されています。[ 5 ] NRLのオープンソースIPsec実装はMITによってオンラインで公開され、ほとんどの初期の商用実装の基礎となりました。[ 4 ]
インターネット技術タスクフォース（IETF）は、 IPsecと呼ばれるIPに対する公開仕様のセキュリティ拡張を標準化するために、1992年にIPセキュリティワーキンググループを設立しました[ 6 ]。[ 7 ] NRLが開発した標準は、RFC 1825からRFC 1827としてIETFによって公開されました[ 8 ]。
初期のIPv4スイートは、セキュリティ対策がほとんど施されていない状態で開発されました。IPv4の拡張の一環として開発されたIPsecは、OSI参照モデルの第3層 、つまりインターネット層のエンドツーエンドのセキュリティスキームです。これに対し、広く利用されている他のインターネットセキュリティシステムの中には、トランスポート層で動作するTLS（Transport Layer Security ）やアプリケーション層で動作するSSH（ Secure Shell）など、ネットワーク層より上位で動作するものがありますが、IPsecはインターネット層でアプリケーションを自動的に保護することができます。
IPsecはIPv4スイートの一部としてオープンスタンダードであり、さまざまな機能を実行するために次のプロトコルを使用します。[ 9 ] [ 10 ]
セキュリティ認証ヘッダー (AH) は、1990 年代初頭に米国海軍研究所で開発され、以前の IETF 標準化作業の一部は、 Simple Network Management Protocol (SNMP) バージョン 2 の認証に由来しています。認証ヘッダー (AH) は、IPsec プロトコル スイートのメンバーです。AH は、 AH アルゴリズムでハッシュ関数と秘密の共有キーを使用することで、コネクションレスの完全性を保証します。AH はまた、 IPパケットを認証することでデータの発信元を保証します。オプションで、シーケンス番号は、スライディング ウィンドウ技術を使用して古いパケットを破棄することで、リプレイ攻撃から IPsec パケットの内容を保護できます。 [ 17 ] [ 18 ]
AHはIPプロトコル番号51を使用してIP上で直接動作します。[ 20 ]
以下のAHパケット図は、AHパケットがどのように構築され、解釈されるかを示しています。[ 11 ]
IP カプセル化セキュリティ ペイロード (ESP) [ 21 ]は、1992 年にDARPAが後援する研究プロジェクトの一環として海軍研究所で開発され、 1993 年 12 月にIETF SIPP [ 22 ]ワーキンググループによって SIPP のセキュリティ拡張機能として公開されました。このESP は、ISO ネットワーク層セキュリティ プロトコル (NLSP) から派生したものではなく、米国国防総省のSP3Dプロトコルから派生したものです。SP3D プロトコル仕様は 1980 年代後半にNISTによって公開されましたが、米国国防総省のセキュア データ ネットワーク システム プロジェクトによって設計されました。カプセル化セキュリティ ペイロード (ESP) は、IPsec プロトコル スイートのメンバーです。送信元認証による送信元認証、ハッシュ関数によるデータ完全性、およびIPパケットの暗号化保護による機密性を提供します。ESP は暗号化のみおよび認証のみの構成もサポートしていますが、認証なしで暗号化を使用することは安全ではないため強く推奨されません。[ 23 ] [ 24 ] [ 25 ]
認証ヘッダー（AH）とは異なり、トランスポートモードのESPはIPパケット全体に対する完全性と認証を提供しません。しかし、トンネルモードでは、元のIPパケット全体が新しいパケットヘッダーを追加してカプセル化されるため、ESPによる保護は内部IPパケット全体（内部ヘッダーを含む）に提供されますが、外部ヘッダー（外部IPv4オプションやIPv6拡張ヘッダーを含む）は保護されません。
ESPはIPプロトコル番号50を使用してIP上で直接動作します。[ 20 ]
以下のESPパケット図は、ESPパケットがどのように構築され、解釈されるかを示しています。[ 26 ]
IPsecプロトコルはセキュリティアソシエーションを使用し、通信当事者はアルゴリズムや鍵などの共有セキュリティ属性を確立します。そのため、IPsecはAHまたはESPのどちらを使用するかが決定されると、さまざまなオプションを提供します。データを交換する前に、2つのホストは、IPパケットを暗号化するために使用される対称暗号化アルゴリズム（たとえばAESまたはChaCha20）と、データの完全性を保証するために使用されるハッシュ関数（たとえばBLAKE2またはSHA256）について合意します。これらのパラメータは特定のセッションに対して合意され、そのセッションの有効期間とセッションキーについても合意する必要があります。[ 27 ]
認証アルゴリズムもデータ転送前に合意され、IPsec はさまざまな方法をサポートしています。認証は事前共有鍵によって可能で、対称鍵が両方のホストに既に存在し、ホストは共有鍵のハッシュを互いに送信して、同じ鍵を所有していることを証明します。IPsec は公開鍵暗号化もサポートしており、各ホストは公開鍵と秘密鍵を持ち、公開鍵を交換し、各ホストは相手の公開鍵で暗号化されたnonce を相手に送信します。あるいは、両方のホストが認証局から公開鍵証明書を持っている場合は、これを IPsec 認証に使用できます。[ 28 ]
IPsec のセキュリティ アソシエーションは、インターネット セキュリティ アソシエーションおよびキー管理プロトコル(ISAKMP) を使用して確立されます。ISAKMP は、事前共有シークレット、インターネット キー交換(IKE および IKEv2)、Kerberized Internet Negotiation of Keys (KINK)、および IPSECKEY DNS レコードの使用による手動構成によって実装されます。[ 16 ] [ 1 ] : §1 [ 29 ] RFC 5386 では、Better-Than-Nothing Security (BTNS) を、拡張 IKE プロトコルを使用した IPsec の認証なしモードとして定義しています。C. Meadows、C. Cremers らは、形式手法を使用して、IKEv1 および IKEv2 に存在するさまざまな異常を特定しました。[ 30 ]
送信パケットにどのような保護を適用するかを決定するために、IPsecはセキュリティパラメータインデックス（SPI）（セキュリティ関連付けデータベース（SADB）へのインデックス）とパケットヘッダー内の宛先アドレスを使用します。これらを組み合わせることで、そのパケットのセキュリティ関連付けが一意に識別されます。受信パケットに対しても同様の手順が実行され、IPsecはセキュリティ関連付けデータベースから復号鍵と検証鍵を取得します。
IPマルチキャストの場合、グループに対してセキュリティアソシエーションが提供され、グループのすべての承認済み受信者に複製されます。異なるSPIを使用して、グループに対して複数のセキュリティアソシエーションを設定できるため、グループ内で複数のレベルとセキュリティセットが可能になります。実際、各送信者は複数のセキュリティアソシエーションを持つことができ、受信者は鍵を知っている人物がデータを送信したことしか知ることができないため、認証が可能になります。なお、関連規格では、アソシエーションの選択方法とグループ全体への複製方法については説明されていません。責任者が選択を行うことが前提となっています。
2つのエンドポイント間の接続が中断されていないことを確認するため、エンドポイントは定期的にキープアライブメッセージを交換します。このメッセージは、接続の中断によって失われたトンネルを自動的に再確立するためにも使用できます。
デッドピア検出（DPD）は、インターネット鍵交換（IKE）ピアの障害を検出する手法です。この手法は、IPsecトラフィックパターンを利用して、ピアの可用性を確認するために必要なメッセージ数を最小限に抑えます。DPDは、ピアが障害状態にあることが判明した場合に失われたリソースを解放するために使用され、IKEピアのフェイルオーバーを実行するためにも使用されます。
UDPキープアライブはDPDの代替手段である。
IPsecプロトコルのAHとESPは、ホスト間トランスポートモードとネットワークトンネリングモードの両方で実装できます。
トランスポートモードでは、通常、IPパケットのペイロードのみが暗号化または認証されます。IPヘッダーは変更も暗号化もされないため、ルーティングはそのまま維持されます。ただし、認証ヘッダーが使用される場合、IPアドレスはネットワークアドレス変換によって変更することはできません。これは、ネットワークアドレス変換によってハッシュ値が常に無効になるためです。トランスポート層とアプリケーション層は常にハッシュによって保護されているため、ポート番号の変換など、いかなる方法でも変更することはできません。
NATトラバーサル（NAT-T）のためにIPsecメッセージをカプセル化する手段は、NAT-Tメカニズムを説明するRFC文書によって定義されている。
トンネルモードでは、IPパケット全体が暗号化され、認証されます。その後、新しいIPヘッダーを持つ新しいIPパケットにカプセル化されます。トンネルモードは、ネットワーク間通信（ルーター間など）、ホスト間通信（リモートユーザーアクセスなど）、ホスト間通信（プライベートチャットなど）のための仮想プライベートネットワークを作成するために使用されます。[ 31 ]
トンネルモードはNATトラバーサルをサポートします。
IPsecで使用するために定義されている暗号化アルゴリズムには、以下のものが含まれます。
詳細については、RFC 8221を参照してください。
IPsecは、オペレーティングシステムのIPスタックに実装できます。この実装方法は、ホストとセキュリティゲートウェイで行われます。HPやIBMなどの企業から、さまざまなIPsec対応IPスタックが提供されています。[ 32 ]代替案として、いわゆるバンプ・イン・ザ・スタック（BITS）実装があり、オペレーティングシステムのソースコードを変更する必要がありません。ここでは、IPsecはIPスタックとネットワークドライバの間にインストールされます。この方法で、オペレーティングシステムにIPsecを後付けできます。この実装方法も、ホストとゲートウェイの両方で使用されます。ただし、IPsecを後付けする場合、IPパケットのカプセル化により、2つのIPホスト間のネットワークパス上の最大伝送単位（MTU）サイズが確立される自動パスMTU検出に問題が発生する可能性があります。ホストまたはゲートウェイに独立した暗号プロセッサがある場合（これは軍事では一般的で、商用システムでも見られます）、いわゆるバンプ・イン・ザ・ワイヤ（BITW）IPsec実装が可能です。[ 33 ]
IPsecがカーネルに実装されている場合、鍵管理とISAKMP / IKEネゴシエーションはユーザー空間から実行されます。NRLが開発し、公開仕様となっている「PF_KEY鍵管理API、バージョン2」は、アプリケーション空間の鍵管理アプリケーションがカーネル空間のIPsec実装内に保存されているIPsecセキュリティ関連付けを更新できるようにするためによく使用されます。[ 34 ]既存のIPsec実装には通常、ESP、AH、IKEバージョン2が含まれます。SolarisやLinuxなどのUnix系オペレーティングシステム上の既存のIPsec実装には、通常PF_KEYバージョン2が含まれます。
組み込みIPsecは、限られたリソースシステム上で動作するアプリケーション間の安全な通信を、わずかなオーバーヘッドで保証するために使用できます。[ 35 ]
IPsecはIPv6と連携して開発され、当初はすべての標準準拠のIPv6実装でサポートされることが義務付けられていましたが、RFC 6434によって推奨事項となりました。[ 36 ] IPsecはIPv4実装でもオプションです。IPsecはIPv4トラフィックを保護するために最も一般的に使用されています。
IPsecプロトコルは、1995年に公開されたRFC 1825からRFC 1829で最初に定義されました。1998年に、これらの文書はRFC 2401とRFC 2412に置き換えられましたが、概念的には同一であるものの、技術的な詳細に若干の互換性がありませんでした。さらに、セキュリティアソシエーションを作成および管理するための相互認証および鍵交換プロトコルであるインターネット鍵交換（IKE）が定義されました。2005年12月、RFC 4301とRFC 4309で新しい標準が定義されました。これらは、インターネット鍵交換標準の第2バージョンであるIKEv2を含む、以前の版の上位互換です。これらの第3世代の文書では、IPsecの略語が大文字の「IP」と小文字の「sec」に標準化されました。「ESP」は一般的にRFC 4303を指し、これは仕様の最新バージョンです。
2008年半ば以降、IETFではIPsec保守および拡張（ipsecme）ワーキンググループが活動している。[ 37 ] [ 38 ]
2013年、スノーデンによる情報漏洩事件の一環として、米国国家安全保障局がブルラン計画の一環として「標的が使用する商用暗号化システム、ITシステム、ネットワーク、エンドポイント通信機器に脆弱性を仕込む」活動を積極的に行っていたことが明らかになった。[ 39 ] IPsecが標的型暗号化システムであったという疑惑もある。[ 40 ]
OpenBSD IPsecスタックは後に登場し、広くコピーされました。OpenBSDのリード開発者であるTheo de Raadtが2010年12月11日にGregory Perryから受け取った手紙には、FBIのために働いていたJason WrightらがOpenBSDの暗号コードに「多数のバックドアとサイドチャネル鍵漏洩メカニズム」を挿入したと主張されています。2010年の転送メールの中で、Theo de Raadtは当初、メールを転送することで暗黙の支持を示した以外に、主張の妥当性について公式な立場を表明しませんでした。[ 41 ] Jason Wrightの主張に対する回答：「都市伝説は、実名、日付、時刻を含めることでより現実味を帯びます。Gregory Perryのメールはこのカテゴリーに該当します。...私は、OpenBSDオペレーティングシステムやOpenBSD暗号化フレームワーク（OCF）にバックドアを追加していないことを明確に述べます。」[ 42 ]数日後、デ・ラートは「NETSECはおそらく、申し立てられているようにバックドアを作成する契約を結んだのだろう。...もしそれらが作成されたとしても、我々のツリーには入っていないと思う」とコメントした。[ 43 ]これはスノーデンによるリークの前に公開された。
Logjam攻撃の著者らが提示した別の説明では、NSAが鍵交換で使用されるDiffie-Hellmanアルゴリズムを弱体化させることでIPsec VPNを侵害したとしている。彼らの論文[ 44 ]では、NSAがRFC 2409で定義されている第2オークリー群など、特定の素数と生成子に対する乗法サブグループを事前に計算するために、特別に計算クラスタを構築したと主張している。2015年5月時点で、アドレス指定可能なIPsec VPNの90%がIKEの一部として第2オークリー群をサポートしていた。組織がこの群を事前に計算すれば、ソフトウェアバックドアを挿入することなく、交換される鍵を導出し、トラフィックを復号化できる。
提示された2番目の代替説明は、Equation Groupが複数のメーカーのVPN機器に対してゼロデイエクスプロイトを使用したというもので、 Kaspersky LabはEquation Groupと関連があると検証し[ 45 ]、メーカー自身も実際のエクスプロイトであると検証しており、その中には暴露された時点でゼロデイエクスプロイトもあった[ 46 ] [ 47 ] [ 48 ] 。Cisco PIXおよびASAファイアウォールには、NSAによる盗聴に使用された脆弱性があった[ 49 ]。
さらに、「アグレッシブモード」設定を使用するIPsec VPNは、PSKのハッシュを平文で送信します。これは、オフライン辞書攻撃を使用してNSAによって標的にされる可能性があり、実際に標的にされているようです。[ 44 ] [ 50 ] [ 51 ]
」という綴りが推奨され、この標準および関連するすべての IPsec 標準で使用されています。IPsec の他のすべての大文字表記は非推奨です。