要約

  • TLS 1.3の KeyUpdate で進むのは、一方の送信秘密と相手側の対応する受信秘密である。逆方向は、別の更新メッセージが届くまで同じ世代に残る。
  • 古い秘密を消去すれば、後の世代が漏れても過去の通信を守れる可能性がある。しかし現行秘密から将来世代は計算できるため、更新を繰り返しても侵害後の安全性は戻らない。

「接続の鍵」は一本ではない

鍵更新を一斉交換と考えると、TLS 1.3の状態を取り違える。クライアントからサーバーへ向かうアプリケーション・トラフィックと、その逆方向には別々の秘密がある。それぞれが独自の世代を持ち、一方だけが先に進める。

この仕組みが必要になるのは、AEADの安全性に使用量の上限があるからだ。一つの鍵で保護するrecordが増えれば、機密性や完全性について許容する確率上の境界に近づく。正しくhandshakeしたことは、同じ鍵を無期限に使えるという意味ではない。RFC 8446 は限界に達する前の更新を勧め、RFC 9325 も長寿命接続を使うアプリケーションに更新方針の検討を求める。

以前のTLSには再ネゴシエーションがあった。既存接続の途中で、鍵だけでなく認証や合意事項まで再び動かし得る広い操作だった。TLS 1.3はそれを廃止し、handshake後の仕事を小さく分けた。KeyUpdate はバージョンや暗号スイートを選び直さず、証明書や利用者の意味も変えない。対象はアプリケーション・トラフィックの保護秘密だけである。

境界を運ぶのは旧世代

送信側は KeyUpdate メッセージ自体を現在の旧い送信鍵で暗号化する。そのメッセージより後のrecordから、新しい送信鍵を使う。受信側は現在の受信鍵で更新指示を検証し、それから対応する受信秘密を導出して次のrecordに備える。

この順序のおかげで、切替点は保護されたストリームの中に残る。両者が時計を合わせて推測する必要はない。一方で実装が早く切り替えれば指示を読めず、遅ければ新世代の最初のrecordを開けない。世代は単なる管理画面のフラグではなく、厳密な順序状態である。

update_not_requested なら、更新はその送信方向だけで完結する。update_requested なら、受信した側は自分の KeyUpdate を update_not_requested で返す。そこで初めて逆方向も次代へ進む。最初の一通が両方向を同時に交換するわけではない。

両端が独立に要求を始めれば、メッセージは行き違う。それでも双方は応答しなければならない。ただし未回答の要求がある間に、次の更新要求を重ねてはならない。Finishedより前の KeyUpdate はエラーであり、過剰な更新が無制限の処理を強いないよう上限も必要だ。

前へ進む導出は、後ろだけを閉じる

移行に必要なrecordを処理し終えた後、古い秘密を安全に捨てられる。後日、新しい世代の秘密だけが漏れても、一方向の導出を逆算して古い世代を得ることはできない。過去に記録された暗号文を守るうえで、この消去には実質的な価値がある。

だが現在から未来へは計算できる。現行のトラフィック秘密を知った攻撃者は、正規のendpointと同じ後継秘密を導出できる。KeyUpdate は独立した乱数を注入せず、相手を再認証もしない。既知の枝から新しい葉を伸ばしても、木そのものは秘密にならない。

したがって運用上の分岐は明快だ。AEAD使用量が限界に近づいたなら世代を更新する。現行秘密の流出が疑われるなら接続を終了し、新しいhandshakeで別のエントロピーを得る。侵害対応を「鍵更新済み」という一つの緑色表示に畳み込むと、攻撃者を同じ導出チェーンに残してしまう。

HTTP/2が許したのは意味を変えない更新

HTTP/2では一つの接続に多数のstreamが同居する。途中で接続全体の認証identityを変えると、どのrequestがどのidentityに属するのかを安全に切り分けにくい。このため RFC 9113 は、HTTP/2でTLS 1.3のpost-handshake認証を使うことを禁じる。

対して KeyUpdate は許される。record保護の世代が変わっても、HTTP requestの主体や権限は直接変化しない。複数のstreamは続き、その下にある一方向の暗号状態だけが前進する。権限を狭くした設計だからこそ、多重化と共存できた。

QUICでは境界が違う。RFC 9001 はTLS KeyUpdate メッセージを禁止する。packetの並べ替わりを扱うQUICは、Key Phase bitと確認処理を使って独自に鍵を更新する。目的が同じでも、順序保証されたTLS record向けの手続きが万能とは限らない。

新世代に与えられた狭い権限

KeyUpdate は新しい身元を証明せず、アプリケーションの認可を更新せず、侵害が終わったことも示さない。同じ接続の中で、方向別のトラフィック秘密を管理する仕組みである。

その限定こそ歴史的な意味を持つ。TLS 1.3は再ネゴシエーションのような大きな儀式から、日常の鍵保守を切り離した。使用上は新しい鍵でも、由来は現在の秘密に連なる。この二面性が KeyUpdate の正確な射程である。

出典と限界

本稿は RFC 8446、RFC 9001、RFC 9113、RFC 9325 に基づく。現在の実装率、製品の既定値、普遍的な更新時間・バイト数を示すものではない。