Learning IPsec

1998.6.1
馬場達也

はじめに

現在では、多くの組織がインターネットへ接続しており、特に企業などでは国内外に展開する拠点との間を専用線ではなく、インターネットを利用して情報をやり取りしたいとの要望が増えてきています。

インターネットはセキュリティの問題から、機密の情報をやり取りするには適していません。しかし、暗号化や認証の技術を利用することによりこれを解決する方法があります。その代表的なものがVPN（Virtual Private Network）であり、そのVPNで使用するために標準化されたプロトコルがIPsec（Security Architecture for the Internet Protocol）です。

この「Learning IPsec」では、基本的なVPNの仕組みから、VPNの標準プロトコルであるIPsecの仕組みまで深く理解できるように説明してあります。この内容には執筆時点（1998年6月1日）で最新の情報を盛り込んだつもりですが、IPsecは今まさに改訂されようとしている最中のものですので、この内容だけではなく、常にその動向をチェックしておくことをお勧めします。

この「Learning IPsec」では、以下のような構成になっています。

VPNの概要
IPsecの概要
認証ヘッダ（AH）の詳細
暗号ペイロード（ESP）の詳細
鍵管理の概要
改訂されたIPsecの仕様
利用上の注意点

第１章から読んでいただければVPNの仕組みから理解できるようになっていますが、VPNについて既に知っている方は第２章から読んでいただけると良いかと思います。

1. VPNとは

まず、VPNの仕組みについて説明していきます。VPN（Virtual Private Network）は、インターネットという公衆網上であたかも自分だけが自由に使え、そこを流れる内容を部外者が覗くことができないような通信路を暗号化や認証の技術を使って仮想的に実現するものです。これは、専用線を使った場合の効果と目指すところは同じですが、VPNの方が非常に安いコストで実現できます。しかし、VPNでは帯域が確保されないため、専用線のような高い通信品質を得ることができないといった問題はあります。しかし、目的に応じて使えば、そのコスト面の長所を生かした利用法を実現することができます。この帯域の問題については、現在RSVP（Resource Reservation Protocol）を使う仕組みなどが検討されています。

1.1 VPNの利用形態

このVPNの利用形態としては、大きく分けて以下の3つの使い方が考えられます。

(1) 拠点間での接続（拠点間VPN）

一つ目は、インターネットを介して接続された複数の拠点間でVPNを利用する方法（拠点間VPN）です。これにより、VPNの利用者は、あたかも専用線で接続されているかのようにインターネットを介して相手側拠点と通信することができます。各拠点には、VPN機器と呼ばれる機器を一台づつ設置するだけでよく、通信する端末のそれぞれがVPNの仕組みをもつ必要はありません。

(2) 端末－拠点間での接続（パーソナルVPN）

二つ目は、端末と拠点を結ぶ形態で、特にリモートアクセスなどの目的で利用されます（パーソナルVPN）。例えば自分がいつも持ち歩くノートパソコンに、対応するVPNソフトウェアをあらかじめインストールしておけば、外出先からインターネット経由で安全に内部のサーバにアクセスすることができます。遠距離からのリモートアクセスに利用すると、インターネットのアクセス料金とそのプロバイダの市内のアクセスポイントまでの電話料金だけで済み、コスト面でメリットがでてきます。ただし、その端末からであれば企業内に簡単にアクセスできるため、端末の盗難には最も気を付ける必要があります。導入の際には、端末の管理の徹底、強力なユーザ認証の仕組みの導入、使用できるサービスの制限などを慎重に検討する必要があります。

(3) 端末間での接続（端末間VPN）

三つ目は、端末と端末との間でVPNを利用する方法です（端末間VPN）。この形態により、End-to-Endのセキュリティを確保することができます。

将来OSのネットワーク機能として、標準でVPN機能が提供されるようになれば、この形態での利用が増えるかもしれません。

1.2 ネットワーク上の脅威

次に、VPNの仕組みを説明する前に、ネットワーク上に情報を流すとどのような危険が待ち受けているのかについて整理してみることにします。

ネットワーク上を流れる情報には、大きく以下の３つの脅威があると言われています。

「盗聴」

インターネットの経路情報の変更によって、第三者のネットワークに機密の情報が流れてしまったり、あるいは、悪意を持った人間に公開サーバに不正侵入されることで、そのネットワークを流れる情報の内容を盗み見られてしまう可能性があります。

「メッセージの改竄（かいざん）」

例えば、ある取引きの金額などの重要な情報をインターネットでやり取りする場合、その内容（金額など）を悪意を持った第三者によって書き変えられてしまう恐れがあります。

「なりすまし」

悪意を持った第三者が正当な人物になりすまして、意図しない情報をやり取りされてしまう恐れがあります。

インターネット上に情報を流すと上記のような脅威が待ち受けており、それぞれに対する対策が必要となってきます。これから説明するVPNでは、これらの脅威から守るための仕組みをその基本機能として持っています。

1.3 VPNの仕組み

それではVPNの仕組みについて説明していきます。VPNを構築するためには、各拠点にVPN機器と呼ばれる機器を設置する必要があります。この機器がVPNのすべての機能を集中して提供するため、ネットワークを利用するユーザはVPNを意識する事なく相手拠点側にアクセスすることができます。

現在、このVPN機器には表１のように様々なタイプのものが市販されています。

表１．VPNを実現する機器

ハードウェアタイプ	ルータ、ブリッジ、ハブ、ファイアウォール
ソフトウェアタイプ	PC用、ワークステーション用、ファイアウォール

