境界防御の終焉と、パケットの現場で戦う暗号アルゴリズムの選択
ゼロトラストアーキテクチャが叫ばれ、社内ネットワークという「安全神話」が崩れ去った現代においても、拠点間を結ぶ、あるいはリモートワーカーを安全に社内リソースへと誘うためのIPsec VPNは、依然としてエンタープライズインフラの堅固な要塞であり続けています。
しかし、パケットキャプチャを開き、インターネットの荒波を越えるESP（Encapsulating Security Payload）パケットのバイナリを眺めたとき、私たちは常に一つの重大な問いに直面します。
――「どの暗号アルゴリズムを選択すべきか？」
長年にわたり王座に君臨してきた AES-CBC と、現代の高速なハードウェアアクセラレーションを前提に設計された認証暗号の星、AES-GCM。この2つのアルゴリズムの選択は、単なるセキュリティ強度の議論にとどまりません。それは、CPUのサイクル、パケットあたりのオーバーヘッド、そして何より、暗号学的な脆弱性に起因する致命的なインシデントを回避するための、インフラアーキテクトとしての極めて重要な決断です。
今回は、パケットレベルの内部挙動、Linuxカーネルの暗号APIの振る舞い、そして現場の泥臭いトラブルシューティングの知見を交えながら、IPsecにおける AES-CBC と AES-GCM の真の姿を解き明かしていきます。
—
1. パケット構造と内部挙動の深掘り：CBC vs GCM
まずは、IPsecのESPパケットがワイヤー上をどのように流れているのか、その構造的な違いから目を背けずに見ていきましょう。
AES-CBC（Cipher Block Chaining）の構造と「パディングの呪い」
AES-CBC は、平文を128ビット（16バイト）のブロックに分割し、前の暗号文ブロックとXORを取ってから暗号化を行う伝統的なモードです。
ここで最大のボトルネックとなるのが 「パディング」 です。AESのブロック長である16バイトの倍数に満たない端数のデータを埋めるため、PKCS#7などのパディング方式が必要になります。
+----------------+----------------+----------------+
| SPI / Sequence | IV (16B) | Ciphertext | ...
+----------------+----------------+----------------+
| ESP Payload |さらに、AES-CBC は「機密性（Confidentiality）」しか提供しません。そのため、完全性（Integrity）を担保するために HMAC-SHA256 などのメッセージ認証コード（MAC）を別途付与する必要があります。
つまり、パケットの処理フローは以下のようになります。
1. 暗号化: 平文を AES-CBC で暗号化する。
2. 認証タグ生成: 暗号文（あるいはESPヘッダーを含む全体）に対して HMAC を計算し、パケットの末尾に付加する。
この「暗号化してから認証する（Encrypt-then-MAC）」アプローチは現代の標準ですが、処理が二段階になるためCPUキャッシュへの負荷が高く、パディングオラクル攻撃などのサイドチャネル攻撃に対する厳密な実装が求められ続けてきました。
AES-GCM（Galois/Counter Mode）の洗練されたAEAD
一方、AES-GCM は AEAD（Authenticated Encryption with Associated Data） と呼ばれるカテゴリに属します。これは、機密性と完全性の保護を単一の数学的プロセスで同時に行う画期的なモードです。
カウンタモード（CTR）を用いてストリーム暗号のように高速に暗号化を行いつつ、ガロア体（$GF(2^{128})$）上の乗算を利用して、認証タグ（通常は16バイト）を瞬時に生成します。
+----------------+----------------+----------------+----------------+
| SPI / Sequence | Salt (4B) | Nonce (8B) | Ciphertext... |
+----------------+----------------+----------------+----------------+
| ESP Payload | Auth Tag (16B) |
+---------------------------------+----------------+AES-GCM の美しさは、パディングが不要である点にあります。データの長さに関わらず、そのままストリームとして処理できるため、ブロック境界を気にする必要がありません。また、パケットサイズが小さく抑えられるため、MTUの制約が厳しい回線やトンネリング環境において非常に有利です。
—
2. パフォーマンスとハードウェアアクセラレーションの現実
「理論上はGCMの方が高速」というフレーズは、教科書やベンダーのホワイトペーパーで耳にタコができるほど聞かされているはずです。しかし、実際のエンタープライズ環境のLinuxルーターやファイアウォール上でパケットを流したとき、何が起きているでしょうか？
AES-NIとCPU命令セットの恩恵
近年のIntelやAMDプロセッサ、さらにはARM64（AWS Gravitonや各種ネットワーク機器のSoC）には、AESの暗号化処理をハードウェアレベルで高速化する専用命令（AES-NI, ARMv8 Crypto Extensions等）が備わっています。
AES-CBC の場合、暗号化自体はAES-NIで高速化されますが、連鎖モード（Chaining）の性質上、前のブロックの暗号化結果が完了しなければ次のブロックの演算を開始できないという本質的な直列依存性（Serial Dependency）が存在します。そのため、マルチコアを使った並列処理の恩恵をパケット単位で受けることが難しくなります。
対して AES-GCM のベースであるカウンタモード（CTR）は、各ブロックの暗号化が独立しています。そのため、CPUのパイプラインやSIMD命令（AVX-512など）をフル活用した並列処理が可能であり、ギガビット・10ギガビット超のトラフィックを処理するインフラにおいて、スループットの差は圧倒的になります。
—
3. 実務で直面するトラブルとコンフィグレーションの最適化
ここからは、現場のインフラエンジニアが頭を悩ませる、強烈に泥臭い実務の話をしましょう。 StrongSwanやLibreSwan、あるいはCisco/JuniperのルーターでIPsecトンネルを構築する際の設定と、トラフィックチューニングの勘所です。
StrongSwanでの設定例：AES-GCMへの移行
もしあなたの環境で、いまだに aes128-sha256-modp2048 のような古き良きCBC構成が動いていて、CPU使用率に悩んでいるならば、以下のように aes128gcm16 への移行を検討すべきです。
/etc/strongswan.conf または ipsec.conf の提案アルゴリズム（proposal）の記述例を見てみましょう。
conn corporate-to-cloud
type=tunnel
auto=start
# 推奨されるIKEv2の暗号スイート（AEADを優先）
ike=aes256gcm16-prfsha256-ecp384,aes128gcm16-prfsha256-ecp256!
# ESP（Child SA）の暗号スイート
# GCMを使用する場合、完全性アルゴリズム（auth）の指定は不要（暗号アルゴリズム名に内包されるため）
esp=aes256gcm16-ecp384,aes128gcm16-ecp256!
left=203.0.113.10
leftid=@hq.enterprise.internal
leftsubnet=10.100.0.0/16
right=198.51.100.20
rightid=@branch.enterprise.internal
rightsubnet=10.200.0.0/16> 実務上の警告: aes128gcm16 の 16 は、認証タグの長さをバイト単位（128ビット）で表しています。機器やOSのバージョンによっては、aes128gcm12（96ビットタグ）を要求する古い実装が存在しますが、セキュリティと衝突耐性の観点から、現代においては 16（128ビット）一択であることを忘れないでください。
MTU、フラグメンテーション、そしてTCP MSS Clampingの罠
AES-GCMやAES-CBCを導入する際、絶対に避けて通れないのが 「パケットサイズの膨張（オーバーヘッド）」 です。
ESPトンネルモードでは、通常のIPパケットにESPヘッダー、IV、パディング、認証タグが追加されます。
- AES-CBC + HMAC-SHA256: オーバーヘッドが大きく、パディングによるサイズ変動もある。
- AES-GCM: オーバーヘッドは比較的予測しやすいが、それでも追加のバイト数が加算される。
結果として、インタフェースの物理MTUが 1500 バイトである場合、IPsecトンネルを通過するパケットが 1500 バイトを超えると、ルーターで断片化（Fragmentation）が発生するか、DF（Don’t Fragment）ビットが立っている場合はパケット破棄（ICMP Destination Unreachable）を引き起こします。
これが、「VPN接続後に特定の重いWebページだけが表示されない（TCPのゼロウインドウやブラックホール現象）」 という、情シス泣かせの古典的かつ深刻なトラブルの正体です。
この問題を根本から防ぐため、Linuxカーネルの iptables / nftables やルーターの設定で、必ず TCP MSS Clamping を適切に設定してください。
# nftablesを用いたTCP MSSの自動クランプ設定例
# パケットの最大セグメントサイズ（MSS）をVPNのオーバーヘッドを考慮して強制的に縮小する
table inet filter {
chain forward {
type filter hook forward priority 0; policy accept;
# SYNパケットを検出し、MSSを1360バイト（例: MTU 1500 - IPsecオーバーヘッド）にクランプ
tcp flags syn tcp option maxseg size set 1360
}
}このワンクッションを入れるだけで、MTU起因のパケットロス地獄から解放されます。インフラ設計の初期段階でこれを忘れると、リリース後に必ず痛い目を見るポイントです。
—
4. 重大な脆弱性の回避：GCMの「Nonce（ナンス）再利用」の恐怖
最後に、セキュリティスペシャリストとして最も強調しておかなければならない「暗号学的リスク」について触れておきます。
AES-GCM は非常に強力ですが、Nonce（Initialization Vectorの一部として使われる一意の数値）が同一のセッション内で重複して使われると、暗号文の安全性は完全に崩壊する という致命的な弱点を持っています。
CBCモードの場合、IVが重複しても、平文のパターンが推測されるリスクはあるものの、GCMのように「平文そのものや認証鍵（GHASHの鍵）が外部に完全に露ロする」という破滅的な状況には至りません。
対策：セッションライフタイムの厳格な管理
IPsec実装（StrongSwanなど）やハードウェアNICのオフロード機能において、長時間の通信（Child SAの更新なし）が行われると、カウンターのロールオーバーやバグによってNonceの重複リスクが高まります。
これを回避するため、エンタープライズ環境では以下のベストプラクティスを必ず適用してください。
1. ライフタイムの短縮: Child SA（ESP）のキーライフタイムを時間単位ではなく、データ量ベース（例: 50GB〜100GBごと）、あるいは短めの時間（例: 1時間ごと）で強制的に再鍵交換（Rekey）させる。
2. ハードウェアとカーネルのバグパッチ: 特に安価なネットワーク機器や古いLinuxカーネルのIPsecオフロードドライバでは、Nonceの生成ロジックに脆弱性が潜んでいた事例が過去に報告されています。OSやファームウェアは常に最新のセキュリティパッチを適用してください。
# strongswan.confでのRekey設定の例
conn corporate-to-cloud
# 1時間、または50GB転送ごとに鍵を強制更新し、Nonceの枯渇・重複を防ぐ
keyingtries=%forever
ikelifetime=3h
lifetime=1h
dpdaction=restart
dpdtimeout=120s—
まとめ：次世代インフラに向けた選択の基準
パケットの挙動、CPUの負荷、そしてセキュリティのトレードオフを俯瞰したとき、私たちが取るべきロードマップは明確です。
- 現代の標準（First Choice）: 最新のCPU命令セット（AES-NI等）が利用可能であり、十分なセキュリティガバナンス（適切なRekey設定）が担保されている環境であれば、スループットとオーバーヘッドの面で圧倒的に有利な
AES-GCMを採用するべきです。 - レガシー・リソース制約環境: 暗号アクセラレータを持たない極端な低スペック組み込み機器や、パケット数が少なく安全性が最優先される特殊なクローズド環境においては、堅牢な実績を持つ
AES-CBC + HMACが依然として選択肢に残ります。
ゼロトラストの思想において、ネットワークの境界は消失したと言われますが、その「見えない境界」を暗号化されたパケットで安全につなぎ合わせているのは、ほかならぬ私たちインフラエンジニアが選定したアルゴリズムそのものです。
アルゴリズムの背後にある数学的背景と、カーネル・ハードウェアの挙動を深く理解し、セキュアで高速なネットワーク基盤を構築していきましょう。
コメント