完全前方秘匿性が破れる経路と鍵漏洩の影響範囲

PFS が約束すること、約束しないこと

前方秘匿性（PFS, Perfect Forward Secrecy）の保証は、しばしば過大に理解されています。PFS が言っているのは厳密に一つだけです。長期秘密鍵（サーバーの秘密鍵）が後で漏れても、それ以前に確立した個々のセッション鍵を逆算できない。 これは ECDHE のように、セッションごとに使い捨てのエフェメラル鍵ペアで共有秘密を作り、長期鍵は「相手の認証（署名）」にしか使わない構成で成立します。長期鍵と、実際にデータを暗号化するセッション鍵が数学的に切り離されているのが核心です。

逆に言えば、PFS は次のものを一切守りません。

• セッション鍵そのものの漏洩。エフェメラル鍵や派生したセッション鍵が記録・流出すれば、その通信は読まれる。PFS は鍵の独立性の話であって、鍵を消す保証ではない。
• 能動的中間者。PFS は受動的盗聴者から過去を守るが、リアルタイムで割り込む攻撃者には別問題。
• 将来の通信。長期鍵が漏れた後の新規セッションでは、攻撃者が長期鍵でサーバーになりすませる（認証が破れる）。

つまり PFS は「過去の、受動的盗聴に対する、長期鍵漏洩という一点」を塞ぐピンポイントな性質です。これを踏まえると、PFS を有効にしているのに破れる経路が見えてきます。

破れ方1：セッション鍵の記録（SSLKEYLOGFILE と TLS 可視化機器）

最も直接的な破れ方は、エフェメラルな共有秘密や派生鍵をそのまま外部に書き出すことです。PFS は長期鍵からセッション鍵を逆算させないだけで、セッション鍵が平文で記録されてしまえば無力です。

代表例が SSLKEYLOGFILE です。ブラウザや多くの TLS ライブラリは、デバッグ用にハンドシェイクで導出したシークレット（TLS 1.3 なら client/server handshake traffic secret や application traffic secret）をファイルに追記する機能を持ちます。これと取得済みのパケットキャプチャがあれば、Wireshark は通信を完全に復号します。ECDHE で PFS が効いていても、鍵を別経路で渡しているのだから当然です。

PFS あり通信の復号フロー（鍵ログがある場合）:
  1. 攻撃者/監査者がパケットを記録（暗号文のみ）
  2. クライアント側で SSLKEYLOGFILE にトラフィックシークレットが残る
  3. ファイル + パケット → 復号成功（長期鍵は一切不要）

企業の TLS 可視化（インスペクション）装置も原理は同じで、セッション鍵をデバイスに保持・記録して中身を検査します。PFS は「長期鍵を守れば過去は安全」を意味しません。鍵が触れたメモリ・ファイル・装置すべてが攻撃面です。

破れ方2：RSA 鍵交換の残存（非 PFS スイートのフォールバック）

歴史的に最も深刻な破れ方が、RSA 鍵交換の残存です。TLS の伝統的な RSA key exchange（TLS 1.2 以前の TLS_RSA_WITH_* スイート）では、クライアントが premaster secret を生成し、それをサーバーの RSA 公開鍵で暗号化して送ります。サーバーは自分の秘密鍵で復号する。ここに PFS はありません。

なぜか。premaster secret は長期の RSA 鍵で暗号化されて通信路を流れるため、長期秘密鍵を後で入手した攻撃者は、過去に記録したハンドシェイクから premaster secret を復号し、そこからセッション鍵を再構成できるのです。長期鍵とセッション鍵が直結しているのが RSA 鍵交換 の構造的弱点です。

実務上の罠は、ECDHE を優先設定していても RSA 鍵交換スイートを無効化し忘れることです。古いクライアントとの互換のため TLS_RSA_WITH_AES_* を残すと、そのスイートで握手したセッションだけ非 PFS になり、長期鍵漏洩時にそのトラフィックが遡って復号されます。証明書失効（漏洩判明後の対応）は将来の接続を守るだけで、すでに記録された過去の暗号文には無力です。PFS を本当に効かせるには、サーバー設定で非 PFS スイートを排除し、ECDHE 系（または TLS 1.3 で RSA 鍵交換を構造的に廃した状態）に限定する必要があります。

破れ方3：ログ・メタデータ経由の漏洩

PFS は暗号路の中身を守りますが、鍵や平文が暗号路の外に複製される経路には届きません。これは破れ方1の一般化です。