特に、現在はほとんどのファイアウォールがこのVPNに対応しており、手軽にVPNを構築する事ができるようになってきています。

1.4 脅威に対する対策

それでは、ネットワークでの脅威に対してVPNではどのような対策が取られているのか、それぞれについて説明していきます。

「盗聴」に対する対策

VPNでは、流れる情報を暗号化することによって機密性を確保します。送信時の暗号化と受信時の復号化には、送信側と受信側のみが知っている暗号化鍵（＝復号化鍵）を使用しますが、この鍵は定期的に安全な方法で変更されます。仮にある時点で暗号が破られたとしても、他の鍵で暗号化された情報の内容まで解読されることはないため、情報全体としては安全性が高いといえます。

この暗号化には、主にDESやトリプルDES、IDEA、RC5などの共通鍵暗号方式が使われます。

この機能は、IPsecでは「暗号ペイロード（Encapsulating Security Payload : ESP）」で実現されています（詳しくは第４章を参照）。この仕様は、RFC1827に記述されています。

「改竄」に対する対策

多くのVPN機器では、流れる情報に送信側と受信側のみが知っている秘密の認証鍵を加えて一方向性関数（ハッシュ関数）などで認証データを計算し、その認証データをもとの情報に付与して送ります。受信側は、同じように受け取った情報の認証データを計算し、それを送信側が付与した認証データと比較することによって、メッセージが改竄されていないかどうかを確認することができます（これをメッセージ認証といいます）。

この認証データを計算するための関数として、MD5やSHA1などの一方向性関数（ハッシュ関数）が使用されます。この認証鍵も、前述の「盗聴に対する対策」で説明した暗号化鍵の場合と同じ鍵交換アルゴリズムによって定期的に変更されます。

この機能は、IPsecでは「認証ヘッダ（Authentication Header : AH）」で実現されています（詳しくは第３章を参照）。この仕様は、RFC1826に記述されています。

「なりすまし」に対する対策

これまでに説明したように、VPNでは送信側と受信側の暗号化鍵（復号化鍵）または認証鍵が一致しないとデータの復号化やメッセージ認証に失敗するため、送られてきた情報を受け取らないような仕組みになっています。このため、これらの鍵を所持しない第三者が正当な人物をなりすますことはできません。

しかし、これらの鍵は定期的に自動で交換されます。その際に、交換する相手が正当な相手かどうかを確認しなければならないわけですが、多くの場合、RSAの公開鍵と秘密鍵のペアを利用するなどして、本当に鍵を交換すべき相手なのかどうかを事前に確認し合う仕組みを持っています。このため、第三者がこれらの鍵を入手することはできないようになっています。

この機能は、鍵管理アルゴリズムによって実現されます。IPsecでは、IKE（Internet Key Exchange）などのプロトコルが利用されます。

1.5 VPNを実現するプロトコル

このようなVPNを構築するために使用するプロトコルとして、IPsec以外にも様々なものが存在します（図４）。

PPTP（Point -to-Point Tunneling Protocol）やL2F（Layer 2 Forwarding）は、PPPプロトコルをIPパケットにカプセル化して送るトンネリング・プロトコルです。このため、PPP上で利用できるIPやAppleTalk、IPX/SPXなどのプロトコルが利用できます。この２つのプロトコルは統一され、現在L2TP（Layer 2 Tunneling Protocol）としてIETF（Internet Engineering Task Force）のPPP Extensions Working Groupで標準化の作業が進められています。これらのプロトコルは、主にリモートアクセスで利用されるように設計されています。

また、セッション層レベルで暗号化を実現するプロトコルとして、SOCKS v5やSSL3.0（Secure Socket Layer）、TLS（Transport Layer Security）があります。これらは暗号化だけではなく、相互認証の機能も備えているのでVPNとして利用することができます。

そして、現在VPNで利用するプロトコルとして有力なものが、IPレベルでVPNを実現するIPsecです。これについては、この後で詳しく説明していきます。

2. IPsecの概要

ここでは、VPNを実現する方式の中でも最も有力なプロトコルであると思われる、IPsecの概要について説明します。

2.1 IPsecとは

これまでも、IPレベルでVPNを実現する方式は多く利用されているのですが、VPN機器ベンダは各社独自の仕様でVPNを実現していたものが多く、異なるベンダのVPN機器の間では相互に接続できないという問題がありました。これでは、将来、接続拠点を増やす際に他ベンダの製品を選択できなかったり、また、他企業との間でエクストラネットを構築しようとした場合には、同じベンダのVPN機器を各企業で揃えて導入しなければならないという煩わしさがあります。しかし現在、 IPsecというプロトコルがRFCで定められており、このプロトコルに準拠している機器同士であれば異なるベンダの機器との間でも相互接続が可能となります。

現在、多くのベンダがこのIPsecの実装を進めており、その相互接続試験を進めています。相互接続試験は、米RSA Data Security社が主催するS/WANや、AIAG（Automotive Industry Action Group）のANX（Automotive Network Exchange）などで行われています。また、ICSA（International Computer Security Association）もIPsec対応製品の認定をしています。

IPsecは、IPパケットの機密性とインテグリティを保証し、認証の機能を提供する仕組みです。IPレベルでこれらのセキュリティを提供することで、IPを使用するアプリケーションはすべて、この機能を利用することができます。これは、現在のIPv4で利用できるだけでなく、次世代のIPであるIPv6では標準の機能とされています。

しかし、現在このIPsecが全面的に改訂されようとしています。現在はInternet Draftの段階ですが、この仕様がRFCとして出版されれば、各ベンダともこの新しい仕様に対応していくことと思います。

