TLS 1.3鍵交換におけるDiffie-Hellmanプロトコルの詳細

ネットワーク・RFCカテゴリを表すパンダのイラスト ネットワーク・RFC
2026.01.02

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

TLS 1.3鍵交換におけるDiffie-Hellmanプロトコルの詳細

背景

Transport Layer Security (TLS) プロトコルは、インターネット上の通信を暗号化し、セキュアにするための標準技術です。特にTLS 1.3は、その前身であるTLS 1.2以前のバージョンと比較して、セキュリティとパフォーマンスの両面で大幅な改善が図られています。TLS 1.3の最も重要な変更点の一つが、鍵交換メカニズムの簡素化と強化であり、Diffie-Hellman (DH) および楕円曲線Diffie-Hellman (ECDH) プロトコルの利用が中心となっています。

TLS 1.3は、IETFによって2018年8月にRFC 8446として標準化されました。このバージョンでは、旧式の脆弱な機能が多数削除され、より強固な暗号スイートとプロトコルフローが導入されています。

設計目標

TLS 1.3における鍵交換プロトコルの設計目標は以下の通りです。

  1. 前方秘匿性 (Forward Secrecy: PFS) の強制: セッション鍵が常に一時的なDiffie-Hellman鍵交換から導出されるようにし、長期的な秘密鍵が漏洩しても過去の通信の秘密が守られるようにします。

  2. 1-RTTハンドシェイク: 新規接続時のハンドシェイクを、クライアントとサーバー間のメッセージ往復を1回で完了できるようにし、接続確立のレイテンシを削減します。

  3. セキュリティの強化: ダウングレード攻撃やその他の既知の攻撃に対する耐性を高めます。

  4. プロトコルの簡素化: 複雑なオプションを削減し、実装と監査を容易にします。

  5. 0-RTTハンドシェイクのサポート: 以前に接続したことのあるサーバーとの間で、初期のアプリケーションデータをクライアントが1往復なしで送信できるようにし、さらなるレイテンシ削減を目指します。

詳細

TLS 1.3では、鍵交換にDHまたはECDHが必須とされています。これにより、鍵交換フェーズで交換される共有秘密は常に一時的となり、前方秘匿性が保証されます。

Diffie-Hellman (DH) および楕円曲線Diffie-Hellman (ECDH)

DHは、公開チャネルを通じて共有秘密を確立するための暗号プロトコルです。ECDHはDHの楕円曲線暗号版であり、より短い鍵長で同等のセキュリティレベルを達成できるため、計算効率と帯域幅の観点から推奨されます。

TLS 1.3のハンドシェイクでは、クライアントがサポートする鍵共有グループ（ECDH曲線や有限体DHグループ）と、そのグループで生成した公開鍵をClientHelloメッセージのkey_share拡張に含めて送信します。サーバーは、クライアントが提示したグループの中から一つを選択し、自身の公開鍵をServerHelloメッセージのkey_share拡張で返します。両者がこの情報を用いて、それぞれの秘密鍵と相手の公開鍵から共有秘密を計算します。

RFC 8446は、P-256、P-384、P-521などの楕円曲線グループと、ffdhe2048、ffdhe3072などの有限体Diffie-Hellmanグループを推奨しています[1]。

鍵交換の流れ (1-RTTハンドシェイク)

TLS 1.3の鍵交換は、以下のsequenceDiagramで示されるように、効率化されています。

sequenceDiagram
    participant Client
    participant Server

    Client ->> Server: ClientHello (supported_versions, supported_groups, key_share: Client_PK_1, Client_PK_2, ...)
    activate Server
    Server -->> Client: ServerHello (supported_version: TLS 1.3, selected_group, key_share: Server_PK)
    Note over Server: 共有秘密 `Premaster Secret` を計算
ハンドシェイク鍵を導出
    Server ->> Client: ChangeCipherSpec (Optional, for middlebox compatibility)
    Server ->> Client: EncryptedExtensions (ServerName, ALPN, etc.)
    Server ->> Client: Certificate (if authentication required)
    Server ->> Client: CertificateVerify (Signature of handshake transcript)
    Server ->> Client: Finished (MAC of handshake transcript)
    deactivate Server
    activate Client
    Note over Client: 共有秘密 `Premaster Secret` を計算
