【テクニカル・上級編】 IPsec VPNにおけるPerfect Forward Secrecy（PFS）の概念 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

鍵の「過去」を切り捨てる覚悟：IPsec VPNにおけるPerfect Forward Secrecy（PFS）の深淵

ネットワークエンジニアの諸君、今日もVPNトンネルの向こう側で蠢く脅威と戦っていることだろう。

多くの現場で「IPsec VPNは繋がってしまえば安心」という神話が未だにまかり通っている。だが、もし君が構築したVPNゲートウェイの長期鍵（Pre-Shared Keyや、それを保護する公開鍵）が、半年後に何らかの物理的アクセスやメモリダンプ攻撃で漏洩したとしたらどうなるか？

過去数ヶ月分のキャプチャデータが、まるで平文であるかのように復号される。そんな悪夢を防ぐための唯一の防波堤が、今回語る Perfect Forward Secrecy (PFS：完全転送秘密) だ。

—

PFSの正体：DHグループが担う「エフェメラル」な交換

PFSの本質を一言で言えば、「セッション鍵の生成を、長期鍵（認証用鍵）の数学的依存関係から切り離す」ことにある。

通常、IKEフェーズ1で確立された鍵を使ってIKEフェーズ2（IPsec SA）の鍵を導出すると、フェーズ1の鍵が破られた瞬間に全てが雪崩のように崩壊する。しかし、PFSを有効にすると、フェーズ2の鍵交換のたびに、再度DH（Diffie-Hellman）鍵交換をやり直す。

このとき行われるのは、使い捨て（Ephemeral）の鍵ペアによる計算だ。たとえ攻撃者が数ヶ月後の未来で長期鍵を手に入れたとしても、その時点で既に破棄されている「過去の使い捨て鍵」の数学的痕跡を遡ることは、計算理論的に不可能に近い。

パケットレベルで何が起きているのか

PFSを有効にすると、Quick Mode（IKEv1）あるいは CREATE_CHILD_SA（IKEv2）のネゴシエーション中に、新たなDH公開鍵の交換が行われる。

PFSなし: フェーズ1の鍵から派生した素材のみで鍵生成。
PFSあり: KE（Key Exchange）ペイロードが追加され、新たなDH公開鍵が交換される。

通信のオーバーヘッドは増える。パケット数が増え、CPUは数学的演算にリソースを割く。しかし、ゼロトラストの時代、エンドポイントが信頼できない前提に立つならば、このコストは「保険料」ではなく「必須の機能」だ。

—

実践：StrongSwanにおけるPFS最適化

現場で最も普及している StrongSwan を例に取ろう。ここで重要なのは、計算コストの低い ECP（楕円曲線暗号）グループの選択だ。レガシーな modp（MODPグループ）は計算が重い上に脆弱性が指摘されがちだ。

/etc/ipsec.conf の設定例を見てほしい。

conn my-secure-vpn
    # フェーズ1の暗号化設定
    ike=aes256gcm16-prfsha384-ecp384!
    
    # フェーズ2の暗号化設定
    esp=aes256gcm16-ecp384!
    
    # PFSを有効化。ecp384を指定することで計算負荷を抑えつつ高い安全性を確保
    pfs=yes
    dh-group=ecp384
    
    # 再鍵化の最適化
    # PFSを有効にすると頻繁に鍵交換を行うため、ライフタイムを適切に設定する
    keylife=1h
    rekeymargin=15m

パフォーマンスチューニングの極意

PFSを有効にすると、再鍵化（Rekeying）時のCPUスパイクが無視できなくなる。高負荷なゲートウェイでは、以下のチューニングを併用するのが鉄則だ。

1. AES-NIの活用: CPUの暗号化支援命令セットが有効か、grep aes /proc/cpuinfo で確認せよ。これがないハードウェアでのPFS運用は自殺行為だ。
2. TCP MSS Clamping: IPsecのオーバーヘッドによりMTUが小さくなるため、TCPハンドシェイク時に MSS を絞り、断片化によるRTT増大を防ぐ。

# iptablesでのMSS調整例
    iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

3. キューイングの最適化: カーネルの sysctl でTCPバッファを広げ、パケットロス時の再送効率を向上させる。

# /etc/sysctl.conf への追記例
    net.ipv4.tcp_rmem = 4096 87380 16777216
    net.ipv4.tcp_wmem = 4096 65536 16777216

—

結論：なぜ我々は「面倒」を選ぶのか

PFSの設定は、管理の手間と計算リソースを確実に消費する。しかし、エンタープライズの境界防御において、「漏洩を前提とする」ことこそがゼロトラストの第一歩だ。

長期鍵が漏洩したとき、君のネットワークは「単なる設定ミス」で崩壊するのか、それとも「過去の通信は守り切った」というプロの矜持を見せられるのか。その差は、今日この設定を投入するかどうかにかかっている。

パケットが暗号化され、その鍵が使い捨てられ、痕跡を残さず消えていく――。そんなネットワークの美しさを、諸君のインフラで体現してほしい。

技術は嘘をつかない。ただ、正しく実装されたか否かを、静かに問い続けているだけだ。