暗号アジリティとプロトコルのバージョン交渉

暗号アジリティとは何か：アルゴリズムを資産でなく「設定」にする

暗号アジリティ（crypto-agility）とは、使用する暗号アルゴリズムを後から差し替えられるようにプロトコルとシステムを設計する原則です。RSA や AES のような特定のアルゴリズムをコードに埋め込むのではなく、プロトコルの中で識別子（暗号スイートやアルゴリズム ID）として扱い、交渉で選ぶ――この一段の抽象化が要になります。

なぜ必要かといえば、暗号アルゴリズムは必ず老いるからです。計算機の高速化、解読法の進歩、そして将来の量子計算機により、いま安全なアルゴリズムもいつか危殆化（compromise）します。MD5 や SHA-1、輸出グレードの 512 ビット RSA/DH、DES はすべて実際に破られ、退役しました。アジリティが無い設計――たとえば証明書フォーマットや署名検証コードに単一アルゴリズムを固定した実装――は、危殆化したときプロトコルごと作り直すしかなくなります。

暗号スイート交渉：共通集合から1つを選ぶ

TLS を例にとると、クライアントは接続開始の ClientHello で「自分が対応する暗号スイートの一覧」を、優先順位を付けて送ります。スイートは鍵交換・認証・暗号化・ハッシュの組み合わせに識別子を割り当てたもので、たとえば TLS_AES_128_GCM_SHA256 のように表されます。サーバーは自分の対応集合と照合し、共通する中から1つを選んで ServerHello で返す――これが交渉の基本形です。

ClientHello  -> cipher_suites = [強いスイート, ..., 弱いスイート]   # クライアントの対応一覧
                                                  選択
ServerHello  <- cipher_suite  = サーバーが選んだ1つ

ここで本質的な弱点が生まれます。「共通集合から選ぶ」という仕組みは、両端が弱いアルゴリズムも持っていれば弱い方が選ばれ得る点です。後方互換のために古いスイートを残すと、その古いスイートが攻撃の入口になります。さらに厄介なのは、交渉メッセージそのものが、まだ鍵が確立する前に平文で飛ぶことです。中間者（MITM）はこの平文の一覧を観測・改ざんできます。

ダウングレード攻撃：FREAK と Logjam の原理

ダウングレード攻撃は、この交渉の隙を突いて両端を弱いアルゴリズムへ意図的に引きずり下ろす手口です。代表例が 2015 年に公表された FREAK と Logjam で、どちらも 1990 年代の**輸出規制（export-grade）**の名残を悪用しました。当時の米国は国外向けに鍵長を 512 ビット程度に制限したスイートを規定しており、それが何十年もサーバー実装に残っていたのです。

FREAK は輸出グレードの RSA（RSA_EXPORT、512 ビット鍵）を標的にしました。MITM がサーバーへの応答を細工し、クライアントに「サーバーは弱い 512 ビット RSA を使う」と信じ込ませます。512 ビットの合成数は当時すでに数時間〜数日で因数分解可能だったため、攻撃者は一時鍵を破り、セッションを復号・改ざんできました。

Logjam は同じ構図を Diffie-Hellman 鍵交換に適用したものです。MITM が ClientHello を書き換え、サーバーに DHE_EXPORT（512 ビット DH）を選ばせます。DH のダウングレードがとりわけ危険だったのは、多くのサーバーが同じ素数（共通の DH パラメータ）を使い回していた点です。攻撃者は事前に一般数体ふるい（NFS）の重い前計算を一度だけ行えば、その素数を使う全セッションを安価に破れました。鍵交換の原理は Diffie-Hellman 鍵交換 でも触れたように離散対数の困難性に依存しますが、512 ビットではその困難性が崩れていたのです。

ネゴシエーション完全性：交渉を後から認証する

ダウングレードを構造的に防ぐ鍵が、ネゴシエーション完全性――交渉で何を合意したかを、鍵確立後に改ざんされていないと確認できる仕組みです。TLS は世代を経てこれを強化してきました。