ハンドシェイク鍵を導出
Server Finishedを検証
    Client ->> Server: ChangeCipherSpec (Optional, for middlebox compatibility)
    Client ->> Server: Finished (MAC of handshake transcript)
    deactivate Client
    Client ->> Server: Application Data (Encrypted)
    Server ->> Client: Application Data (Encrypted)

  1. ClientHello: クライアントは、TLS 1.3をサポートすること、利用可能なDiffie-Hellmanグループのリスト、そして各グループに対する自身の公開鍵（key_share拡張）を送信します。

  2. ServerHello: サーバーは、TLS 1.3を選択し、クライアントが提示したグループの中から一つを選び、そのグループでの自身の公開鍵を返します。

  3. 鍵の導出: クライアントとサーバーは、それぞれ自身の秘密鍵と相手の公開鍵を用いて共通のDiffie-Hellman共有秘密を計算します。この共有秘密とハンドシェイクのトランスクリプト（交換されたメッセージ履歴）を基に、Key Derivation Function (HKDF) を用いて、ハンドシェイク鍵、アプリケーションデータ保護鍵などを導出します。これにより、以後の通信は暗号化されます。

  4. Finished: 両者は、ハンドシェイク全体の整合性を保護するMAC (Finishedメッセージ) を交換し、ハンドシェイクを完了します。

KeyShare拡張の構造

ClientHelloやServerHelloに含まれるKeyShare拡張は、以下のような構造を持ちます。

struct {
    KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;

struct {
    KeyShareEntry server_share;
} KeyShareServerHello;

struct {
    NamedGroup group;
    opaque key_exchange<1..2^16-1>;
} KeyShareEntry;

  • client_shares: クライアントが提示するKeyShareEntryのリスト。複数のグループに対して公開鍵を事前に生成して送ることで、サーバーの選択に応じて1-RTTでの鍵交換を可能にします。

  • server_share: サーバーが選択したグループと、そのグループに対するサーバーの公開鍵を含むKeyShareEntry。

  • NamedGroup: 楕円曲線グループ（例: secp256r1, x25519）または有限体Diffie-Hellmanグループ（例: ffdhe2048）を識別します。

  • key_exchange: Diffie-Hellmanの公開鍵値。

相互運用性

TLS 1.2以前との比較

TLS 1.3の鍵交換は、TLS 1.2以前のバージョンと比べて以下の点が異なります。

  • 前方秘匿性の強制: TLS 1.2では、RSA鍵交換のような前方秘匿性のない鍵交換も許容されていましたが、TLS 1.3ではDiffie-Hellman鍵交換のみが許され、前方秘匿性が強制されます。

  • Cipher Suiteの選定: TLS 1.2では、ClientHelloでクライアントが暗号スイートのリストを提示し、サーバーが一つを選んでいました。TLS 1.3では、暗号スイートの概念が簡素化され、認証・暗号化・ハッシュアルゴリズムの組み合わせで鍵交換メカニズムはDH/ECDHに固定されます。鍵共有グループはkey_share拡張でネゴシエートされます。

  • ハンドシェイクの往復回数: TLS 1.2の完全なハンドシェイクは通常2-RTTを要しましたが、TLS 1.3は1-RTTでのハンドシェイクを基本とします。

0-RTT (Early Data)

TLS 1.3は、リジューム接続時に0-RTT (Zero Round Trip Time) ハンドシェイクをサポートします。これは、過去のセッション情報を持つクライアントが、最初のClientHelloメッセージとともに暗号化されたアプリケーションデータを送信する機能です。これにより、待ち時間がさらに削減されます。

sequenceDiagram
    participant Client
    participant Server

    Client ->> Server: ClientHello (early_data, key_share: Client_PK, ...) + Early Application Data (Encrypted)
    activate Server
    Note over Server: Replay攻撃のリスクを考慮
    Server -->> Client: ServerHello (selected_group, key_share: Server_PK)
    Server ->> Client: EncryptedExtensions
    Server ->> Client: Finished
    deactivate Server
    activate Client
    Client ->> Server: Finished
    deactivate Client
    Client ->> Server: Application Data (Encrypted)
    Server ->> Client: Application Data (Encrypted)

0-RTTはパフォーマンス上の利点がある一方で、リプレイ攻撃のリスクを伴います。サーバーは、同じEarly Dataが複数回処理されないよう、リプレイ保護機構を実装する必要があります。RFC 8446では、サーバーがClientHelloのpsk_identityに対応するチケットのobfuscated_ticket_ageをチェックしたり、Nonceを追跡したりするなどの方法が示唆されています[1]。

セキュリティ考慮

前方秘匿性 (PFS)

TLS 1.3はDiffie-Hellman鍵交換を強制することで、PFSをすべてのセッションで保証します。これにより、サーバーの長期的な秘密鍵（例: 証明書署名鍵）が将来的に漏洩しても、過去の通信内容は解読されません。

ダウングレード攻撃への対策

TLS 1.3は、攻撃者がより古い、脆弱なバージョンのプロトコルへのダウングレードを強制する攻撃を防ぐためのメカニズムを備えています。ClientHelloのsupported_versions拡張によって、クライアントはサポートするTLSバージョンを明示し、legacy_record_versionフィールドは互換性のためのみに設定されます。サーバーは、意図しないダウングレードを防ぐための特定のバイト列をServerHelloのrandomフィールドに含めることで、これを検知する機能を提供します[1]。

リプレイ攻撃 (0-RTTデータ)

前述の通り、0-RTTデータはリプレイ攻撃に対して脆弱です。クライアントが送信した初期アプリケーションデータが、攻撃者によって再度サーバーに送信される可能性があります。RFC 8446は、以下の対策を推奨または言及しています[1]。