現在出版されているIPsec関連のRFCと、改訂版の仕様が記述されたInternet Draftは以下の通りです（図６）。

【RFC】

Proposed Standard（提案標準）

"Security Architecture for the Internet Protocol"
RFC1825
"IP Authentication Header"
RFC1826
"IP Encapsulating Security Payload (ESP)"
RFC1827
"IP Authentication using Keyed MD5"
RFC1828
"The ESP DES-CBC Transform"
RFC1829
"HMAC-MD5 IP Authentication with Replay Prevention"
RFC2085

Informational（情報提供）

"HMAC: Keyed-Hashing for Message Authentication"
RFC2104

Experimental（実験的）

"The ESP Triple DES Transform"
RFC1851
"IP Authentication using Keyed SHA1"
RFC1852

【Internet Drafts（代表的なもののみ記載）】

既存のRFCの改訂版

"Security Architecture for the Internet Protocol" ※RFC1825の改訂版
draft-ietf-ipsec-arch-sec-05.txt
"IP Authentication Header" ※RFC1826の改訂版
draft-ietf-ipsec-auth-header-06.txt
"IP Encapsulating Security Payload (ESP)" ※RFC1827の改訂版
draft-ietf-ipsec-esp-v2-05.txt
"The Use of HMAC-MD5-96 within ESP and AH" ※RFC1828/RFC2085の改訂版
draft-ietf-ipsec-auth-hmac-md5-96-03.txt
"The Use of HMAC-SHA1-96 within ESP and AH" ※RFC1852の改訂版
draft-ietf-ipsec-auth-hmac-sha1-96-03.txt
"The ESP DES-CBC Cipher Algorithm With Explicit IV" ※RFC1829の改訂版
draft-ietf-ipsec-ciph-des-expiv-02.txt

鍵管理プロトコル

"The Internet IP Security Domain of Interpretation for ISAKMP"
draft-ietf-ipsec-ipsec-doi-09.txt
"Internet Security Association and Key Management Protocol (ISAKMP)"
draft-ietf-ipsec-isakmp-09.txt
"The Internet Key Exchange (IKE)"
draft-ietf-ipsec-isakmp-oakley-07.txt
"The OAKLEY Key Determination Protocol"
draft-ietf-ipsec-oakley-02.txt

2.2 認証ヘッダと暗号ペイロード

IPsec では、「認証ヘッダ（AH）」（RFC1826）と「暗号ペイロード（ESP）」（RFC1827）の２つのプロトコルを規定しています。

「認証ヘッダ」は、IPパケットにメッセージ認証の機能を提供します。「暗号ペイロード」は、VPNの暗号化やトンネリングの機能を提供し、IPパケットに機密性とインテグリティを提供します。これらの仕組みは独立して動作するので、IPパケットのメッセージ認証の機能を利用したい場合は認証ヘッダを利用し、データの暗号化やトンネリングの機能を利用したい場合は暗号ペイロードを利用すれば良いわけです。また、両方を組み合わせて利用することももちろん可能です。

IPv4の場合は、通常IPv4ヘッダの後に認証ヘッダが続き、その後に暗号ペイロードが続きます（図７）。しかし、第５章で述べるSKIPという鍵交換プロトコルが使用される場合には、IPv4ヘッダのすぐ後にSKIPヘッダが挿入されます。

IPv6でIPsecが利用される場合には、通常、IPv6ヘッダの後に、認証ヘッダ、暗号ペイロードと続きます。しかし、IPv6の拡張ヘッダとして、中継点オプションヘッダや経路制御ヘッダ、断片ヘッダが使用されている場合は、その後に認証ヘッダと暗号ペイロードが続きます（図８）。（IPv6の詳細については、他の書籍を参照して下さい）

2.3 セキュリティ・アソシエーションとSPI

IPsecでは、暗号化や認証に使用するアルゴリズムを規定していません。このため、様々な種類のアルゴリズムの中から利用したいものを選択することが可能となります。しかし、当然、相手側がどのアルゴリズムを使用して暗号化したのか、どのアルゴリズムを利用して認証しているのかということが分からなければパケットを受け取ることができません。

このような情報を保持するために、IPsecでは「セキュリティ・アソシエーション」を利用します。「セキュリティ・アソシエーション」には、使用する暗号化アルゴリズムの種類、暗号化アルゴリズムのモード、暗号化アルゴリズムで使用する初期ベクトル（IV）の長さ、認証アルゴリズムの種類、認証アルゴリズムのモード、暗号化鍵、認証鍵などの情報が保持されます。この「セキュリティ・アソシエーション」はそれぞれの機器で保持され、IPsecパケットを送り出す場合には、相手側の保持するセキュリティ・アソシエーションの中から利用できるものを送信側が選択し、そのセキュリティ・アソシエーションに付けられている「セキュリティ・パラメータ・インデックス（SPI）」の値をそのパケットの認証ヘッダや暗号ペイロードのフィールドに含めて送ります。受信側は、認証ヘッダや暗号ペイロードのヘッダ中のSPI値によってどのセキュリティ・アソシエーションが使用されているのかを識別します（図９）。このSPIの値は受信側が付与します（0～255は予約されていますので、その他の値が使用されます）。

このセキュリティ・アソシエーションは単方向です。つまり、端末Aと端末Bが通信する場合、端末Aから端末Bへのパケットと、端末Bから端末Aへのパケットには異なるセキュリティ・アソシエーションが使用されます。よって、行きのパケットはDESで暗号化し、帰りのパケットはトリプルDESで暗号化するといったような、その方向によって使用するアルゴリズムを変えることができるわけです。

