Diffie-Hellman Key Exchange

Diffie-Hellman鍵交換（DH鍵交換）とは、通信を行う2者が安全でない通信路を通じて、共通の秘密鍵を安全に共有するための暗号プロトコルです。1976年にWhitfield DiffieとMartin Hellmanによって発表され、公開鍵暗号の概念を世界に初めて示した画期的な発明として知られています。

共通鍵暗号（AESなど）を使った暗号通信を行うには、送信者と受信者が同じ秘密鍵を共有する必要があります。しかし、秘密鍵そのものを通信路で送信すると盗聴されるリスクがあります。Diffie-Hellman鍵交換は、この「鍵配送問題」を数学的に解決します。盗聴者が通信内容をすべて傍受しても、共有された秘密鍵を計算で求めることができない仕組みを実現しています。

現在、DH鍵交換はTLS/SSL、IPsec VPN、SSH、Signal Protocol、WireGuardなど、インターネットの暗号通信基盤のほぼすべてで使用されています。特に楕円曲線を用いたECDHE（Elliptic Curve Diffie-Hellman Ephemeral）は、TLS 1.3の必須アルゴリズムとして、日々数十億の接続を保護しています。

DH鍵交換の数学的原理

Diffie-Hellman鍵交換の安全性は、離散対数問題（DLP：Discrete Logarithm Problem）の計算困難性に基づいています。大きな素数pと、その原始根（生成元）gが公開パラメータとして与えられたとき、g^x mod p からxを求めることは、pが十分大きければ現在のコンピュータでは実質的に不可能です。

DH鍵交換のプロトコルは以下の手順で行われます：

• 準備：大きな素数pと生成元gを公開パラメータとして事前に合意する
• 秘密値の生成：AliceはランダムにaをBobはランダムにbを秘密値として選ぶ
• 公開値の交換：AliceはA = g^a mod pを、BobはB = g^b mod pを相手に送信する
• 共有秘密の計算：AliceはB^a mod p = g^(ab) mod pを、BobはA^b mod p = g^(ab) mod pを計算する
• 結果：両者とも同じ値 g^(ab) mod p を得る。これが共有秘密鍵となる

盗聴者はA = g^a mod p と B = g^b mod p を傍受できますが、これらからg^(ab) mod pを計算するには離散対数問題を解く必要があり、計算量的に困難です。この問題はCDH問題（Computational Diffie-Hellman Problem）と呼ばれています。

ECDHE（楕円曲線Diffie-Hellman Ephemeral）

ECDHEは、Diffie-Hellman鍵交換を楕円曲線上で実装し、さらに一時的（Ephemeral）な鍵ペアを使用するバージョンです。従来の有限体上のDH（FFDHE）と比較して、以下の利点があります：

• 短い鍵長：256ビットのECDHEが3072ビットのFFDHEと同等のセキュリティを提供
• 高速な計算：鍵生成と共有秘密の計算が大幅に高速化
• 少ない帯域使用：交換するデータ量が小さく、TLSハンドシェイクが効率的

TLS 1.3では、鍵交換にECDHE（X25519またはP-256）の使用が必須となり、従来のRSA鍵交換やstatic DH鍵交換は廃止されました。X25519（Curve25519ベース）が最も推奨される鍵交換方式で、高速かつサイドチャネル攻撃への耐性が高い設計が特徴です。

Perfect Forward Secrecy（PFS）

Perfect Forward Secrecy（前方秘匿性 / PFS）は、サーバーの長期秘密鍵が将来漏洩しても、過去の通信内容を復号できないことを保証するセキュリティ特性です。DH鍵交換でPFSを実現するには、セッションごとに一時的（Ephemeral）な鍵ペアを生成・使用し、セッション終了後に破棄する必要があります。

PFSが重要な理由は明確です。従来のRSA鍵交換では、サーバーのRSA秘密鍵が漏洩すると、過去に傍受・保存していたすべての暗号通信を復号できてしまいます。これは「Harvest now, decrypt later（今収穫して、後で復号する）」攻撃として知られ、国家レベルの攻撃者が大量の暗号通信を保存しておき、鍵入手後に一括で復号するシナリオです。DHE/ECDHEによるPFSはこの脅威を根本的に排除します。