• アプリケーションログ。復号後の平文（リクエストボディ、認証トークン、セッション ID）をアプリがログに書けば、通信が PFS でもログ漏洩で内容が露出します。これは セッション管理 で扱うセッション ID の取り扱いと地続きの問題です。
• 鍵管理基盤の監査ログ。エフェメラル鍵の生成に使った乱数源やシード、あるいは派生鍵を誤ってログ・トレースに出力する事故。
• TLS 終端の手前/後ろ。ロードバランサや WAF で TLS を終端すると、その内側は平文です。終端点のメモリダンプやサイドカーのキャプチャは、エンドツーエンドの PFS を素通りします。

要点は、PFS の保護境界は「暗号化された通信路」だけだということです。鍵や平文がその境界を越えてログ・ディスク・別プロセスに渡った瞬間、PFS の保証は及びません。設計時は「鍵と平文が物理的にどこに存在しうるか」を列挙し、各所在をゼロ化・暗号化・アクセス制御で守る必要があります。

影響範囲：長期鍵 vs 一時鍵

漏洩した鍵の種類で被害範囲（blast radius）はまったく異なります。これを取り違えると対応を誤ります。

特に見落とされやすいのがセッションチケット鍵（STEK, Session Ticket Encryption Key）です。TLS のセッション再開は、サーバーがセッション状態（再開用の鍵素材）を STEK で暗号化したチケットをクライアントに渡し、後で提示させる方式です。STEK は複数セッションで共有される準長期鍵なので、これが漏れると、その STEK で発行された多数のチケット＝多数の再開セッションがまとめて危険にさらされます。PFS のためにエフェメラル鍵を律儀に使い捨てても、STEK を半年ローテーションせず使い回していれば、そこが事実上の「長期鍵」になり PFS を骨抜きにします。STEK は短寿命・頻繁ローテーションが鉄則です（鍵全体の扱いは 鍵管理ライフサイクル を参照）。

破れ方4：0-RTT 早期データの前方秘匿性欠如とリプレイ

TLS 1.3 の 0-RTT（zero round-trip time）早期データは、性能のために PFS とリプレイ耐性の両方を意図的に犠牲にした機能です。原理から見ると危うさが明確になります。

0-RTT では、クライアントは前回の接続で得た PSK（pre-shared key, 再開用秘密）から導出した early traffic secret で、ハンドシェイク完了を待たずに最初の往復でアプリデータを送ります。問題は二つです。

0-RTT のデータ保護:
  early_secret      = HKDF(PSK)           ← 過去の PSK に依存
  early_traffic_key = derive(early_secret)
  0-RTT データ       = AEAD(early_traffic_key, ...)   ← 新しい DH を経ていない

1. 前方秘匿性がない。 0-RTT データは新しい (EC)DHE 共有秘密を経由せず、過去から持ち越した PSK だけに依存します。よって PSK（や派生元の再開鍵素材）が後で漏れれば、0-RTT で送った早期データは前方秘匿性なしに復号されます。1-RTT 本体データは DH を経るので PFS がありますが、早期データだけは別扱いです。

2. リプレイ可能。 サーバーは 0-RTT データを「ハンドシェイクを完全に検証する前」に受理します。中間者が同じ 0-RTT パケットを複数回サーバーに再送すると、サーバーは各回を独立した正規リクエストとして処理しうる。これは 認証付き鍵交換 が本来提供するリプレイ防止（シーケンス番号・新鮮な乱数）が、最初の片道では成立していないためです。

まとめ

PFS は「長期鍵が漏れても過去の各セッション鍵を逆算できない」という一点の保証であり、それ以上ではありません。だから破れ方はすべて「PFS が守らない領域」に現れます。①セッション鍵を SSLKEYLOGFILE や TLS 可視化装置で記録すれば、長期鍵なしで過去通信が読める。②RSA 鍵交換 は premaster を長期鍵で暗号化するため非 PFS で、スイートを絞り損ねると長期鍵漏洩で過去が遡って復号される。③鍵や平文がログ・終端点・スワップへ複製されれば、PFS の保護境界の外で漏れる。④0-RTT 早期データは PSK 依存で前方秘匿性がなく、かつリプレイ可能。

影響範囲は鍵の種類で逆向きです。長期鍵漏洩は「未来のなりすまし」、エフェメラル鍵漏洩は「その1本の過去」、そして準長期の STEK 漏洩は多数の再開セッションをまとめて巻き込む。PFS を実効的にするには、ECDHE を使うだけでなく、非 PFS スイートの排除・鍵の即時ゼロ化・STEK の短寿命ローテーション・0-RTT の冪等操作限定までを一体で設計する必要があります。鍵の独立性を作る原理は 前方秘匿性とラチェット、鍵全体の寿命管理は 鍵管理ライフサイクル と合わせて押さえてください。