また、認証ヘッダと暗号ペイロードはそれぞれにSPIフィールドを持っており、それぞれ独立して別のセキュリティ・アソシエーションを選択することができます。

2.4 トンネルモードとトランスポートモード

VPNの方式にはその利用法によってトンネルモードとトランスポートモードの二つのモードがあります。この二つの方式には、それぞれ長所と短所がありますのでそれについてもまとめておきます。

(1) トンネルモード

トンネルモードと呼ばれるモードでは、IPパケット全体を暗号化し、それを新しいIPパケットにカプセル化（包み込む）します（図10）。こうすることで、データだけではなく、IPヘッダも暗号化されますので、送信元アドレスや宛先アドレス、使用しているプロトコル（アプリケーション）などの情報を隠すことができます。

このモードの長所と短所についてまとめると以下の通りになります。

（長所）

内部ネットワークでプライベートアドレスを利用している場合でも、VPN機器にグローバルアドレスが付与されていれば、VPN機器のグローバルアドレスを含むIPヘッダが付加されるので、インターネットを経由してプライベートアドレス同士の端末間で通信をすることが可能となります。

また、この機能を利用することにより、内部ネットワークでIPv6を使用している場合では、そのIPv6パケットをIPv4パケットにカプセル化することも可能なことから、利用者はIPv4ネットワークを意識することなくIPv6パケットを流すこともできます。

（短所）

暗号化されたパケットに新たにIPヘッダを付加するため、その分パケットのサイズが大きくなり配送中にパケットの分割が起こり、スループットが下がる可能性があります。

(2) トランスポートモード

もうひとつのモードは、トランスポートモードと呼ばれます。このモードでは、IPヘッダは暗号化せずに、IPパケットのユーザデータ（トランスポート層以上の部分）のみを暗号化します（図11）。このモードは主に、端末間でのセキュリティを提供するために利用されます。

（長所）

トンネルモードのようにパケットのサイズが大きくならずに済みます。

（短所）

トンネルモードと違い、オリジナルのIPヘッダをそのまま利用して送られるので、宛先や送信元の端末がプライベートアドレスを使用している場合は、インターネットを介して通信することができません。

2.5 IPsecが適用されたパケット

これまででIPsecの概要について説明してきましたが、その過程でIPパケット自身にどのような処理がされていくのかを整理すると以下の図のようになります（図12, 13）。

以下の図は、暗号ペイロード（ESP）の処理と認証ヘッダ（AH）の処理の両方がされていますが、どちらかが単独で使用されても構いません。

以上のように、IPsecではIPパケットに暗号ペイロード（ESP）と認証ヘッダ（AH）の処理がされていくわけですが、この後では、このIPsecの重要な２つの仕組みについて詳細に説明していきます。

3. 認証ヘッダ（AH）

3.1 認証ヘッダの仕組み

認証ヘッダは、IPパケット全体のインテグリティを保証するための仕組みです。この仕組みは、RFC1826に記述されています。

認証ヘッダでは、MD5やSHA-1のような一方向性ハッシュ関数をパケット全体に対して適用し、その結果を認証データとしてそのパケットと一緒に送ります。この時、送信側と受信側しか知らない秘密の認証鍵を認証計算に含めることで、第三者がパケットの内容を改竄した後で認証データを再び計算し直すことができないようにしています。この認証鍵を含めた計算の方法は、別の文書で定義されます。このアルゴリズムとしては現在、Keyed-MD5（RFC1828）、Keyed-SHA1（RFC1852）、HMAC-MD5（RFC2085）などがあります。

ここで重要なのは、認証ヘッダはIPのデータのみではなく、IPヘッダを含んだパケット全体に対して認証データを計算するということです。こうすることで、例えば、IPヘッダの送信元アドレスなどの情報も配送中に改竄されることはなくなります。こうすることで、そのパケットの送信元アドレスのホストが確かに送り出したパケットであることが保証されることになり、身元証明を必要とするアプリケーションに利用することができるでしょう。しかし、IPヘッダの内容には、IPv4ヘッダの「TTL」や「ヘッダチェックサム」、そしてIPv6ヘッダの「中継限界数」フィールドのように、配送中に内容が変更されるフィールドを含みます。これらのフィールドを認証計算に含めると、受信側での認証の確認の際には内容が変更されているため、認証に失敗することになります。このため、これらのフィールドは、認証の計算の際に値が "0" であるとして計算されます（図14）。

特に、データ部分のインテグリティは、データ部を暗号化する暗号ペイロードによってある程度保証されており（特に現在議論中の改訂版の仕様では、暗号ペイロードの機能として、ハッシュ関数を利用したデータ部のインテグリティチェックの機能が含まれる予定です）、認証ヘッダは、IPヘッダの情報を改竄から守るものとして利用されます。

認証ヘッダは、通常IPヘッダのすぐ後に挿入されます。認証ヘッダはIPプロトコル番号として51番を割り当てられているため、IPv4ヘッダのプロトコル・フィールドには、値51が含まれます。IPv6の場合は、IPv6基本ヘッダや中継点オプションヘッダ、経路制御ヘッダ、断片ヘッダなどの後に挿入されます。

認証ヘッダで使用されるアルゴリズムは、認証ヘッダ自体の仕様では決められていませんが、必須のアルゴリズムとして、Keyed-MD5（RFC1828）とHMAC-MD5（RFC2085）を実装することになっています。その他のアルゴリズムとしては、Keyed-SHA1（RFC1852）などがあります。