  • サーバーサイドのNoncing/リプレイキャッシュ: サーバーは、クライアントから受け取った0-RTTデータに紐づくNonceやチケットステートを追跡し、重複を検出する必要があります。

  • 非リプレイ可能なデータのみを0-RTTで送信: アプリケーション層で、冪等性のあるリクエスト（例: GETリクエスト）のみを0-RTTで許可する設計が望ましいです。

鍵更新メカニズム

TLS 1.3は、長期接続における対称鍵の定期的更新を可能にするKeyUpdateメッセージを提供します。これにより、一度侵害された鍵がセッション全体にわたって悪用されるリスクを軽減します。

実装メモ

推奨されるDHグループ/ECDH曲線

セキュリティとパフォーマンスのバランスから、以下のグループが推奨されます[1]。

  • 楕円曲線Diffie-Hellman: secp256r1 (P-256), secp384r1 (P-384), secp521r1 (P-521), X25519, X448。特にX25519は実装の容易さと優れたパフォーマンスで広く採用されています。

  • 有限体Diffie-Hellman: ffdhe2048, ffdhe3072, ffdhe4096など。

クライアントは、自身の能力とサーバーの一般的なサポートを考慮して、ClientHelloに複数のKeyShareEntryを含めるべきです。

乱数生成の重要性

Diffie-Hellmanの秘密鍵生成には、高品質な乱数生成器が不可欠です。エントロピー源が不十分な場合、秘密鍵が推測され、鍵交換が危険にさらされる可能性があります。

MTU/Path MTU考慮

ClientHelloメッセージは、クライアントが多くのsupported_groupsとそれぞれのkey_share（公開鍵）を含める場合、サイズが大きくなる可能性があります。これにより、TCP/IP層でフラグメントが発生し、パフォーマンス低下やパケットロスにつながる可能性があります。実装者は、ClientHelloのサイズをPath MTU内に収めるように考慮するか、フラグメントへの耐性を高める必要があります。

キュー制御と優先度

TLSハンドシェイク自体は一般に優先的に処理されるべきですが、特に0-RTTデータを含むClientHelloの場合、アプリケーションデータとハンドシェイクメッセージの適切なキュー制御と優先度付けが必要です。ネットワークスタックでハンドシェイクメッセージが遅延すると、接続確立全体が遅れます。

鍵のライフサイクル管理

生成されたDiffie-Hellmanの秘密鍵と共有秘密は、セッション終了後または鍵更新後に安全に破棄されるべきです。これにより、メモリ上の秘密情報が攻撃者に利用されるリスクを低減します。

まとめ

TLS 1.3におけるDiffie-Hellman鍵交換は、前方秘匿性の強制、1-RTTハンドシェイク、そして堅牢なセキュリティ機能を提供することで、現代のインターネットセキュリティの基盤となっています。RFC 8446で規定されるこのプロトコルは、旧来の複雑で脆弱な要素を排除し、より高速かつ安全な通信を実現します。

しかし、0-RTTハンドシェイクにおけるリプレイ攻撃への対策や、ClientHelloのMTU考慮、強固な乱数生成の維持など、実装者には引き続き注意が求められます。これらの点を適切に管理することで、TLS 1.3はその潜在能力を最大限に発揮し、セキュアな通信環境を維持することができるでしょう。

参照: [1] IETF. “The Transport Layer Security (TLS) Protocol Version 1.3”. RFC 8446. 2018年8月. https://datatracker.ietf.org/doc/html/rfc8446

文書情報

記事タイトル
TLS 1.3鍵交換におけるDiffie-Hellmanプロトコルの詳細
作成日
更新日
Source URL
https://papanda925.com/?p=4914

ライセンス: 本記事のうち、当サイトが権利を有する本文・自作図表は、特記なき限り CC BY 4.0 で利用できます。生成AIを活用して作成・編集した内容を含みます。コードについて、別途ライセンス表示またはリンク先GitHubリポジトリのライセンスがある場合は、その条件を優先します。引用・第三者資料・画像・商標等は本ライセンスの対象外です。 利用ポリシー

タイトルとURLをコピーしました