【実務・中級編】 AES-GCM暗号化アルゴリズムの仕組みとIPsec/OpenVPNでの実装 – サイバーセキュリティとプライバシー保護実践ガイド

はじめに：なぜ今、エンジニアがAES-GCMとVPNの暗号化を直視すべきなのか

おい、そこの君。週末にカフェのフリーWi-Fiにつないで、平然と本番環境のKubernetesクラスタへ kubectl を叩いたり、機微な顧客データを扱うWeb APIのエンドポイントをデバッグしたりしてないだろうな？

「HTTPS（TLS 1.3）を使っているからパケットの中身は見られない」――確かにその通りだ。だが、トランスポート層以下、あるいはパブリッククラウド間のVPCピアリングやリモートワーカーからのアクセスにおいて、VPNがどのようにトラフィックを包み込んでいるか、その「包み紙」の強度を意識したことはあるか？

インフラ運用やWeb APIの設計に携わるシニアエンジニアであれば、「とりあえずOpenVPNやIPsecを設定しておけば安全」というフェーズはとうに過ぎていることを知っているはずだ。ゼロトラストアーキテクチャが叫ばれる現代において、私たちが扱うデータは常に「信頼できないネットワーク」の荒波にさらされている。そのデータを守る現代の暗号化の要（かなめ）こそが、今回深掘りする AES-GCM（Advanced Encryption Standard – Galois/Counter Mode） だ。

今回は、パケットが暗号化回路を駆け抜け、どのようにカプセル化され、宛先へとルーティングされるのか。その裏側の数学的・実装的メカニズムを、現場のトラブルシューティングの知見を交えて徹底的に解説しよう。

—

1. AES-GCMとは何か？：機密性と完全性の同時達成

従来の暗号モード、例えば古くから使われてきたCBC（Cipher Block Chaining）モードでは、機密性（暗号化）を担保するためにAESを使い、データの改ざん検知（完全性）を行うためにはHMAC（Hash-based Message Authentication Code）などを別途組み合わせる必要があった。

これの何が問題か？パフォーマンスのオーバーヘッド、そして実装ミスの温床になることだ。「暗号化してからMACを計算するのか、その逆か（Encrypt-then-MAC vs MAC-then-Encrypt）」といった議論で夜を明かしたシニアも多いだろう。

そこで登場したのが AEAD（Authenticated Encryption with Associated Data：認証付き暗号） というパラダイムであり、その代表格が AES-GCM だ。

ガロア/カウンタモードの仕組み

AES-GCMは、以下の2つの要素が美しく融合して成り立っている。

1. カウンタモード（CTR）: ブロック暗号をストリーム暗号のように扱えるモード。プレーンテキストをブロック単位に分割せず、カウンタ値から生成したキーストリームと排他的論理和（XOR）を取ることで暗号化を行う。並列処理（パイプライン処理）が非常に得意で、ハードウェアアクセラレーション（AES-NI等）との相性が抜群に良い。
2. ガロアモード（GMH: Galois Message Authentication Code）: GHASH関数を用いて、ガロア体（$\text{GF}(2^{8})$）上の乗算ベースで認証タグ（Auth Tag）を生成する。これにより、暗号文だけでなく、平文のままヘッダー等に付与されるAAD（Associated Data）の改ざんも同時に検知できる。

この仕組みにより、AES-GCMは「1つのアルゴリズムで、超高速な暗号化と強力な改ざん検知を同時に行う」という、インフラエンジニアにとって夢のような特性を実現しているのだ。

—

2. IPsecとOpenVPNにおけるAES-GCMの実装とパラメータ

では、このAES-GCMが、実際のVPNプロトコル（IPsecおよびOpenVPN）でどのように設定され、パケットを保護しているのかを見ていこう。

IPsec（IKEv2 / ESP）でのAES-GCM

IPsecのデータ転送を担うESP（Encapsulating Security Payload）プロトコルでは、AES-GCMは強力な武器となる。IPsecでは通常、暗号化アルゴリズムと認証アルゴリズムを別々に指定するが、AES-GCMの場合は両方を兼ねるため、トランスフォーム提案（Transform Proposal）の記述がシンプルになる。

以下は、強いセキュリティが求められる環境における、実用的なStrongSwan（IPsec実装）の設定ファイル（ipsec.conf）の断片だ。

# /etc/ipsec.conf の設定例（AES-GCMによる強固な暗号化）
conn corporate-vpn-gcm
    keyingtries=%forever
    dpdaction=restart
    dpddelay=30s
    
    # IKEv2フェーズ1（ISAKMP SA）の設定：合意形成と認証
    ike = aes256gcm16-prfsha384-ecp384!
    
    # IKEv2フェーズ2（Child SA）の設定：実際のデータ転送用暗号スイート
    # aes256gcm16 は AES-256 と 128ビット（16バイト）の認証タグを使用することを意味する
    esp = aes256gcm16-ecp384!
    
    left=%defaultroute
    leftauth=pubkey
    leftcert=server.crt
    right=%any
    rightauth=pubkey
    auto=add

ここで注目してほしいのが、aes256gcm16 というパラメータだ。末尾の 16 は認証タグの長さをバイト単位で表している（128ビット）。IPsecの文脈では、このタグがパケットの末尾に付加され、途中のルータや悪意あるアタッカーによるビットフリップ攻撃（改ざん）をミリ秒単位で検知・ドロップする。