3.2 認証ヘッダの処理の流れ

認証ヘッダでは以下のような流れで処理が行われます。

（送信側）

送信側の利用者IDと宛先アドレスから、認証ヘッダで使用するセキュリティ・アソシエーションを決定する。
セキュリティ蜒Aソシエーションで指定する認証アルゴリズム、認証鍵を使用してパケット全体に渡って認証データを計算する。この時、配送中に中間のルータなどによって変更される可能性のあるフィールドは、すべて "0" で満たされているとして計算する。このフィールドは、IPv4の場合は、「TTL」、「ヘッダチェックサム」（「TOS」、「フラグ」、「断片オフセット」も "0" にされることも多い）、IPv6の場合は、「中継限界数」フィールドである。この時は認証ヘッダが挿入された状態のパケットに対して認証データが計算されるが、その「認証データ」フィールドも、"0" で満たされているとみなされる。
認証ヘッダの次ヘッダ・フィールド、長さフィールド、SPIフィールドに適切な値を入れ、先ほど計算された認証データを認証データ・フィールドに挿入し、パケットを組み立てる。この時、IPヘッダの全パケット長・フィールドが適切な値に調整される。
組み立てたパケットがネットワーク上に送られる。

（受信側）

受信されたパケットのプロトコル・フィールド（IPv4の場合）、次ヘッダ・フィールド（IPv6の場合）にIPプロトコル番号51が含まれているので、認証ヘッダが使用されていることが判断される。
認証ヘッダのSPIフィールドの値から、使用されているセキュリティ・アソシエーションを検索する。
そのセキュリティ・アソシエーションから、使用されている認証アルゴリズム、認証鍵を判断し、パケット全体に渡って認証データを計算する。この時、IPv4ヘッダの「TTL」や「ヘッダチェックサム」、IPv6ヘッダの「中継限界数」フィールド、そして認証ヘッダの「認証データ」フィールドは送信側と時と同様に "0" であるとみなされる。
ここで計算された認証データと、認証データ・フィールドに入っていた値とを比較し、同一のものであれば認証処理が成功したことになる。
認証処理が成功すれば、認証ヘッダが外されて、もとの状態でネットワーク上に送られる。この時、IPヘッダの全パケット長フィールドが適切な値に調整される。

3.3 認証ヘッダでのKeyed-MD5の利用

認証ヘッダでは、必須のアルゴリズムとして、Keyed-MD5を実装するように規定されています。Keyed-MD5についてはRFC1828に記述されています。

Keyed-MD5では、送信側と受信側が共有する秘密の認証鍵を、認証されるデータ（IPヘッダとデータ）の前後に付加し、その全体に対してMD5を適用します（図15, 16）。そしてその結果得られた128ビットのハッシュが、認証データとして認証ヘッダの認証データ・フィールドに挿入されます。

3.4 認証ヘッダでのHMAC-MD5の利用

HMACも、Keyed-MD5が出力するような認証データを作成するアルゴリズムです。このHMACは、Keyed-MD5のような、認証鍵をメッセージに連結する方式に弱点が発見されたため考案されました。このHMACの仕組みについては、RFC2104に記述されています。

HMACでは、その内部でMD5やSHA-1などのハッシュ関数を使用します。その使用されるハッシュ関数によって、HMAC-MD5やHMAC-SHA1などの名称で呼ばれます。（HMAC-MD5については、RFC2085に記述されています。）

HMAC-MD5の場合、認証されるメッセージの前に、鍵Kと固定文字列 ipad（64バイトの値：0x36363636…36）のXORの結果を付加し、MD5を計算します。そしてその結果生じた128ビットのハッシュ値の前にさらに鍵Kと固定文字列opad（64バイトの値：0x5c5c5c5c…5c）のXORの結果を付加し、再び、MD5を計算します。この結果生じたハッシュ値が、実際の認証データとして使用されます（図17）。

H(K XOR opad , H(K XOR ipad , text))
H: ハッシュ関数、K:鍵, text: データ

この時、鍵KとipadとのXORの結果を鍵K1、鍵KとopadとのXORを鍵K2と考えると、これらの鍵をMD5に適用した結果を通常のMD5への初期ベクトル（IV）として利用していることになるので、通常は固定値である初期ベクトルを、変数として扱っているということと同じになるわけです。HMACではこのようにして強度を増しています。

また、HMAC-MD5の仕様では、RFC1826で定義されている認証ヘッダのフォーマットが変更されています（図18）。これは、現在議論されている改訂版の認証ヘッダにも取り入れられるものですが、下図のように64ビットのリプレイ防止フィールドが追加されています。このフィールドの値は、パケットが送られるたびに1から単純に増加するわけですが、こうすることで、認証されたパケットを第三者がコピーし、それを後で何らかの形で再び使用するという攻撃（リプレイ攻撃）を防ぐことができます。

4. 暗号ペイロード（ESP）

4.1 暗号ペイロードの仕組み

暗号ペイロード（ESP）は、IPパケットを暗号化することによって、IPパケットの機密性を保証する仕組みです。この仕組みは、RFC1827に記述されています。

暗号ペイロードは、第2.4章で説明したトンネルモードとトランスポートモードの２つのモードを実現する仕組みを持っています。しかし、その暗号化のアルゴリズムについては、暗号ペイロードの仕様では決められていません。これは、将来新しい安全なアルゴリズムを使用したい場合に、この暗号ペイロードの仕様を変更することなく使用できるようにするためです。

