TLS 1.3 ハンドシェイクの内部と鍵導出

1.3 が「速くて安全」になった理由

TLS 1.2 までのハンドシェイクは、暗号スイートを合意してから鍵交換用の値を交換するため、実データの前に 2往復（2-RTT） が必要でした。TLS 1.3（RFC 8446）はこの構造を作り替え、クライアントが最初の ClientHello で 鍵共有の材料を投機的に同梱 します。サーバーはそれを使って即座に鍵を導出できるため、ハンドシェイクは 1往復（1-RTT） で完了します。

この投機が成立するのは、TLS 1.3 が鍵交換方式を ECDHE（楕円曲線 Diffie-Hellman、一時鍵）に事実上限定 し、選択肢を絞ったからです。RSA 鍵交換や静的 DH は仕様から削除され、前方秘匿性（Forward Secrecy）が 常に保証 されます。基礎は /network/tls/ を、土台のトランスポートは /network/tcp-udp/ を参照してください。

1-RTT ハンドシェイクの順序

-> はクライアント送信、<- はサーバー送信を表します。{} 内はハンドシェイク鍵で暗号化されたメッセージです。

->  ClientHello
      + key_share        (client の ECDHE 公開値 g^x)
      + supported_groups (X25519, secp256r1 ...)
      + signature_algorithms
<-  ServerHello
      + key_share        (server の ECDHE 公開値 g^y)
    {EncryptedExtensions}
    {Certificate}        サーバー証明書チェーン
    {CertificateVerify}  ハンドシェイク全文への署名
    {Finished}           HMAC によるトランスクリプト検証
->  {Finished}
->  [Application Data]    アプリ鍵で暗号化

ポイントは、ServerHello 以降のメッセージが すでにハンドシェイク鍵で暗号化 されることです。証明書すら平文では流れません。CertificateVerify はそれまでの全メッセージ（トランスクリプト）に対する署名で、Finished はトランスクリプトのハッシュに対する HMAC です。これにより、途中でメッセージが改ざんされていない（ダウングレード攻撃を含む）ことが相互に検証されます。

ECDHE：共有秘密の作り方

ECDHE では、両者が一時的な秘密値（クライアント x、サーバー y）と、それに対応する公開値を持ちます。曲線上の生成元を G として、公開値はそれぞれ x*G と y*G です。互いの公開値に自分の秘密を掛けると、同じ点に到達します。

client: (y*G) を受け取り、x を掛ける  -> x*y*G
server: (x*G) を受け取り、y を掛ける  -> x*y*G
共有秘密 = x*y*G の x 座標（= ECDH shared secret）

x*y*G は両者の手元でだけ計算でき、ネットワークには x*G と y*G しか流れません。盗聴者が両公開値を見ても、離散対数問題のため x や y を復元できず、共有秘密に到達できません。秘密値 x,y は接続ごとに使い捨てるため、後でサーバーの長期秘密鍵が漏れても過去のセッションは復号できません（これが前方秘匿性の根拠）。

HKDF による鍵スケジュール

ECDHE が生む共有秘密は、それ自体では鍵に使いません。TLS 1.3 は HKDF（RFC 5869）の2段構成で、用途ごとの鍵を 段階的に 導出します。

• HKDF-Extract(salt, ikm)：入力鍵材料 ikm から固定長の擬似乱数鍵を「抽出」する
• HKDF-Expand-Label(secret, label, transcript, len)：抽出した鍵を、ラベルとトランスクリプトを混ぜて用途別に「展開」する

鍵スケジュールは3つの Secret を順に連鎖させます。前段の出力が次段の salt になる構造です。

Early Secret      = HKDF-Extract(salt=0,              ikm=PSK or 0)
Handshake Secret  = HKDF-Extract(salt=deriv(Early),   ikm=ECDHE 共有秘密)
Master Secret     = HKDF-Extract(salt=deriv(Handshake),ikm=0)

各 Secret から Expand-Label で実際のトラフィック鍵を導出:
  client_handshake_traffic_secret  (EncryptedExtensions 以降の暗号化)
  server_handshake_traffic_secret
  client_application_traffic_secret (Finished 以降の実データ)
  server_application_traffic_secret

トラフィック鍵には常に トランスクリプトのハッシュ が混ぜ込まれます。そのため、ハンドシェイクの内容が1ビットでも違えば導出される鍵が変わり、攻撃者がメッセージを差し替えると鍵が一致せず Finished の検証に失敗します。鍵導出と完全性検証が同じトランスクリプトに束ねられているのが TLS 1.3 設計の核心です。

0-RTT：往復ゼロの再接続

一度ハンドシェイクしたサーバーとは、再開のための PSK（事前共有鍵） を NewSessionTicket で受け取れます。次回クライアントは ClientHello に PSK 由来の情報を載せ、その PSK から導いた early_traffic_secret で 最初のアプリデータを ClientHello と同時に送れます。これが 0-RTT で、往復はゼロです。

ただし 0-RTT データは ECDHE の新鮮な交換を経ておらず、サーバー側に「これは初めて見る送信か」を判定する状態がありません。攻撃者が 0-RTT パケットを記録して 再送（リプレイ） すると、サーバーは同じ要求を二度処理しうります。

TLS 1.2 との差異

実務で確認するコマンド

# ネゴシエート結果（バージョン・暗号スイート・鍵交換曲線）を確認
openssl s_client -connect example.com:443 -servername example.com </dev/null \
  | grep -E "Protocol|Cipher|Server Temp Key"

# TLS 1.3 を明示して接続できるか試す
openssl s_client -connect example.com:443 -tls1_3 </dev/null

# セッションチケット（0-RTT/再開の材料）が払い出されるか観察
openssl s_client -connect example.com:443 -tls1_3 -sess_out sess.pem </dev/null

Server Temp Key 行に X25519 や P-256 が出れば ECDHE が使われている証拠です。鍵共有から HKDF の鍵スケジュールまで一本の流れとして捉えると、TLS 1.3 が「速さ」と「前方秘匿性」を両立できる理由が見えてきます。HTTP/3 が採用する QUIC はこの 1-RTT/0-RTT 設計を取り込んでいるため、/network/http-versions/ と併せて読むと理解が深まります。