DHグループと安全なパラメータ

従来のDH鍵交換では、使用する素数pと生成元gの組み合わせを「DHグループ」と呼びます。安全なDHグループの選択は暗号の安全性に直結します：

• RFC 3526グループ：IETFが標準化したMODPグループ。2048ビット（Group 14）、3072ビット（Group 15）、4096ビット（Group 16）など
• RFC 7919グループ：TLS用に標準化されたffdhe2048、ffdhe3072、ffdhe4096グループ
• NIST ECDHEグループ：P-256、P-384、P-521（楕円曲線ベース）
• X25519 / X448：Daniel J. Bernstein設計の楕円曲線。TLS 1.3で推奨

各プロトコルでの利用

TLS/SSLでは、TLS 1.2以降でECDHE鍵交換が標準となり、TLS 1.3ではECDHE（またはFFDHE）が唯一の鍵交換方式です。これにより、すべてのTLS 1.3接続がPFSを提供します。

IPsec VPNでは、IKE（Internet Key Exchange）プロトコルのフェーズ1でDH鍵交換が使用されます。VPNトンネルの確立時に、安全な共通鍵を確立するための基盤技術です。IKEv2ではECDHEグループもサポートされています。

SSHでは、セッション鍵の確立にDH鍵交換（diffie-hellman-group-exchange-sha256）またはECDHE（curve25519-sha256）が使用されます。OpenSSH 6.7以降ではcurve25519-sha256がデフォルトとなっています。

Signal Protocolでは、Double Ratchetアルゴリズムの中でECDH鍵交換を繰り返し実行し、メッセージごとに新しい暗号鍵を生成することで、極めて高いForward Secrecyを実現しています。

• 01
  ECDHEの優先採用：従来の有限体DH（FFDHE/DHE）よりもECDHEを優先して使用してください。特にX25519が最も推奨されます。ECDHEは同等のセキュリティをより短い鍵長で提供し、計算も高速です。TLS 1.3ではX25519が事実上の標準鍵交換方式となっています。レガシーシステムとの互換性が必要な場合のみFFDHEを検討してください。
• 02
  従来DHの最低鍵長2048ビット：有限体DH（FFDHE）を使用する場合、パラメータのビット長は最低2048ビット以上を使用してください。1024ビット以下のDHグループは、Logjam攻撃などにより既に安全とは言えません。長期的なセキュリティが求められるシステムでは3072ビット以上を推奨します。768ビットや512ビットのDHグループは即座に廃止すべきです。
• 03
  標準DHグループの使用：独自のDHパラメータを生成するのではなく、RFC 3526やRFC 7919で定義された標準グループを使用してください。独自パラメータは生成時の不備（素数の品質不足など）によりセキュリティが低下するリスクがあります。また、標準グループはプリコンピュテーション攻撃の対象になり得るものの、十分なビット長であれば現時点で安全です。
• 04
  Ephemeral鍵によるPFSの確保：DH鍵交換では必ず一時的（Ephemeral）な鍵ペアを使用し、セッションごとに新しい鍵を生成してください。Static DH（固定の秘密鍵を再利用する方式）はPerfect Forward Secrecyを提供しないため、長期秘密鍵の漏洩時に過去のすべての通信が復号されるリスクがあります。TLS設定ではDHEまたはECDHE暗号スイートのみを有効化してください。
• 05
  中間者攻撃への対策：DH鍵交換自体は通信相手の認証を行わないため、中間者攻撃（MITM）に対して脆弱です。必ずデジタル証明書やデジタル署名による相手認証と組み合わせて使用してください。TLSではサーバー証明書がこの役割を果たしています。認証のないDH鍵交換（Anonymous DH）は絶対に使用してはいけません。
• 06
  Export暗号スイートの完全無効化：TLS/SSLサーバーにおいて、512ビットDHを使用するExportグレードの暗号スイート（DHE_EXPORT）を完全に無効化してください。これらは1990年代の米国暗号輸出規制時代に導入されたもので、現在では数秒で解読可能です。Logjam攻撃はこのExport暗号スイートへのダウングレードを悪用したものでした。