暗号ペイロードには、IPプロトコル番号として50番が割り当てられています。この暗号ペイロードは、通常、IPヘッダや認証ヘッダなどの後に挿入されますので、例えば認証ヘッダと一緒に使用されれば、IPヘッダのプロトコル・フィールドには51番が含まれますし、他のヘッダが利用されなければ、50番が含まれることになります（図19）。

4.2 暗号ペイロードの処理の流れ

暗号ペイロードは以下のような流れで処理されます。

（送信側）

送信側の利用者IDと宛先アドレスから、暗号ペイロードで使用するセキュリティ・アソシエーションを決定する。
トンネルモードの場合は、IPパケット全体をセキュリティ・アソシエーションで指定する初期ベクトルの長さ、暗号化アルゴリズム、暗号化鍵を使用して暗号化する。トランスポートモードの場合は、IPパケット中のデータ部のみ（TCP. UDP, ICMP）をセキュリティ・アソシエーションで指定する初期ベクトルの長さ、暗号化アルゴリズム、暗号化鍵を使用して暗号化する。この時、暗号化される前のデータの最後には、パディング、パディング長・フィールド、次ヘッダ・フィールドが付加される。この暗号ペイロードの次ヘッダ・フィールドには、トンネルモードであれば、IP-in-IPで指定されているIPプロトコル番号の4番、トランスポートモードであれば、暗号化したトランスポート層プロトコルのIPプロトコル番号が含まれる（TCPであれば6番、UDPであれば17番となる）。
使用したセキュリティ・アソシエーションを示すSPI値と、もし使用されていれば暗号化アルゴリズムの初期ベクトル、そして先ほど暗号化されたペイロードデータを使って暗号ペイロードを組み立てる。
トンネルモードであれば、送信元アドレスが暗号ペイロードの処理を施した機器のアドレス、宛先アドレスが相手側の（復号化する）機器のアドレスを含んだIPヘッダが付加される。トランスポートモードであれば、もともとのIPヘッダが付与される。この時、そのIPヘッダのプロトコル・フィールド（IPv4）、次ヘッダ・フィールド（IPv6）には、暗号ペイロードのIPプロトコル番号である50番が含まれる。また、この時、全パケット長フィールドの値も調整される。
組み立てられたパケットがネットワーク上に送られる。

（受信側）

受信されたパケットのプロトコル・フィールド（IPv4）、次ヘッダ・フィールド（IPv6）に50番が含まれているので、暗号ペイロードが使用されていることが判断される。
暗号ペイロードのSPIフィールドの値から使用されているセキュリティ・アソシエーションを検索する。
そのセキュリティ・アソシエーションから、初期ベクトルの長さや使用されている暗号化アルゴリズムの種類、復号化鍵を判断し、それらを利用して復号化処理をする。
復号化された暗号ペイロードの次ヘッダ・フィールドの値から、トンネルモードとトランスポートモードのどちらが使用されているのかが判断される。
復号化されたパディング長・フィールドで指定された長さのパディングが取り除かれる。
トンネルモードの場合は、復号化されたパケットがそのままネットワーク上に送り出される。トランスポートモードの場合は復号化されたデータにもとのIPヘッダが付与され、ネットワーク上に送り出される。この時、IPヘッダのプロトコル・フィールド（IPv4）、次ヘッダ・フィールド（IPv6）と、全パケット長・フィールドの内容が適切な値に調整される。

4.3 暗号ペイロードでのDES-CBCの利用

ここで、暗号ペイロードで必須とされているDES-CBCを使った場合について説明します。このDES-CBCについては、RFC1829に記述されています。

DES-CBCでは、32ビットまたは64ビットの任意の値の初期ベクトル（IV）を使用します。その初期ベクトルの長さは、セキュリティ・アソシエーションのパラメータとして決められています。初期ベクトルが32ビットの場合には、ビット補完して64ビットにしてから使用します。そのヘッダ・フォーマットと処理の過程については以下の図の通りです（図20, 21）

暗号ペイロードで利用できるアルゴリズムには、このDES-CBCの他に、トリプルDES（RFC1851）やRC5、IDEAを使用したものなどが存在します。

5. 鍵管理

5.1 鍵交換の必要性

IPsecの仕組みである認証ヘッダと暗号ペイロードは、IPパケットに強力なセキュリティを提供するものです。しかし、このセキュリティは、使用する暗号化鍵や認証鍵が第三者に知られないことが前提とされています。つまり、これらの鍵が知られてしまえばIPsecの仕組みはセキュリティのないものとなってしまいます。

暗号の解読には、基本的に鍵の総当たりが使用されます。このことから、鍵の長さはなるべく長いものを利用して、鍵の総当たりにかかる時間をなるべく長くするべきですが、結局時間を費やせば解かれてしまいますし、暗号技術の輸出規制などにより、十分に長い鍵長のものを利用できないという現実があります。

そこで、その暗号化鍵や認証鍵を定期的に短い間隔で変更することが必要となります。

5.2 手動鍵管理

鍵の一番簡単な交換方法は、手動鍵管理（マニュアル鍵管理）と呼ばれるものです。この手動鍵管理は、IPsecの仕様では必須とされています。

手動鍵管理では、文字通り、管理者が送信側と受信側の各システムで鍵を手動で設定します。しかし、定期的に鍵を手動で変更するのはとても現実的な方法ではありません。そこで、後述する自動で鍵を交換する仕組みが求められてきます。

5.3 既存の鍵交換方式

自動で鍵交換を行なう仕組みには、大きく分けて二つの方式が存在します。

