「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-戻る
--[[VPN]]
--[[Windowsネットワークの基礎知識、設定・トラブルシュート]]

* 目次 [#u69b2388]
#contents

*概要 [#afae0383]
-IPsec(Security Architecture for Internet Protocol、アイピーセック)
-共有鍵暗号方式を用いることで、IP パケット単位で改ざん検知や秘匿機能を提供するプロトコル
--暗号化をサポートしていないトランスポート層やアプリケーション層のプロトコルをネットワーク層で暗号化可能。
--共有鍵暗号方式を用いるので鍵交換が必要。「完全性の確保」と「認証」も含まれる。
-暗号化アルゴリズムなどをあえて特定せず、あらゆる暗号を利用できるような柔軟な枠組みを提供している。
-もともとインターネットの標準化団体であるIETFが[[VPN]]の標準プロトコルとして規定した。

*機能 [#s39cd83f]

**アクセス制御 [#vd989288]
-プロトコル~
以下の何れかで可能
--[[ESP(Encapsulating Security Payload)>#kdc6e311]]
--[[AH(Authentication Header)>#d62f99c7]]

-F/Wと同様に、
--SRC、DSTアドレス
--DSTポート(プロトコル)

-以下を制御できる。

--IPSecを使用するか?

--使用する機能
---暗号化
---メッセージ認証

**送信元の認証 [#b47d2711]
-MACによる送信元の認証

-プロトコル~
以下の何れかで可能
--[[ESP(Encapsulating Security Payload)>#kdc6e311]]
--[[AH(Authentication Header)>#d62f99c7]]

**メッセージ認証 [#m1103410]
-MACによるメッセージ認証(改ざん検知)

-プロトコル~
以下の何れかで可能
--[[ESP(Encapsulating Security Payload)>#kdc6e311]]
--[[AH(Authentication Header)>#d62f99c7]]

**受信データ重複検知 [#z950bf6d]
-リプレイアタックの防止

-プロトコル~
以下の何れかで可能
--[[ESP(Encapsulating Security Payload)>#kdc6e311]]
--[[AH(Authentication Header)>#d62f99c7]]

**通信データの暗号化 [#tbc6612c]
-プロトコル~
[[ESP(Encapsulating Security Payload)>#kdc6e311]]

*構成 [#q965906a]

**ピア [#o89a3055]
-ピアは、ホストとセキュリティ・ゲートウェイの二種類に分類できる。

-IPsecは、原理的にはピアがどちらのタイプであるのかを問わない。

-が、ピアがどちらのタイプであるかによって推奨される通信モードが存在する。

-IPsecの各ピアは、2つのデータベースを管理する。

***SPD(Security Policy Database) [#m59440ff]
セキュリティポリシーのデータベース

-判定ポリシー
--IPアドレス
--プロトコル([[TCP/UDP>TCP, UDP]]/[[ICMP]]等)
--TCPポート

-アクション・ポリシー
--パケットを破棄(discard)
--IPsecを使わずに送信(bypass IPsec)
--IPsecを使って送信(apply IPsec)

***SAD(Security Association Database) [#x13f0c38]
各[[ピア>#o89a3055]]と[[SA>#o2043d34]]を確立する際に用いるパラメタのデータベース

**コネクション [#wb4eb52b]

***SA(Security Association) [#o2043d34]
-一連のネゴシエーションの結果として、お互いの間で得られた暗号化アルゴリズムや暗号鍵に関する合意。

-SAには、ISAKEMP SA(制御用)とIPsec SA(通信用)がある。

--ISAKEMP SA(制御用)~

--IPsec SA(通信用)

---単方向であるため、双方向通信を行う場合には、上りと下りの2つのSAを確立する必要がある。

---2つの単方向コネクションを確立することで、[[ピア>#o89a3055]]間にセキュアな通信を確立する。

***SPI(Security Pointer Index) [#gabb7fc5]
-[[SA>#o2043d34]]の確定と同時に、[[SA>#o2043d34]]と関連付けされた32ビットの整数値

-SPIは暗号化通信で各パケット中に挿入され、暗号化・復号(化)をガイドする。
--暗号化アルゴリズム
--暗号鍵

-SPIを検索キーのように使って、パケット内の必要な情報を引き出す。
--暗号化アルゴリズムや暗号鍵が推測できないように、暗号化通信の開始時に任意のものが割り当てられる。
--値の意味がネゴシエーションを行った当事者者同士以外には分からないように工夫されている。

*プロトコル [#q5da25af]

**フロー [#dc209d0d]
[[ピア>#o89a3055]]Sが[[ピア>#o89a3055]]Rに向けてIPsecで通信する場合。
+SからRへの[[SA>#o2043d34]]を確立する。~
鍵共有プロトコルが実行される。
+[[SA>#o2043d34]]を使ってパケットをSがRに暗号通信する。~
共有された鍵を用いて、通信を暗号化する。
+Rがデータを受信し、復号などの必要処理を行う。~
共有された鍵を用いて、通信を復号(化)する。

**中核 [#ndab438d]
中核をなす以下の3つのプロトコルがある。

***[[鍵共有プロトコル>#ca8380ea]] [#ya8452c3]
-[[IKEv1(Internet Key Exchange protocol version 1)>#uc192a61]]
-[[IKEv2(Internet Key Exchange protocol version 2)>#dcef0a61]]

***[[暗号通信プロトコル>#qef20afc]] [#mda99925]
-[[ESP(Encapsulating Security Payload)>#kdc6e311]]
-[[AH(Authentication Header)>#d62f99c7]]

*鍵共有プロトコル [#ca8380ea]
IKE(Internet Key Exchange)という鍵交換プロトコルを使用する。

-[[ISAKMP/Oakley>#hd03e081]]を元にして作られた。

-「[[Diffie-Hellman>暗号化アルゴリズム#w2cf2dea]]」方式が利用される。

-それ自体で暗号化通信をサポートしている。

-UDPポート番号500上で通信される。

-[[IKEv1>#uc192a61]]と[[IKEv2>#dcef0a61]]があるが互換性はない。

**ISAKMP/Oakley [#hd03e081]
-IPsecで利用される[[SA>#o2043d34]]確立のためのプロトコル

-今日では[[IKE(Internet Key Exchange)>#uc192a61]]に統合化されている。

-[[ISAKMP>#na5a38e4]]

-Oaklay
--[[Diffie-Hellman>暗号化アルゴリズム#w2cf2dea]]技術をベースとして、
--[[ピア>#o89a3055]]間での安全なセッションを構成可能にする。

**IKEv1 [#uc192a61]
Internet Key Exchange protocol version 1

***ISAKMP [#na5a38e4]
-Internet Security Association Key Management Protocol

-イニシエータとレスポンダのセッション確立のためのネゴシエーションを行う。

-ヘッダ
|>|>|>|>|0 ------------------------------------------------------------- 31|
|>|>|>|>|イニシエータ・クッキー(64bit)|
|>|>|>|>|レスポンダ・クッキー(64bit)|
|次ペイロード|Major-Version|Minor-Version|交換タイプ|フラグ|
|>|>|>|>|メッセージID|
|>|>|>|>|全メッセージ長|

--交換タイプ
---Mainモード
---Aggressiveモード
---Quickモード

-パケット
|>|>|ヘッダ|>|>|>|ペイロード|h
|IPヘッダ|UDPヘッダ|ISAKMPヘッダ|ISAKMPペイロード|ISAKMPペイロード|ISAKMPペイロード|...|

--ISAKMPペイロードの種類
|番号|種類|h
|1|SA ペイロード|
|2|Proposal ペイロード|
|3|変換ペイロード|
|4|鍵交換ペイロード|
|5|ID ペイロード|
|6|証明書ペイロード|
|7|証明書要求ペイロード|
|8|ハッシュ・ペイロード|
|9|署名ペイロード|
|10|乱数(nonce)ペイロード|
|11|通知ペイロード|
|12|削除ペイロード|
|13|ベンダ ID ペイロード|
|14|データ属性ペイロード|

***フェーズ [#gaa424df]
-フェーズ1~
ISAKMP SAを確立

--[[ISAKMP SAパラメタのネゴシエーション>#q87c97ec]]
--[[メッセージの交換手順>#c1cb1467]]
--[[デバイスの認証方式>#u1938a73]]

-フェーズ2~
IPsec SAを確立

--フェーズ1で秘密対称鍵が共有できた後、
--[[IPsec SAパラメタのネゴシエーション>#hee7eadd]]
--暗号化通信が行えるようになる。

***ISAKMP SAパラメタのネゴシエーション [#q87c97ec]
-イニシエータがパラメタを提案
--暗号化アルゴリズム
--ハッシュ・アルゴリズム
--認証方式
--, etc.

-レスポンダが受諾可能なパラメタを選択・回答

***メッセージの交換手順 [#c1cb1467]
ISAKMP SAを確立するまでの、

>[[ISAKMP>#na5a38e4]]メッセージの交換手順

として2つの交換タイプがある。

-Mainモード~
3往復のパケット交換

--[[ISAKMP SAパラメタのネゴシエーション>#q87c97ec]]

--「[[Diffie-Hellman>暗号化アルゴリズム#w2cf2dea]]」方式で秘密対称鍵の生成・交換~
次の4つの秘密対称鍵を生成する。
---SKEYID:他のカギを生成する元(事前共有鍵認証の場合、事前共有鍵から生成)~
---SKEYID_d:IPsec SAの秘密対称鍵を生成する元(SKEYIDやDH秘密鍵から生成)~
---SKEYID_a:ISAKMPメッセージ認証用(SKEYID、SKEYID_d、DH秘密鍵から生成)~
---SKEYID_e:IPsec SAの暗号化用(SKEYID、SKEYID_a、DH秘密鍵から生成)~

--[[デバイスの認証方式>#u1938a73]]

-Aggressiveモード~
1.5往復のパケット交換

--イニシエータは、以下を同時に行う。
---[[ISAKMP SAパラメタのネゴシエーション>#q87c97ec]]
---「[[Diffie-Hellman>暗号化アルゴリズム#w2cf2dea]]」方式で秘密対称鍵の生成・交換

--レスポンダは、
---受諾可能なパラメタを選択・回答、
---同時に(、イニシエータ、レスポンダは)、秘密対称鍵が生成可能。

--イニシエータは、
---[[デバイスの認証>#u1938a73]]を行う(レスポンスは受けない)。
---IDにFQDNを使用することで、動的なIPアドレスでも対応できる。

***デバイスの認証方式 [#u1938a73]
通信相手(IPsec機器)との認証を行う認証方式

|#|認証方式|説明|h
|1|事前共有鍵認証(pre-shared key 認証)|事前に鍵交換する(もっとも簡便で広く利用されている)|
|2|ディジタル署名認証|[[証明書]]を使用して相互認証|
|3|公開鍵暗号認証|...|
|4|改良型公開鍵暗号認証|...|

これにより、ISAKMP SAが確立する。

※ 仕組み(シーケンスやペイロードなど)が不明。

***IPsec SAパラメタのネゴシエーション [#hee7eadd]
-IPsec SAを確立する[[ISAKMP>#na5a38e4]]メッセージの交換手順
--秘密対称鍵は、SKEYID_dによって生成される。
--通信は、SKEYID_eによって暗号化される。

-Quickモード~
1.5往復のパケット交換を行う

--イニシエータは、以下を同時に行う。
---IPsec SAパラメタのネゴシエーション
---認証情報の送信(認証用乱数、認証用ハッシュ)

--レスポンダは、
---受諾可能なパラメタを選択・回答、
---認証情報の送信(認証用乱数、認証用ハッシュ)

--イニシエータは、
---[[デバイスの認証>#u1938a73]]を行う(レスポンスは受けない)。
---IPsec SAを確立し、以降IPsec通信が可能になる。
---SAは定期的に更新され、両ホスト間で再認証と鍵の更新が行われる。

**IKEv2 [#dcef0a61]
Internet Key Exchange protocol version 2

-混沌とした IKEv1 の標準化の仕切り直しを図っている。
-[[IKEv1>#uc192a61]]と同じUDPポート500だが互換性はない。
-動的IPアドレスに標準対応している。
-ユーザ認証にEAP (Extensible Authentication Protocol)を標準実装している。

***SA [#xe0a18e9]
-IKE_SA
--ISAKMP SAに相当する。
--上りと下りで2つ造られる。

-CHILD_SA
--IPsec SAに相当する。
--AHとESPの通信に用いられる。

***Exchange [#e5a7ba21]
イニシエータとレスポンダの通信

-IKE_SA_INT
--IKEv1のフェーズ1に相当
--(デバイス認証を含まない)

-IKE_AUTH
--IKEv1のフェーズ1に相当
--(デバイス認証とユーザ認証)

-CREATE_CHILD_SA~
IKEv1のフェーズ2に相当
--別のCHILD_SAの生成
--既存のCHILD_SAの定期更新

-INFORMATIONNAL~
SAの削除やエラー情報の通知など

-参考
--IKEv2 パケット交換とプロトコル レベルのデバッグ - Cisco~
https://www.cisco.com/c/ja_jp/support/docs/security-vpn/ipsec-negotiation-ike-protocols/115936-understanding-ikev2-packet-exch-debug.html

*暗号通信プロトコル [#qef20afc]

**動作モード [#m33fba6f]

***[[トランスポート・モード>VPN#mc567dd3]] [#sbdbcc5e]
-ペイロード、TCPヘッダを暗号化(署名)

-パケットデータ部のみに、
--[[ESP(Encapsulating Security Payload)>#kdc6e311]]暗号化
--[[AH(Authentication Header)>#d62f99c7]]メッセージ認証

>処理を施す。

-主に2つのホスト間の通信で使われる。

***[[トンネル・モード>VPN#j72bb78c]] [#sa0ed6e7]
-ペイロード、TCPヘッダ、IPヘッダを暗号化(署名)

-ヘッダを含めたパケット全体に
--[[ESP(Encapsulating Security Payload)>#kdc6e311]]暗号化
--[[AH(Authentication Header)>#d62f99c7]]メッセージ認証

>処理を施し、新たなIPヘッダを付加する(カプセル化)。

-主に以下の通信で使われる。
--セキュリティ・ゲートウェイとセキュリティ・ゲートウェイ
--セキュリティ・ゲートウェイとホストの間

**暗号化、メッセージ認証 [#j3f3aa41]
[[SA>#o2043d34]]が確立された後、[[ピア>#o89a3055]]SとRは、

-以下の2つのうちいずれか、~
若しくは両方のプロトコル用いて、~
暗号化(メッセージ認証)通信を行う。

--平文の暗号化とメッセージ認証の両方を実行できる共通鍵暗号方式

--暗号処理に必要な共通鍵は、[[SA>#o2043d34]]の確立の際に生成もしくは読み込んだものを用いる。

***AH (Authentication Header) [#kdc6e311]
-IPプロトコル番号 51。

-「完全性の保証」と「認証」のための仕組み。

-IPパケットにメッセージ認証子(MAC)をつけ暗号化は行わないので改ざん検知しか担保されない。

-MAC(SPI、シーケンス番号、認証データ)をパックしてIPへッダの直後に加える。

-ヘッダのレイアウト

|>|>|0 ----------------------------------------- 31|
|次ヘッダ|ペイロード長|予約|
|>|>|セキュリティ・パラメタ・インデックス(SPI)|
|>|>|シーケンス番号|
|>|>|認証データ(可変長):ICV(Integrity Check Value)|

-パケット構成

--通常時
|IPヘッダ|TCPヘッダ|データ|

--[[トランスポート・モード>#sbdbcc5e]]~
AHヘッダを挿入
|IPヘッダ|BGCOLOR(red):AHヘッダ|TCPヘッダ|データ|
|>|>|>|<--------------- 認証の範囲 --------------->|

--[[トンネル・モード>#sa0ed6e7]]~
AHヘッダとIPヘッダでカプセル化
|新IPヘッダ|BGCOLOR(red):AHヘッダ|IPヘッダ|TCPヘッダ|データ|
|>|>|>|>|<-------------------- 認証の範囲 -------------------->|

***ESP (Encapsulated Security Payload) [#d62f99c7]
-IPプロトコル番号 50。

-IPパケットに認証暗号を施すため、パケットの秘匿性と改ざん検知の両方が担保される。

-以下の3つの情報が

--暗号化された通信内容
--SPIとシーケンス番号フィールド
--そして認証データ

>付け加えられた構造になる。

-[[動作モード>#m33fba6f]]によって暗号化の範囲が異なる。

-パケット
--レイアウト
|>|>|0 ----------------------------------------- 31|
|>|>|セキュリティ・パラメタ・インデックス(SPI)|
|>|>|シーケンス番号|
|>|>|データ|
|>|>|パディング|
|||ESPトレーラ(パディング長、次ヘッダ)|
|>|>|認証データ(可変長):ICV(Integrity Check Value)|

--構成

---通常時
|IPヘッダ|TCPヘッダ|データ|

---[[トランスポート・モード>#sbdbcc5e]]~
ESPヘッダを挿入
|IPヘッダ|BGCOLOR(red):ESPヘッダ|TCPヘッダ|データ|BGCOLOR(red):ESPトレーラ|BGCOLOR(red):ESP認証データ|
||>|>|>|<-------------------- 認証の範囲 -------------------->||
|||>|>|<------------ 暗号化の範囲 ------------>||

---[[トンネル・モード>#sa0ed6e7]]~
ESPヘッダとIPヘッダでカプセル化
|新IPヘッダ|BGCOLOR(red):ESPヘッダ|IPヘッダ|TCPヘッダ|データ|BGCOLOR(red):ESPトレーラ|BGCOLOR(red):ESP認証データ|
||>|>|>|>|<-------------------- 認証の範囲 -------------------->||
|||>|>|>|<------------ 暗号化の範囲 ------------>||

※ &color(red){ESP認証データは、認証&暗号化対象外。};

**復号化、メッセージ認証の検証 [#f09c3f50]

***フィルタリング [#o2f0b5d5]
-[[ピア>#o89a3055]]Rは、パケットを受け取り、
-[[SAD>#x13f0c38]]の記載に従って、パケットを破棄するか否かを決める。

***復号(化) [#y6496134]
-パケットがIPsecのものであれば、
--パケットを復号し(暗号化されている場合)
--メッセージ認証の検証を行った上で、上位レイヤーのプロトコルにパケットを渡す。

-パケットがIPsecではなく通常のIPのものである場合、
--復号などの処理を施さず、
--直接上位レイヤーのプロトコルにパケットを渡す。

*留意点と対策 [#p0d1f5c6]

**端末の不正使用 [#nb68b157]
-リモートアクセス環境では、
--デバイス認証だけでなく
--ユーザ認証が必要になる。

-XAUTH

--ISAKMP SAが確立する中でデバイスが認証が行われる。

--ユーザ認証

---デバイス認証後に、ユーザ認証が行われる。

---[[IPsec SAパラメタのネゴシエーション>#hee7eadd]]が暗号化されるようにユーザ認証も暗号化される。

---認証はユーザIDとパスワードによる(方式はチャレンジ&レスポンスやワンタイムパスワードを選択可)

**IPアドレスの動的割当 [#n7d9f72e]
-[[Point-to-Site VPN (P2S)>VPN Gateway#rbc785d4]]などでポイントとなる端末にIPアドレスの動的割当を行う必要がある。

-これには、ISAKMP Configuration Methodが使用され、以下の2つの方式がある。
--イニシエータが要求した情報をレスポンダから受け取る。
--イニシエーから情報をレスポンダに送り、了解を得る。

**[[NAT / NAPT>ネットワーク機器一覧#x06ef648]]利用時の留意点 [#e1050a74]

***NAT [#kd4370eb]
IPの変換なので、IPヘッダにだけ影響する。

|プロトコル|動作モード|問題|h
|IKE|動作モードを問わない|特に問題は生じない。|
|AH|動作モードを問わない|IPヘッダ含めて認証データであるICV(Integrity Check Value)が&br;生成されているので、IPアドレス変更によってICVが不一致になる。|
|ESP|[[トランスポート・モード>#sbdbcc5e]]|IPアドレスの変更に伴い、TCPヘッダのチェックサムを変更する必要があるが、TCPヘッダ自体が暗号化されているため出来ない。|
|~|[[トンネル・モード>#sa0ed6e7]]|トンネルモードでは、新IPヘッダが変更されるだけなので問題ない。|

※ IKE + ESPで処理可能。

***NAPT [#x14df20b]
IPとポート番号の変換なので、IPヘッダとTCPヘッダに影響する。

|プロトコル|動作モード|問題|h
|IKE|動作モードを問わない|IKEパケットのポート番号は変換しないようにする。|
|AH|動作モードを問わない|NATと同じ問題が発生する。|
|ESP|動作モードを問わない|ポート番号は暗号化されているので変換できない。|

※ 処理不可能なので[[UDP encapsulation of IPSec ESP packets>#cc713328]]を使用する。

***UDP encapsulation of IPSec ESP packets [#cc713328]
-新IPヘッダとESPヘッダの間にヘッダを追加する。
-UDPヘッダ(UDPでカプセル化するため)
-non-IKEヘッダ(IKEパケットとの区別のため)

*参考 [#sa20ce66]

-IPsecとは~
http://www.infraexpert.com/study/study10.html

-技術解説:IT管理者のためのIPSec講座 (1/3) - @IT~
http://www.atmarkit.co.jp/ait/articles/0011/27/news001.html

-IPsec - Wikipedia~
https://ja.wikipedia.org/wiki/IPsec

--以下の理由から、現状は専門の技術者が管理するGateway間でVPNとして利用されることが多い。
---通信する二点間で全ての設定が一致していなければ通信が成立しない。
---手動設定の場合は同じ鍵情報を長期間使い続けることになるため、セキュリティ強度の観点からも好ましくない。

----
Tags: [[:IT国際標準]], [[:インフラストラクチャ]], [[:セキュリティ]], [[:通信技術]]
Tags: [[:IT国際標準]], [[:インフラストラクチャ]], [[:セキュリティ]], [[:暗号化]], [[:通信技術]]

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS