【実務・中級編】 Diffie-Hellman（DH）グループの仕様と暗号強度の比較 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

「そのDHグループ、まだGroup 2で止まっていませんか？」――VPNの要、鍵交換アルゴリズムの深淵を紐解く

ネットワークエンジニアの皆さん、お疲れ様です。深夜の切り替え作業中、VPNトンネルが「IKE Phase 1 failure」で上がらず、冷や汗をかいた経験は誰にでもあるはずです。

多くのエンジニアが「なんとなく動くから」と設定しがちなIKE（Internet Key Exchange）のパラメータ。中でも、VPNの安全性とパフォーマンスの根幹を成すDiffie-Hellman（DH）グループは、セキュリティ設計の要です。今回は、このDHグループの選び方がなぜ重要なのか、現場の視点から深掘りしてみましょう。

1. DHグループは「鍵交換の安全地帯」である

VPNにおいて、通信相手と安全に共通鍵を共有するための仕組みがDH交換です。ここで選ぶDHグループは、離散対数問題という数学的難問をどれくらいの「桁数」で解かせるか、つまり「暗号の解読難易度」を決定します。

Group 2 (1024-bit MODP): 絶滅危惧種です。もし今も現役で動いているなら、今すぐ引退させてください。現代の計算能力では、国家レベルの脅威でなくても解読可能です。
Group 14 (2048-bit MODP): 多くの古い機器で「デフォルト」として設定されていますが、そろそろ卒業の時期です。
Group 19/20/21 (ECP): これが現代のスタンダード。楕円曲線暗号（Elliptic Curve Cryptography: ECC）を採用しており、MODP（素数体）よりも短い鍵長で同等以上の強度を確保できます。計算も高速で、モバイル端末などの処理能力が限られたデバイスにも適しています。

2. 通信の裏側：IKEネゴシエーションのシーケンス

VPNが確立されるとき、パケットは以下のようなやり取りをしています（IKEv2の場合）。

1. IKE_SA_INIT: ここでDH公開鍵を交換し、共通の秘密を生成します。
2. IKE_AUTH: 認証を行い、暗号化通信のトンネルを確立します。

もしDHグループの選択で食い違いがあると、IKE_SA_INIT の応答パケットで NO_PROPOSAL_CHOSEN というエラーが返ってきます。これは「お前の提示したDHグループは脆弱すぎる（あるいはサポートしていない）からお断りだ」という、ネットワーク機器からの無言の拒絶です。

3. 実務的な設定例：Cisco IOSと強固なセキュリティの担保

現場で最もよく見るCisco IOSのIKEv2設定例を挙げます。今時の要件であれば、Group 19（256-bit ECP）以上を推奨します。

! IKEv2の提案リストを作成
crypto ikev2 proposal MY_VPN_PROPOSAL
 encryption aes-cbc-256
 integrity sha256
 group 19  ! ECP 256-bitを選択。Group 14よりも高速かつ強固です
 !
! IKEv2のポリシーに適用
crypto ikev2 policy MY_VPN_POLICY
 proposal MY_VPN_PROPOSAL

ここで重要なのは、「暗号強度と計算コストのバランス」です。Group 21（ECP 521-bit）は非常に強力ですが、古いハードウェアだとCPU負荷が無視できないレベルになることがあります。まずは group 19 で検証し、機器の負荷とスループットを監視するのが「泥臭い」インフラ運用の定石です。

4. Web APIにおけるDHの考え方：TLSとの比較

Webエンジニアの皆さんにとっても、これは無関係ではありません。HTTPSのTLSハンドシェイクも、裏側では同じDH交換を行っています。

curl を使ってサーバーの暗号スイートを確認する際、以下のように実行してDHパラメータを注視してみてください。

# サーバーが対応している暗号スイートをチェック
curl -vI https://api.example.com --tlsv1.3

TLS 1.3では、安全性の低いDHグループはそもそも廃止され、ECDHE（楕円曲線Diffie-Hellman）が強制されています。VPNもこの「標準」に合わせるべきです。コードベースでセキュリティを担保する場合、Pythonの ssl モジュールなどでDHパラメータを固定する設定（context.set_ecdh_curve('secp256r1') など）が、このDHグループの概念に直結します。

5. トラブルシューティングの極意：ログを信じろ

トラブルが起きたとき、慌てて設定をガチャガチャ変更するのは悪手です。まずはログを確認しましょう。

Ciscoの場合: debug crypto ikev2
Linux (StrongSwan) の場合: /var/log/charon.log

ログ内に proposal mismatch や unsupported group といった文字列があれば、それはもうDHグループの不一致で確定です。

最後に：エンジニアとしての矜持

「とりあえずGroup 14で繋がったからOK」で済ませるか、それとも「現代の脅威に対抗するためにGroup 19を採用する」と判断するか。その小さな決定の積み重ねが、組織のセキュリティを支えています。

DHグループの選定は、ただの数字遊びではありません。それは、通信の「秘匿性」という約束を守るための、エンジニアの技術的な良心なのです。

次回のブログでは、今回触れきれなかった「Perfect Forward Secrecy (PFS)」の詳細と、なぜ鍵交換を定期的に行う必要があるのか、その数学的根拠について深掘りしていこうと思います。それでは、良いネットワークライフを！