TLS 1.2 では Finished メッセージがハンドシェイク全体（ClientHello から直前までの全メッセージ）のハッシュを含む値を、確立した鍵で計算して交換します。もし MITM が途中で ClientHello を書き換えていれば、両端が計算するハッシュが食い違い、Finished の検証に失敗して接続が切れます。理屈の上ではこれでダウングレードを検知できるはずでした。問題は、輸出グレードの弱い鍵自体が即座に破れたため、攻撃者が正しい Finished を偽造できてしまった点です。完全性チェックは正しくても、それを支える鍵が弱ければ無意味になります。

TLS 1.3 はこの教訓から、設計を根本的に作り直しました。第一に、弱いスイートと静的 RSA 鍵交換を規格から削除し、前方秘匿性のある (EC)DHE のみを残しました（脆弱な選択肢が無ければダウングレードの行き先も無い）。第二に、サーバーは CertificateVerify でそれまでの全ハンドシェイクメッセージのハッシュ（transcript hash）に署名します。MITM が交渉を1ビットでも書き換えれば、この署名検証が失敗します。署名鍵は証明書に紐づくため、攻撃者は正しい署名を作れません。さらに TLS 1.3 は、旧バージョンへのダウングレードを検知するため、サーバーが選んだ ServerHello のランダム値の末尾に特定の番兵（sentinel）値を埋め込む仕組みも持ち、新クライアントが「本当は 1.3 が使えたのに 1.2 へ落とされた」状況を見抜けるようにしています。

PQC ハイブリッド移行：アジリティの実地試験

暗号アジリティが真価を問われるのが、いま進行中のポスト量子暗号（PQC）への移行です。将来の量子計算機が現れる前に、鍵交換を量子耐性のある方式へ差し替える必要があります。ここでも単純な「総入れ替え」は危険で、ハイブリッド方式が現実解になっています。

shared_secret = KDF( ECDH(X25519) || Decaps(ML-KEM) )
# 古典(X25519) と PQC(ML-KEM) の両方を破らないと鍵が漏れない

クライアントとサーバーは、古典的な X25519 と格子ベースの ML-KEM の両方の共有鍵を結合（KDF で混合）してセッション鍵を導きます。新しい ML-KEM に未知の実装バグや解読法が見つかっても古典側が守り、量子計算機が登場しても PQC 側が守る――どちらか一方が破れても安全という冗長性です。この移行で重要なのは、ハイブリッド鍵交換もまた新しい暗号スイート識別子（たとえば X25519MLKEM768）として交渉に乗せられる点で、まさに暗号アジリティの「追加」能力が働いています。詳しい原理は ポスト量子暗号 を参照してください。

まとめ

暗号アジリティは、アルゴリズムをハードコードせず識別子として交渉し、追加・削除でき、差し替え境界を局所化する設計原則です。アルゴリズムは必ず老いるため、これが無いと危殆化のたびにプロトコルごと作り直すことになります。

交渉の落とし穴は「共通集合から選ぶと最弱に引きずられる」こと、そして「交渉内容が認証されないと MITM が弱い方へダウングレードできる」ことでした。FREAK（512 ビット RSA）と Logjam（512 ビット DH、共有素数の前計算）は、輸出グレードの残骸とネゴシエーション完全性の欠如を突いた実例です。

対策の核は交渉全体を強い鍵と署名で事後認証すること。TLS 1.3 は弱い選択肢を規格から排除し、transcript hash への証明書署名でハンドシェイク全体を覆ってダウングレードを封じました。同じネゴシエーション完全性が、X25519+ML-KEM のハイブリッドによる PQC 移行の安全も支えます。交渉を守る AEAD は AEAD の設計原理、量子移行の全体像は ポスト量子暗号、運用面は 鍵管理ライフサイクル を合わせて押さえてください。