マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

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

機能

アクセス制御

  • F/Wと同様に、
    • SRC、DSTアドレス
    • DSTポート(プロトコル)
  • 以下を制御できる。
  • IPSecを使用するか?
  • 使用する機能
    • 暗号化
    • メッセージ認証

送信元の認証

  • MACによる送信元の認証

メッセージ認証

  • MACによるメッセージ認証(改ざん検知)

受信データ重複検知

  • リプレイアタックの防止

通信データの暗号化

構成

ピア

  • ピアは、ホストとセキュリティ・ゲートウェイの二種類に分類できる。
  • 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(通信用)がある。
  • ISAKEMP SA(制御用)
  • IPsec SA(通信用)
  • 単方向であるため、双方向通信を行う場合には、上りと下りの2つのSAを確立する必要がある。
  • 2つの単方向コネクションを確立することで、ピア間にセキュアな通信を確立する。

SPI(Security Pointer Index)

  • SAの確定と同時に、SAと関連付けされた32ビットの整数値
  • SPIは暗号化通信で各パケット中に挿入され、暗号化・復号(化)をガイドする。
    • 暗号化アルゴリズム
    • 暗号鍵
  • SPIを検索キーのように使って、パケット内の必要な情報を引き出す。
    • 暗号化アルゴリズムや暗号鍵が推測できないように、暗号化通信の開始時に任意のものが割り当てられる。
    • 値の意味がネゴシエーションを行った当事者者同士以外には分からないように工夫されている。

プロトコル

フロー

ピアSがピアRに向けてIPsecで通信する場合。

  1. SからRへのSAを確立する。
    鍵共有プロトコルが実行される。
  2. SAを使ってパケットをSがRに暗号通信する。
    共有された鍵を用いて、通信を暗号化する。
  3. Rがデータを受信し、復号などの必要処理を行う。
    共有された鍵を用いて、通信を復号(化)する。

中核

中核をなす以下の3つのプロトコルがある。

鍵共有プロトコル

暗号通信プロトコル

鍵共有プロトコル

IKE(Internet Key Exchange)という鍵交換プロトコルを使用する。

  • それ自体で暗号化通信をサポートしている。
  • UDPポート番号500上で通信される。

ISAKMP/Oakley

  • IPsecで利用されるSA確立のためのプロトコル
  • Oaklay
    • Diffie-Hellman技術をベースとして、
    • ピア間での安全なセッションを構成可能にする。

IKEv1

Internet Key Exchange protocol version 1

ISAKMP

  • Internet Security Association Key Management Protocol
  • イニシエータとレスポンダのセッション確立のためのネゴシエーションを行う。
  • ヘッダ
    0 ------------------------------------------------------------- 31
    イニシエータ・クッキー(64bit)
    レスポンダ・クッキー(64bit)
    次ペイロードMajor-VersionMinor-Version交換タイプフラグ
    メッセージID
    全メッセージ長
  • 交換タイプ
    • Mainモード
    • Aggressiveモード
    • Quickモード
  • パケット
    ヘッダペイロード
    IPヘッダUDPヘッダISAKMPヘッダISAKMPペイロードISAKMPペイロードISAKMPペイロード...
  • ISAKMPペイロードの種類
    番号種類
    1SA ペイロード
    2Proposal ペイロード
    3変換ペイロード
    4鍵交換ペイロード
    5ID ペイロード
    6証明書ペイロード
    7証明書要求ペイロード
    8ハッシュ・ペイロード
    9署名ペイロード
    10乱数(nonce)ペイロード
    11通知ペイロード
    12削除ペイロード
    13ベンダ ID ペイロード
    14データ属性ペイロード

フェーズ

  • フェーズ1
    ISAKMP SAを確立
  • フェーズ2
    IPsec SAを確立

ISAKMP SAパラメタのネゴシエーション

  • イニシエータがパラメタを提案
    • 暗号化アルゴリズム
    • ハッシュ・アルゴリズム
    • 認証方式
    • , etc.
  • レスポンダが受諾可能なパラメタを選択・回答

メッセージの交換手順

ISAKMP SAを確立するまでの、

ISAKMPメッセージの交換手順

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

  • Mainモード
    3往復のパケット交換
  • 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公開鍵暗号認証...
4改良型公開鍵暗号認証...

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

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

IPsec SAパラメタのネゴシエーション

  • IPsec SAを確立するISAKMPメッセージの交換手順
    • 秘密対称鍵は、SKEYID_dによって生成される。
    • 通信は、SKEYID_eによって暗号化される。
  • Quickモード
    1.5往復のパケット交換を行う
  • イニシエータは、以下を同時に行う。
    • IPsec SAパラメタのネゴシエーション
    • 認証情報の送信(認証用乱数、認証用ハッシュ)
  • レスポンダは、
    • 受諾可能なパラメタを選択・回答、
    • 認証情報の送信(認証用乱数、認証用ハッシュ)
  • イニシエータは、
    • デバイスの認証を行う(レスポンスは受けない)。
    • IPsec SAを確立し、以降IPsec通信が可能になる。
    • SAは定期的に更新され、両ホスト間で再認証と鍵の更新が行われる。

IKEv2

Internet Key Exchange protocol version 2

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

SA

  • IKE_SA
    • ISAKMP SAに相当する。
    • 上りと下りで2つ造られる。
  • CHILD_SA
    • IPsec SAに相当する。
    • AHとESPの通信に用いられる。

