仕組み：Diffie-Hellman鍵交換は「鍵合意」

Diffie-Hellman鍵交換は、直接は共有されない情報から、通信相手と同じ「共通の秘密（以後、鍵素材）」を作り出すための方法です。仕組みの要点は、各当事者があらかじめ決めた計算（公開情報と自分の秘密情報を用いたべき乗など）により、最終的に同じ鍵素材に到達するよう設計されている点にあります。

ここで混同しやすいのが、「鍵交換＝機密情報の保護のすべて」ではないことです。鍵交換が作るのは、以降の暗号通信で使う鍵（あるいは鍵素材）です。機密情報を守る本体は、その鍵を使ってデータを暗号化し、必要なら相手が本当に正しいか（認証）を確認するプロトコル側の設計になります。鍵交換単体が安全であっても、認証や暗号化の組み立てが不十分だと、機密情報を守れない場合があります。

部品：公開情報・秘密情報・計算結果

鍵交換では、次のような役割分担で考えると理解しやすくなります。

  • 公開可能な情報：他者に見られてもよい前提の値（例：グループのパラメータや一部の公開値）
  • 秘密に保持する情報：各当事者だけが保持する値（再現性を持つ秘密）
  • 計算結果：公開情報と秘密情報から計算して得る共有秘密（双方で同じものになるように設計）

重要なのは、第三者が通信を盗み見ても、相手の秘密情報に到達できない設計であることです。ただし、これも「条件付き」です。鍵交換の計算だけが成立しても、相手の公開鍵が改ざんされていないこと、あるいは相手であることを確かめる仕組みが欠けていないことが必要になります。

制限と例外：中間者攻撃は「鍵交換」だけでは防げない

Diffie-Hellman鍵交換で現実に起こりやすい問題は、鍵交換の計算が正しくても「相手が本物か」を確かめないと成立する中間者攻撃です。攻撃者が通信の途中に入り、当事者それぞれと別々に鍵交換を成立させると、当事者同士は暗号化された通信をしているつもりでも、攻撃者がその暗号を解いて別経路で再暗号化できる状況が理論上ありえます。

このため実務では、鍵交換に加えて、公開鍵の検証や相手の真正性を確認する仕組みが必要になります。たとえば次のような考え方です。

  • 相手の公開情報が正しいことを確認する（証明書、既知の公開鍵、信頼された検証経路など）
  • 鍵交換で合意した鍵が、認証の結果と結びついている設計である
  • プロトコルが「鍵合意」と「認証」を一体として扱う

また、鍵交換方式にも制限があります。具体的なパラメータや実装方針は、古い方式や不適切な設定だと安全性が下がります。ここは一律に断言できないため、導入先の要件（どのプロトコルで、どの方式・パラメータを使うか）を確認して判断する必要があります。