「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- IPsec(Security Architecture for Internet Protocol、アイピーセック)
- 共有鍵暗号方式を用いることで、IP パケット単位で改竄検知や秘匿機能を提供するプロトコル
- 暗号化をサポートしていないトランスポート層やアプリケーション層のプロトコルをネットワーク層で暗号化可能。
- 共有鍵暗号方式を用いるので鍵交換が必要。「完全性の確保」と「認証」も含まれる。
- 暗号化アルゴリズムなどをあえて特定せず、あらゆる暗号を利用できるような柔軟な枠組みを提供している。
- もともとインターネットの標準化団体であるIETFがVPNの標準プロトコルとして規定した。
機能 †
アクセス制御 †
- F/Wと同様に、
- SRC、DSTアドレス
- DSTポート(プロトコル)
送信元の認証 †
メッセージ認証 †
受信データ重複検知 †
通信データの暗号化 †
構成 †
ピア †
- ピアは、ホストとセキュリティ・ゲートウェイの二種類に分類できる。
- IPsecは、原理的にはピアがどちらのタイプであるのかを問わない。
- が、ピアがどちらのタイプであるかによって推奨される通信モードが存在する。
- IPsecの各ピアは、2つのデータベースを管理する。
SPD(Security Policy Database) †
セキュリティポリシーのデータベース
- 判定ポリシー
- IPアドレス
- プロトコル(TCP/UDP/ICMP等)
- TCPポート
- アクション・ポリシー
- パケットを破棄(discard)
- IPsecを使わずに送信(bypass IPsec)
- IPsecを使って送信(apply IPsec)
SAD(Security Association Database) †
各ピアとSAを確立する際に用いるパラメタのデータベース
コネクション †
SA(Security Association) †
- 一連のネゴシエーションの結果として、お互いの間で得られた暗号化アルゴリズムや暗号鍵に関する合意。
- SAには、ISAKEMP SA(制御用)とIPsec SA(通信用)がある。
- 単方向であるため、双方向通信を行う場合には、上りと下りの2つのSAを確立する必要がある。
- 2つの単方向コネクションを確立することで、ピア間にセキュアな通信を確立する。
SPI(Security Pointer Index) †
- SAの確定と同時に、SAと関連付けされた32ビットの整数値
- SPIは暗号化通信で各パケット中に挿入され、暗号化・復号(化)をガイドする。
- SPIを検索キーのように使って、パケット内の必要な情報を引き出す。
- 暗号化アルゴリズムや暗号鍵が推測できないように、暗号化通信の開始時に任意のものが割り当てられる。
- 値の意味がネゴシエーションを行った当事者者同士以外には分からないように工夫されている。
プロトコル †
フロー †
ピアSがピアRに向けてIPsecで通信する場合。
- SからRへのSAを確立する。
鍵共有プロトコルが実行される。
- SAを使ってパケットをSがRに暗号通信する。
共有された鍵を用いて、通信を暗号化する。
- Rがデータを受信し、復号などの必要処理を行う。
共有された鍵を用いて、通信を復号(化)する。
中核 †
中核をなす以下の3つのプロトコルがある。
鍵共有プロトコル †
IKE(Internet Key Exchange)という鍵交換プロトコルを使用する。
ISAKMP/Oakley †
IKEv1 †
Internet Key Exchange protocol version 1
ISAKMP †
- Internet Security Association Key Management Protocol
- イニシエータとレスポンダのセッション確立のためのネゴシエーションを行う。
- ヘッダ
0 ------------------------------------------------------------- 31 |
イニシエータ・クッキー(64bit) |
レスポンダ・クッキー(64bit) |
次ペイロード | Major-Version | Minor-Version | 交換タイプ | フラグ |
メッセージID |
全メッセージ長 |
- 交換タイプ
- Mainモード
- Aggressiveモード
- Quickモード
- パケット
IPヘッダ | UDPヘッダ | ISAKMPヘッダ | ISAKMPペイロード | ISAKMPペイロード | ISAKMPペイロード | ... |
- ISAKMPペイロードの種類
番号 | 種類 |
1 | SA ペイロード |
2 | Proposal ペイロード |
3 | 変換ペイロード |
4 | 鍵交換ペイロード |
5 | ID ペイロード |
6 | 証明書ペイロード |
7 | 証明書要求ペイロード |
8 | ハッシュ・ペイロード |
9 | 署名ペイロード |
10 | 乱数(nonce)ペイロード |
11 | 通知ペイロード |
12 | 削除ペイロード |
13 | ベンダ ID ペイロード |
14 | データ属性ペイロード |
フェーズ †
ISAKMP SAパラメタのネゴシエーション †
- イニシエータがパラメタを提案
- 暗号化アルゴリズム
- ハッシュ・アルゴリズム
- 認証方式
- , etc.
メッセージの交換手順 †
ISAKMP SAを確立するまでの、
ISAKMPメッセージの交換手順
として2つの交換タイプがある。
- 秘密対称鍵の生成・交換
- 「Diffie-Hellman」方式で秘密鍵を共有
- これを元に、次の4つの秘密対称鍵を生成する。
・SKEYID:他のカギを生成する元(事前共有鍵認証の場合、事前共有鍵から生成)
・SKEYID_d:IPsec SAの秘密対称鍵を生成する元(SKEYIDやDH秘密鍵から生成)
・SKEYID_a:ISAKMPメッセージ認証用(SKEYID、SKEYID_d、DH秘密鍵から生成)
・SKEYID_e:IPsec SAの暗号化用(SKEYID、SKEYID_a、DH秘密鍵から生成)
- Aggressiveモード
1.5往復のパケット交換
- レスポンダは、
- 受諾可能なパラメタを選択・回答、
- 同時に(、イニシエータ、レスポンダは)、秘密対称鍵が生成可能。
- イニシエータは、
- 通信相手の認証を行う(レスポンスは受けない)。
- IDにFQDNを使用することで、動的なIPアドレスでも対応できる。
通信相手の認証方式 †
通信相手(IPsec機器)との認証を行う認証方式
# | 認証方式 | 説明 |
1 | 事前共有鍵認証(pre-shared key 認証) | 事前に鍵交換する(もっとも簡便で広く利用されている) |
2 | ディジタル署名認証 | 証明書を使用して相互認証 |
3 | 公開鍵暗号認証 | PKIとIDとNonceにより認証を行うが、普及していない。 |
4 | 改良型公開鍵暗号認証 | ... |
これにより、ISAKMP SAが確立する。
IPsec SAパラメタのネゴシエーション †
- IPsec SAを確立するISAKMPメッセージの交換手順
- 秘密対称鍵は、SKEYID_dによって生成される。
- 通信は、SKEYID_eによって暗号化される。
- イニシエータは、以下を同時に行う。
- IPsec SAパラメタのネゴシエーション
- 認証情報の送信(認証用乱数、認証用ハッシュ)
- レスポンダは、
- 受諾可能なパラメタを選択・回答、
- 認証情報の送信(認証用乱数、認証用ハッシュ)
- イニシエータは、
- 通信相手の認証を行う(レスポンスは受けない)。
- IPsec SAを確立し、以降IPsec通信が可能になる。
- SAは定期的に更新され、両ホスト間で再認証と鍵の更新が行われる。
IKEv2 †
Internet Key Exchange protocol version 2
暗号通信プロトコル †
動作モード †
処理を施す。
- ペイロード、TCPヘッダ、IPヘッダを暗号化(署名)
処理を施し、新たなIPヘッダを付加する(カプセル化)。
- 主に以下の通信で使われる。
- セキュリティ・ゲートウェイとセキュリティ・ゲートウェイ
- セキュリティ・ゲートウェイとホストの間
暗号化、メッセージ認証 †
SAが確立された後、ピアSとRは、
- 以下の2つのうちいずれか、
若しくは両方のプロトコル用いて、
暗号化(メッセージ認証)通信を行う。
- 平文の暗号化とメッセージ認証の両方を実行できる共通鍵暗号方式
- 暗号処理に必要な共通鍵は、SAの確立の際に生成もしくは読み込んだものを用いる。
AH (Authentication Header) †
- IPパケットにメッセージ認証子(MAC)をつけ暗号化は行わないので改竄検知しか担保されない。
- MAC(SPI、シーケンス番号、認証データ)をパックしてIPへッダの直後に加える。
0 ----------------------------------------- 31 |
次ヘッダ | ペイロード長 | 予約 |
セキュリティ・パラメタ・インデックス(SPI) |
シーケンス番号 |
認証データ(可変長):ICV(Integrity Check Value) |
- トランスポート・モード
AHヘッダを挿入
IPヘッダ | AHヘッダ | TCPヘッダ | データ |
<--------------- 認証の範囲 ---------------> |
- トンネル・モード
AHヘッダとIPヘッダでカプセル化
新IPヘッダ | AHヘッダ | IPヘッダ | TCPヘッダ | データ |
<-------------------- 認証の範囲 --------------------> |
ESP (Encapsulated Security Payload) †
- IPパケットに認証暗号を施すため、パケットの秘匿性と改竄検知の両方が担保される。
- 暗号化された通信内容
- SPIとシーケンス番号フィールド
- そして認証データ
付け加えられた構造になる。
- パケット
- レイアウト
0 ----------------------------------------- 31 |
セキュリティ・パラメタ・インデックス(SPI) |
シーケンス番号 |
データ |
パディング |
| | ESPトレーラ(パディング長、次ヘッダ) |
認証データ(可変長):ICV(Integrity Check Value) |
- トランスポート・モード
ESPヘッダを挿入
IPヘッダ | ESPヘッダ | TCPヘッダ | データ | ESPトレーラ | ESP認証データ |
| <-------------------- 認証の範囲 --------------------> | |
| | <------------ 暗号化の範囲 ------------> | |
- トンネル・モード
ESPヘッダとIPヘッダでカプセル化
新IPヘッダ | ESPヘッダ | IPヘッダ | TCPヘッダ | データ | ESPトレーラ | ESP認証データ |
| <-------------------- 認証の範囲 --------------------> | |
| | <------------ 暗号化の範囲 ------------> | |
復号化、メッセージ認証の検証 †
フィルタリング †
ピアRは、パケットを受け取り、SADの記載に従って、パケットを破棄するか否かを決める。
復号(化) †
- パケットがIPsecのものであれば、
- パケットを復号し(暗号化されている場合)
- メッセージ認証の検証を行った上で、上位レイヤーのプロトコルにパケットを渡す。
- パケットがIPsecではなく通常のIPのものである場合、
- 復号などの処理を施さず、
- 直接上位レイヤーのプロトコルにパケットを渡す。
留意点と対策 †
端末の不正使用 †
IPアドレスの動的割当 †
NAT †
プロトコル | 動作モード | 問題 |
IKE | 動作モードを問わない | 特に問題は生じない。 |
AH | 動作モードを問わない | IPヘッダ含めて認証データであるICV(Integrity Check Value)が生成されているので、IPアドレス変更によってICVが不一致になる。 |
ESP | トンネル・モード | |
トランスポート・モード | |
NAPT †
参考 †
- 以下の理由から、現状は専門の技術者が管理するGateway間でVPNとして利用されることが多い。
- 通信する二点間で全ての設定が一致していなければ通信が成立しない。
- 手動設定の場合は同じ鍵情報を長期間使い続けることになるため、セキュリティ強度の観点からも好ましくない。
Tags: :IT国際標準, :インフラストラクチャ, :通信技術, :Windows