Exchange

イニシエータとレスポンダの通信

  • IKE_SA_INT
    • IKEv1のフェーズ1に相当
    • (デバイス認証を含まない)
  • IKE_AUTH
    • IKEv1のフェーズ1に相当
    • (デバイス認証とユーザ認証)
  • CREATE_CHILD_SA
    IKEv1のフェーズ2に相当
    • 別のCHILD_SAの生成
    • 既存のCHILD_SAの定期更新
  • INFORMATIONNAL
    SAの削除やエラー情報の通知など

暗号通信プロトコル

動作モード

トランスポート・モード

  • ペイロード、TCPヘッダを暗号化(署名)

処理を施す。

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

トンネル・モード

  • ペイロード、TCPヘッダ、IPヘッダを暗号化(署名)

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

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

暗号化、メッセージ認証

SAが確立された後、ピアSとRは、

  • 以下の2つのうちいずれか、
    若しくは両方のプロトコル用いて、
    暗号化(メッセージ認証)通信を行う。
  • 平文の暗号化とメッセージ認証の両方を実行できる共通鍵暗号方式
  • 暗号処理に必要な共通鍵は、SAの確立の際に生成もしくは読み込んだものを用いる。

AH (Authentication Header)

  • IPプロトコル番号 51。
  • 「完全性の保証」と「認証」のための仕組み。
  • IPパケットにメッセージ認証子(MAC)をつけ暗号化は行わないので改竄検知しか担保されない。
  • MAC(SPI、シーケンス番号、認証データ)をパックしてIPへッダの直後に加える。
  • ヘッダのレイアウト
0 ----------------------------------------- 31
次ヘッダペイロード長予約
セキュリティ・パラメタ・インデックス(SPI)
シーケンス番号
認証データ(可変長):ICV(Integrity Check Value)
  • パケット構成
  • 通常時
    IPヘッダTCPヘッダデータ
  • トンネル・モード
    AHヘッダとIPヘッダでカプセル化
    新IPヘッダAHヘッダIPヘッダTCPヘッダデータ
    <-------------------- 認証の範囲 -------------------->

ESP (Encapsulated Security Payload)

  • IPプロトコル番号 50。
  • IPパケットに認証暗号を施すため、パケットの秘匿性と改竄検知の両方が担保される。
  • 以下の3つの情報が
  • 暗号化された通信内容
  • SPIとシーケンス番号フィールド
  • そして認証データ

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

  • パケット
    • レイアウト
      0 ----------------------------------------- 31
      セキュリティ・パラメタ・インデックス(SPI)
      シーケンス番号
      データ
      パディング
      ESPトレーラ(パディング長、次ヘッダ)
      認証データ(可変長):ICV(Integrity Check Value)
  • 構成
  • 通常時
    IPヘッダTCPヘッダデータ
  • トランスポート・モード
    ESPヘッダを挿入
    IPヘッダESPヘッダTCPヘッダデータESPトレーラESP認証データ
    <-------------------- 認証の範囲 -------------------->
    <------------ 暗号化の範囲 ------------>
  • トンネル・モード
    ESPヘッダとIPヘッダでカプセル化
    新IPヘッダESPヘッダIPヘッダTCPヘッダデータESPトレーラESP認証データ
    <-------------------- 認証の範囲 -------------------->
    <------------ 暗号化の範囲 ------------>

ESP認証データは、認証&暗号化対象外。

復号化、メッセージ認証の検証

フィルタリング

  • ピアRは、パケットを受け取り、
  • SADの記載に従って、パケットを破棄するか否かを決める。

復号(化)

  • パケットがIPsecのものであれば、
    • パケットを復号し(暗号化されている場合)
    • メッセージ認証の検証を行った上で、上位レイヤーのプロトコルにパケットを渡す。
  • パケットがIPsecではなく通常のIPのものである場合、
    • 復号などの処理を施さず、
    • 直接上位レイヤーのプロトコルにパケットを渡す。

留意点と対策

端末の不正使用

  • リモートアクセス環境では、
    • デバイス認証だけでなく
    • ユーザ認証が必要になる。
  • XAUTH
  • ISAKMP SAが確立する中でデバイスが認証が行われる。
  • ユーザ認証
  • デバイス認証後に、ユーザ認証が行われる。
  • 認証はユーザIDとパスワードによる(方式はチャレンジ&レスポンスやワンタイムパスワードを選択可)

IPアドレスの動的割当

  • Point-to-Site VPN (P2S)などでポイントとなる端末にIPアドレスの動的割当を行う必要がある。
  • これには、ISAKMP Configuration Methodが使用され、以下の2つの方式がある。
    • イニシエータが要求した情報をレスポンダから受け取る。
    • イニシエーから情報をレスポンダに送り、了解を得る。

NAT / NAPT利用時の留意点

NAT

IPの変換なので、IPヘッダにだけ影響する。

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

※ IKE + ESPで処理可能。

NAPT

IPとポート番号の変換なので、IPヘッダとTCPヘッダに影響する。

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

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

UDP encapsulation of IPSec ESP packets

  • 新IPヘッダとESPヘッダの間にヘッダを追加する。
  • UDPヘッダ(UDPでカプセル化するため)
  • non-IKEヘッダ(IKEパケットとの区別のため)

参考

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

Tags: :IT国際標準, :インフラストラクチャ, :通信技術, :Windows


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-10-26 (土) 17:49:17 (44d)