OpenVPN（TLSモード）でのAES-GCM

一方、TLSをベースにしたレイヤー3/2 VPNであるOpenVPNでも、AES-GCMは広く採用されている。かつては BF-CBC や AES-256-CBC がデフォルトだったが、現代のOpenVPN 2.4以降では AES-256-GCM が標準推奨となっている。

以下は、OpenVPNのサーバー側設定ファイル（server.conf）の暗号化関連セクションの記述例だ。

# /etc/openvpn/server.conf の暗号化・認証設定

# データの暗号化および認証にAES-256-GCMを指定（AEADによりHMACディレクティブが不要になる）
cipher AES-256-GCM

# 認証アルゴリズムの明示的な指定は不要（GCM自身が認証を含んでいるため）
# auth SHA256  <- AES-GCM使用時は不要。設定すると逆にエラーや非効率になる場合がある。

# TLSハンドシェイクで使用する暗号スイートの制限（TLS 1.3を強制し、GCM系を優先）
tls-cipher TLS-AES-256-GCM-SHA384:TLS-CHACHA20-POLY1305-SHA256

# リプレイ攻撃を防ぐためのパケットIDカウンタの有効化
# GCMモードではIV（初期化ベクトル）の管理が極めて厳密である必要がある

—

3. 現場でハマる罠：AES-GCMの「IV（初期化ベクトル）の重複」という悪夢

ここで、私が過去にプロダクション環境のトラブルシューティングで冷や汗をかいた、AES-GCMの最大の急所について共有しておこう。

AES-GCMは非常に強力だが、「同じ鍵（Key）と同じ初期化ベクトル（IV）のペアで、絶対に2回以上暗号化を行ってはならない」 という鉄の掟がある。

CTRモードの性質上、もし同一のIVが再利用されてしまうと、生成されるキーストリームが完全に一致してしまう。これが何を意味するか？悪意ある第三者が2つの暗号文のXORを取るだけで、元の平文が丸裸になってしまうのだ。IPsecやOpenVPNのパケットカウンタがリセットされたり、クラッシュ後の再起動でカウンタの永続化に失敗したりすると、この致命的なIV衝突（IV Reuse）が引き起こされる。

デバッグとパケットキャプチャの現場

もし、VPN経由の通信で特定のパケットがデコードできなくなったり、通信がランダムに切断される怪現象に遭遇したら、tcpdump や Wireshark を使ってESPパケットのシーケンス番号（Sequence Number）やIKEv2のSA（Security Association）ライフタイムを疑うべきだ。

# 特定のインターフェースでIPsec（ESPプロトコル: 50）のトラフィックをキャプチャする現場コマンド
sudo tcpdump -i eth0 -nn esp -vv

パケット解析の際、WiresharkのAES-GCM復号機能を使うためには、セッション確立時のキーマテリアル（IKEv2のデバッグログから抽出したSK_d, SK_ei, SK_erなど）が必要になる。インフラのセキュリティ監査やフォレンジックの現場では、このIVのシーケンス管理が正常に行われているかを確認することが、プロとしての腕の見せ所となる。

—

4. Web API設計・インフラ運用者への実務的ティップス

最後に、日々のWeb API設計やインフラ運用において、私たちがこの知識をどう活かすべきか、具体的な提言をいくつか残そう。

1. TLS終端とサービスメッシュの暗号化の選択:
Kubernetes環境でIstioやLinkerdなどのサービスメッシュを導入する際、mTLS（相互TLS）の暗号スイートとして TLS_AES_256_GCM_SHA384 がデフォルトで選択されていることを確認してほしい。CPUがAES-NIをサポートしている現代のサーバーであれば、パフォーマンスの低下を気にすることなく、最高レベルの機密性をサービス間通信に適用できる。
2. 古い暗号スイートの完全排除:
NginxやApache、あるいはロードバランサー（AWS ALB/ELBなど）の設定において、古いCBCモードやRC4、3DESなどのレガシーなアルゴリズムは、セキュリティポリシー（例: CIS Benchmarks）に従って容赦なく無効化すること。
3. アプリケーション層での追加暗号化（必要に応じ）:
「ゼロトラスト」の思想に基づけば、たとえVPNやTLSでセキュアに保護されたネットワーク内であっても、データベースの特定のカラム（クレジットカード番号や個人情報など）は、アプリケーション層（Web API）で個別にAES-GCMを使ってフィールド単位で暗号化（Application-Layer Encryption）しておくのが、真に堅牢なエンタープライズアーキテクチャである。

—

おわりに

AES-GCMは、単なる「暗号化のアルゴリズムの一つ」ではない。それは、複雑化するサイバー脅威の中で、私たちのシステムが信頼の境界線を維持するための、最も信頼できる数理的防壁の一つだ。

教科書通りの設定をなぞるだけではなく、「なぜこのパラメータが必要なのか」「パケットの裏側でどのような数学的処理とハードウェアの挙動が行われているのか」を理解しているエンジニアこそが、障害時に冷静に原因を特定し、組織を救うことができる。

さあ、今日の業務に戻るとしよう。君の構築するネットワークとWeb APIが、堅牢な暗号のベールに守られ、安全なデータ通信を続けられることを祈っている。