一つは、RSAなどの公開鍵暗号方式を利用する方式です。これは、データ自体は高速なDESなどの共通鍵暗号方式で暗号化しますが、そこで使われる秘密の暗号化鍵を、RSAなどの公開鍵暗号方式で暗号化して相手側に送るというものです（図22）。

もう一つは、Diffie-Hellman法です。この方式（図23）では、鍵を交換するAとBには、あらかじめ素数pと原始根gを知らせておきます。このpとgは第三者に知られても構いません。そして、AとBはそれぞれ秘密の乱数値xとyを生成します。そしてその秘密の値と、先程のpとgからある計算式によって、それぞれnとmという値を生成します。このnとmをお互いに交換し（この値は第三者に知られても構わない）、交換された値と自分の持っている秘密の値、そして素数pからある計算式によって、AとBの両者はまったく同じKという値を得ることができます。この値KをAとBで共有する秘密鍵として使用するのです。

5.4 鍵管理プロトコル

鍵交換の基本的な方式としては、上記のような方式が使用されるわけですが、RSAやDiffie-Hellman法では、鍵交換の仕組みをプロトコルレベルで規定しているわけではないので、各社独自に実装することになります。しかし、それでは相互接続性を保つことができません。これをプロトコルレベルで規定したものが、IKE（Internet Key Exchange）やSKIP（Simple Key-management for Internet Protocol）です。これらの鍵管理プロトコルは、基本的にはDiffie-Hellman法を使用するものですが、鍵の交換だけではなく、暗号化アルゴリズムの種類などのセキュリティ・アソシエーションのパラメータを取り決める機能も持っています。

IPsecでは、必須の鍵管理プロトコルとしてIKEを指定しています。IKEは以前ISAKMP（Internet Security Association and Key Management Protocol）/Oakleyと呼ばれていた鍵管理プロトコルで、現在Internet Draftとして議論の途中です。このプロトコルは、UDPのポート500番を使用し、実際のデータパケットとは別のパケットを使用します。

また、その他の鍵管理プロトコルとしては、SKIPが存在します。こちらもRFCとしては出版されていませんが、IPsecではオプションとして使用することが決定されています。しかし、比較的早くから実装が進められているため、SKIPを採用しているVPN機器間では、既にある程度の相互接続ができているようです。こちらはIPのオプションヘッダとして規定されており、実際のデータパケットのヘッダという形で挿入されます。ですから、別のパケットが発生することはありませんが、パケット自体のサイズは大きくなります。SKIPには、IPプロトコル番号として57番が割り当てられています。

6. 改定された IPsec の仕様

IPsecは、1995年にRFC1825-1829として規定されましたが、この仕様の改訂版が現在IETFのIP Security Protocol Working Groupで議論されています。この改訂版の仕様は、Internet Draftとして参照することができます（第2.1章を参照）。これらの仕様では、内容が以前のものよりも詳しく記述されている他に、そのフォーマットが少し変更されています。ここでは、その変更されたフォーマットについて説明します。

6.1 改定された認証ヘッダの仕様

改定された認証ヘッダでは、下図のように、新たに「通し番号」フィールドが追加されました（図24）。これは、すでにRFC2085のHMAC-MD5で採用されているものと同じものです（HMAC-MD5では64ビットのフィールドですが、この仕様では32ビットとなっています）。このフィールドの値は、パケットが送られる度に 1 から単純に増加するわけですが、こうすることで、認証されたパケットを第三者がコピーし、それを後で何らかの形で再び使用するという攻撃（リプレイ攻撃）を防ぐことができます。

また、必須のアルゴリズムが変更されており、Keyed-MD5やHMAC-MD5の代わりに、HMAC-MD5-96とHMAC-SHA1-96が指定されています。これらは、以前のKeyed-MD5の方式で使われていた認証鍵の組み合わせ方法よりも安全なHMACを使用し、さらにそのHMACの出力を96ビットに省略します。32ビットの「通し番号」フィールドが追加されたわけですが、代わりに認証データが96ビットに省略されているので、認証ヘッダ全体としてはサイズが大きくなったわけではありません。

6.2 改定された暗号ペイロードの仕様

改定された暗号ペイロードでも認証ヘッダと同じ32ビットの「通し番号」フィールドが追加されています（図25）。

また、大きな変更点としては、暗号ペイロードでも認証ヘッダのようなインテグリティをチェックするような機能が追加されたことがあげられます。

この機能を利用することによって、暗号ペイロード自体のインテグリティを保つことができますが、認証ヘッダの提供するようなIPヘッダの認証の機能は持たないため、パケットの送信元アドレスの認証などをしたい場合は、従来通り、認証ヘッダを利用することになります。

必須のアルゴリズムとして、Explicit IVを使ったDES-CBCと、認証の機能が加わったことで、認証ヘッダと同じHMAC-MD5-96とHMAC-SHA1-96が指定されています。

7. 利用上の注意点

ここでは、実際にIPsecを利用する場合のいくつかの注意点について説明します。

7.1 ファイアウォールの設定

VPNの利用形態には、拠点間の接続やリモートアクセスなどが考えられますが、この時問題となるのが、ファイアウォールの設定です。ファイアウォールでは、通常のパケットを制限しつつVPNのパケットを通すように設定しなければなりません。

IPsecでは、その利用法によってファイアウォールでの設定が違ってきます。

