なぜ今さらIPsecの「暗号アルゴリズム」を語るのか？――AES-GCM vs AES-CBC の決定的分岐点
現場でバリバリとWeb APIのバックエンドやインフラを触っているエンジニア諸君、お疲れ様。突然だが、君たちがクラウドとオンプレミスを繋ぐIPsecトンネルを構築する際、プロポーザル設定で「なんとなく推奨されているから」という理由で AES-GCM を選んではいないだろうか。あるいは、レガシーな装置の互換性維持のために、思考停止で AES-CBC を使い続けてはいないか。
ゼロトラストアーキテクチャが叫ばれる昨今、ネットワークの境界は消失したと言われるが、それでも拠点間接続やテレワークのインフラとしてIPsecは現役の「壁」だ。この壁を支える暗号アルゴリズムの選択は、単なるスペックの比較じゃない。それは、君たちのアプリケーションが叩き出すスループットや、パケットロス発生時の挙動を左右する「実務的な生命線」なんだ。
今日は、教科書には載っていない（載っていても読み飛ばされる）、この二つのアルゴリズムの「中の動き」に焦点を当てて解説しよう。
—
1. AES-CBC：かつての王者が抱える「逐次処理」の限界
AES-CBC (Cipher Block Chaining) は、長らくIPsecの標準だった。仕組みは直感的だ。前のブロックの暗号文を次のブロックの暗号化に利用する。これによって、同じ平文でも毎回異なる暗号文が生成される。
しかし、実務において AES-CBC には致命的な弱点がある。それは「完全性保護（Integrity）」のために別途 HMAC（SHA-256など）が必要になるという点だ。
CBCの通信フロー（実務的視点）
1. 暗号化: データを AES-CBC で暗号化する。
2. 認証: 暗号化されたデータに対して HMAC を計算し、MAC（Message Authentication Code）を付与する。
3. 検証: 受信側で HMAC を再計算し、一致しなければパケットを破棄する。
ここで発生するのが「二重のオーバーヘッド」だ。CPUは暗号化とハッシュ計算を別々に行わなければならない。特に高スループットなWeb API通信において、この処理の重さは CPU Load に直結する。さらに悪いことに、CBC は並列処理ができない。前のブロックが終わらないと次へ進めないからだ。
—
2. AES-GCM：現代のインフラに不可欠な「AEAD」の真価
一方、現代のインフラにおける救世主が AES-GCM (Galois/Counter Mode) だ。これは AEAD (Authenticated Encryption with Associated Data) と呼ばれる方式で、「暗号化」と「認証（改ざん検知）」を一つのプロセスで同時にやってのける。
なぜGCMが圧倒的に速いのか？
AES-GCM は内部的に CTR (Counter Mode) をベースにしている。CTR はブロックごとに独立して計算できるため、CPUのパイプラインをフル活用した「並列処理」が可能だ。現代のプロセッサが持つ AES-NI 命令セットと組み合わせれば、その速度差は歴然とする。
比較まとめ：
| 特徴 | AES-CBC + HMAC | AES-GCM |
| :— | :— | :— |
| 処理方式 | 逐次処理（遅い） | 並列処理（非常に速い） |
| 完全性保護 | 別途HMACが必要 | 暗号化に内包（AEAD） |
| CPU負荷 | 高い | 低い（ハードウェア支援と相性◎） |
| 実務推奨 | 互換性維持以外は非推奨 | 現在のデファクトスタンダード |
—
3. 実践：強固なIPsecトンネルを定義する
では、実機の設定例を見てみよう。例えば、StrongSwan を使ったLinuxベースのゲートウェイで AES-GCM を採用する場合、以下のように設定する。
# /etc/ipsec.conf の抜粋
conn vpn-to-cloud
# 認証と暗号化をGCMで統合指定する（AEAD）
# aes256gcm16 は 256bitの暗号化 + 128bitのICV(認証タグ)を意味する
esp=aes256gcm16-sha256-modp2048
# 鍵交換にはIKEv2を使うこと（必須！）
ike=aes256gcm16-sha256-modp2048
# ライフタイム設定（短めに設定して定期的に鍵を更新する）
ikelifetime=28800s
keylife=3600sもし、古いネットワーク機器との接続で CBC を使わざるを得ない場合は、以下のように明示的にハッシュ関数を組み合わせる必要がある。
# レガシーな環境でCBCを使用する場合の例
esp=aes256-sha256-modp2048※ ここで sha256 を指定しているのは、md5 や sha1 が既に衝突耐性を失っているためだ。インフラ屋としては、どんなに古くても sha1 は絶対に避けるべきだ。
—
4. エンジニアへのアドバイス：トラブルシュートの現場から
最後に、現場でよくある失敗談を一つ。
AES-GCM を採用した際、通信が不安定になるケースがある。原因の多くは「MTUの不一致」と「ICV（認証タグ）の付与によるパケットサイズ増」だ。
AES-GCM は HMAC を含んだ形でパケットを構築するため、CBC よりもパケットサイズが微妙に大きくなることがある。これが原因で、VPNトンネルを通るパケットがMTU制限に引っかかり、断片化（フラグメンテーション）やパケットロスを引き起こす。
APIのレスポンスが途中で切れる、といった不可解な現象に遭遇したら、まずは以下のコマンドでMSS（Maximum Segment Size）を調整してほしい。
# iptablesでVPNトンネルを通るTCPパケットのMSSをクランプする例
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --clamp-mss-to-pmtu結びに代えて
技術は進化し、かつての「定石」は今の「ボトルネック」になる。AES-GCM への移行は単なる設定変更ではない。それは、君たちのインフラがより安全で、かつ効率的にスケールするための重要な一歩だ。
もし君が今のシステムで AES-CBC を使っているなら、まずは検証環境で AES-GCM に切り替えてパフォーマンスを計測してみるといい。その劇的な変化に、きっと驚くはずだ。
「なぜその設定なのか」を言語化できるエンジニアこそが、真に強いネットワークを守れるのだと、私は信じている。また次の現場で会おう。
コメント