(1) 暗号ペイロード（ESP）のみを使用する場合: 暗号ペイロードのみを使用する場合には、通常IPv4ヘッダのプロトコル・フィールドには、IPプロトコル番号として50番が含まれます。よってファイアウォールでは、利用するアドレス間のIPプロトコル番号が50番のパケットを通す設定にする必要があります。ただし、暗号ペイロードを使用し、かつ認証ヘッダも使用する場合には以下の(2)の設定に、SKIPを使用する場合には、以下の③の設定になります。
(2) 認証ヘッダ（AH）を使用する場合: 認証ヘッダを使用する場合には、通常IPv4ヘッダのプロトコル・フィールドには、IPプロトコル番号として51番が含まれます。よってファイアウォールでは、利用するアドレス間のIPプロトコル番号が51番のパケットを通す設定にする必要があります。ただし、認証ヘッダを使用していても鍵管理にSKIPを使用する場合には、(3)の設定になります。
(3) 鍵管理プロトコルとしてSKIPを使用する場合: 鍵管理プロトコルとしてSKIPを使用する場合、VPNのパケットにはSKIPヘッダが含まれます。これは通常、認証ヘッダや暗号ペイロードの前に現れますので、IPv4ヘッダのプロトコル・フィールドには、IPプロトコル番号として57番が含まれます。よってファイアウォールでは、利用するアドレス間のIPプロトコル番号が57番のパケットを通す設定にする必要があります。
(4) 鍵管理プロトコルとしてIKE（ISAKMP/Oakley）を使用する場合: 鍵管理プロトコルとしてIKEを使用する場合には、VPNのパケットとは別にUDPのポート500番のパケットが鍵管理のために利用されます。よってファイアウォールでは、上記の設定に加えて、利用するアドレス間の500/UDPのパケットを通す設定にする必要があります。

表２. IPsecにおいて使用されるプロトコルの種類

ESPのみを使用する場合	IPプロトコル番号50
AHのみ/AH+ESP を使用する場合	IPプロトコル番号51
鍵管理にIKEを使用する場合	上記のプロトコル＋ 500/UDP
鍵管理にSKIPを使用する場合	IPプロトコル番号57
（参考）PPTP を使用する場合	IPプロトコル番号47 ＋ 1723/TCP
（参考）L2F/L2TP を使用する場合	1701/UDP

7.2 相互接続上の問題

これまで、IPsecに対応している機器間であれば、相互接続が可能であると説明してきましたが、それには実はいくつかの問題点が残されています。ここでは相互接続時に問題となると考えられる項目についてまとめておきます。

(1) 認証ヘッダ（AH）でのパディング方法の違い

認証ヘッダは、配送中に変更される可能性のあるヘッダ・フィールドを認証データの計算の前に "0" で埋めてから（パディング）計算する仕組みになっています。しかし、どのフィールドを "0" で埋めるかという解釈が複数存在し、ベンダによって実装が異なることがあります（表３）。

これについては、実際の接続の前に直接VPN機器ベンダに問い合わせるか、事前に接続試験をしておく必要があります。（現在では、以下の "Draft AH" の仕様に準拠しているベンダが多いようです。）

表３認証データの計算時に "0" で埋められるIPv4フィールド

	TOS	断片オフセット	フラグ
RFC1826	-	-	-
S/WAN	0	-	-
Draft AH	0	0	0

※ "S/WAN" は、米RSA Data Security社主催のIPsec相互接続性フォーラムでの解釈
※ "Draft AH" は、draft-ietf-ipsec-auth-header-06.txt での定義

(2) 新旧仕様の実装の違い

認証ヘッダと暗号ペイロードにはRFC1826/1827の仕様と、改訂版（Internet Draft）の２つの仕様が存在しています。これらは第６章で説明した通り、そのフォーマットが異なっているため、相互に接続することができません。

現在のほとんどのIPsec対応機器はRFC1826/1827の仕様に準拠していますが、将来に新しいドラフトの仕様に準拠した機器も混在してくることが予想されます。

仮に受信側が両方の仕様を実装していたとしても、送信側がどちらの仕様で送ってきているのかを判断する手段が明確でなく、正しく処理されないという問題があります。（セキュリティ・アソシエーションのパラメータとして、仕様のバージョンを追加するということも考えられます）

7.3 暗号の輸出規制の影響

以前は，金融機関を除き、共通鍵暗号方式は鍵長 40bit 相当の強度の暗号までしか米国からの輸出が認められていませんでした。しかし、1997年から「データリカバリ（キーリカバリ）」とよばれる技術を実装した製品を開発することを承諾すれば 2年に限り（1999年1月1日まで）、DES 56bit 相当の暗号の輸出が認められるようになりました。

現在のVPN機器は米国で開発されているものが多いのですが、日本に輸入されるものは暗号の強度の低いバージョンが多く、十分にその機能を利用できないといった問題があります。

（注：最近では、128bitの鍵長のものでも輸出が許可される例がでてきているようです。）

8. さらなる学習のために

これまでの説明で、VPNの利用形態と基本的な仕組み、IPsecの仕組みと機能、そして、IPsecを利用する際の注意点について理解されたことと思います。

残念ながら、この他にIPsecについて詳しく取り上げている書籍はあまりないのが現状です。IPsecについてさらに詳細に知りたい方は、第2.1章で列挙したRFCやInternet Draftを直接参照することをお勧めします。また、IPsecに関連するRFCについては、和訳を用意してありますので、こちらを参照いただければさらに理解が深まることと思います。

また、IPsecの標準化動向について知りたい方は、IETFのIP Security Protocol Working Groupのメーリングリストに参加することをお勧めします。こちらは、ipsec-request@tis.com から申し込むことができます。詳細については、IP Security Protocol Working Groupのページ http://www.ietf.org/html.charters/ipsec-charter.html を参照して下さい。

Learning IPsec

はじめに

目次