2026年のポスト量子暗号への移行：開発チームのための計画

要点：2026年には、通信経路上の暗号化に関するポスト量子対応の大部分が、アップグレードだけで完了します。Chrome、Firefox、Apple のバージョン 26 の各 OS、OpenSSL 3.5、Go 1.24 以降、JDK 27、OpenSSH 10 は、デフォルトでハイブリッド ML-KEM 鍵交換をネゴシエートします。やるべきことは、まだそうなっていない接続を見つけることです。古いライブラリ、固定されたグループリスト、ミドルボックス、TLS 1.2、VPN、内部サービスなどが該当します。時間がかかるのは署名と証明書のほうです。公開 CA はまだブラウザー向けの ML-DSA 証明書を発行できません。そのため、今のうちに棚卸しを行い、プライベート PKI で ML-DSA を試験導入し、アルゴリズムを容易に切り替えられる設計にしておきます。計画の基準となる日付は、NIST のドラフト IR 8547 に示されたものです。RSA-2048 などの 112 ビットの鍵は 2030年より後に非推奨となり、量子コンピューターに対して脆弱なすべての公開鍵アルゴリズムは 2035年より後に使用禁止となります。NSA の CNSA 2.0 は、米国の国家安全保障システムに対して、より早い期限を定めています。

時間軸が異なる 2 つの問題

暗号を破れる規模の量子コンピューターが実現すれば、ショアのアルゴリズムによって RSA、有限体上のディフィー・ヘルマン、楕円曲線暗号（ECDH、ECDSA、EdDSA）が破られます。共通鍵暗号とハッシュは、現在の鍵長のまま、つまり AES-256 と SHA-256、またはそれ以上のサイズで安全性を保てます。そのような量子コンピューターがいつ実現するかは、誰にもわかりません。OpenSSH のプロジェクトページは、公表されている予測を「5〜20 年後で、多くの識者は 2030年代半ばに登場すると予想している」とまとめています。移行は、緊急度が大きく異なる 2 つの問題に分かれます。

• 機密性（急を要する）：今日記録された暗号化通信は、量子コンピューターが実現した時点で解読できるようになります。これが harvest now, decrypt later（今収集し、後で解読）です。数年以上秘密にしておかなければならないものは、鍵交換が従来型であれば、すでに危険にさらされています。対策はポスト量子鍵交換で、今日すぐに導入できます。
• 認証（期限がある）：偽造された署名が問題になるのは、誰かがそれを信頼したときだけです。つまり、その時点で量子コンピューターが存在していなければなりません。ただし、署名鍵とトラストアンカーは長期間使われます。ルート証明書、ファームウェアの鍵、コード署名鍵、アーカイブされた署名付き文書は数十年にわたって信頼され、それらの置き換えには何年もかかります。

作業はこの順序で計画してください。まず鍵交換、次に署名です。

実際に定められている期限

この表について、注意すべき点が 3 つあります。

1. IR 8547 はまだドラフト：2030年と 2035年という日付は、政府機関やベンダーが計画の基準にしているものですが、まだ NIST の最終的なポリシーではありません。ドラフトでは、「非推奨（deprecated）」はリスクを受け入れればそのアルゴリズムを引き続き使用できることを、「使用禁止（disallowed）」は一切使用できないことを意味します。
2. 2030年の段階で対象になるのは 112 ビットの鍵、とりわけ RSA-2048：RSA-2048 は今も多くの証明書で使われ、トークンを署名する多くのシステムでも使われています（後述のスキャンでは、6 つのエンドポイントのうち 2 つが使用）。P-256 と RSA-3072 は 128 ビットで 2035年まで使い続けられますが、これらに移行しても稼げるのは最大 5 年です。ドラフトは、2035年より後は量子コンピューターに対して脆弱なものをすべて使用禁止としているからです。
3. ハイブリッドには CNSA 2.0 の脚注が重要：ハイブリッドモードは認められていますが、CNSA 2.0 のアルゴリズムは「所定の日付で選択が必須になる」ため、従来型のみの設定は認められなくなります。

すでにデフォルトでポスト量子対応になっているもの

次のコンポーネントは、両端が十分に新しければ、設定なしでハイブリッド ML-KEM 鍵交換をネゴシエートします。

サーバー側も移行が進んでいます。2026年10月20日に、インベントリの節のスクリプトを使って OpenSSL 3.5.7 からスキャンした結果は次のとおりです。

www.cloudflare.com:443     TLSv1.3  X25519MLKEM768    id-ecPublicKey 256 bit    ecdsa-with-SHA256
github.com:443             TLSv1.3  X25519,253bits    id-ecPublicKey 256 bit    ecdsa-with-SHA256
www.google.com:443         TLSv1.3  X25519MLKEM768    id-ecPublicKey 256 bit    ecdsa-with-SHA256
login.microsoftonline.com:443 TLSv1.3  ECDH,secp384r1    rsaEncryption 2048 bit    sha256WithRSAEncryption
api.stripe.com:443         TLSv1.3  X25519,253bits    rsaEncryption 2048 bit    sha256WithRSAEncryption
letsencrypt.org:443        TLSv1.3  X25519,253bits    id-ecPublicKey 256 bit    ecdsa-with-SHA384

注目すべきは 2 つの列です。鍵交換はまちまちで、ハイブリッドを使うサービスもあれば、使わないサービスもあります。証明書の列は一様に従来型で、ECDSA P-256 か RSA-2048 です。SSH でも状況は同じで、GitHub は OpenSSH 10 のクライアントに対してすでにハイブリッドを選択しています。

debug1: kex: algorithm: mlkem768x25519-sha256

ステップ 1：インベントリの作成

一覧にできないものは移行できません。役に立つ暗号インベントリでは、公開鍵暗号の用途ごとに、アルゴリズムと鍵長、使用しているライブラリとそのバージョン、設定の管理者、保護対象のデータの機密性を保つべき期間、鍵や署名を信頼し続けるべき期間がわかります。

まずは、外部から計測できるもの、つまり TLS エンドポイントから始めます。

#!/bin/bash
for target in "$@"; do
  host=${target%:*}; port=${target##*:}; [ "$host" = "$target" ] && port=443
  out=$(openssl s_client -connect "$host:$port" -servername "$host" -brief </dev/null 2>&1)
  proto=$(grep -m1 "^Protocol version" <<<"$out" | cut -d: -f2 | xargs)
  group=$(grep -m1 "^Negotiated TLS1.3 group" <<<"$out" | cut -d: -f2 | xargs)
  [ -z "$group" ] && group=$(grep -m1 "^Peer Temp Key" <<<"$out" | cut -d: -f2 | cut -d, -f1-2 | tr -d ' ')
  cert=$(openssl s_client -connect "$host:$port" -servername "$host" </dev/null 2>/dev/null | openssl x509 -noout -text 2>/dev/null)
  key=$(grep -m1 "Public Key Algorithm" <<<"$cert" | cut -d: -f2 | xargs)
  bits=$(grep -m1 -o -E "\([0-9]+ bit\)" <<<"$cert" | tr -d '()')
  sig=$(grep -m1 "Signature Algorithm" <<<"$cert" | cut -d: -f2 | xargs)
  printf '%-26s %-8s %-17s %-25s %s\n' "$host:$port" "$proto" "$group" "$key $bits" "$sig"
done

このスクリプトは、OpenSSL 3.5 のクライアントで実行しなければなりません。それより古いクライアントはハイブリッドを提示しないため、どのサーバーも従来型に見えてしまいます。多数のドメインをまとめて確認するなら、ドメイン一括チェッカーがホストごとに鍵交換、証明書のアルゴリズム、有効期限を表示します。

次に、内部に目を向けます。作業の大部分はこちらにあります。

• ライブラリとランタイム：すべてのイメージとすべてのホストについて、OpenSSL、BoringSSL、Go、JDK、.NET、Node.js、Python のバージョンを一覧にします。OpenSSL 3.0 はアップストリームのサポートが終了しており、ML-KEM も搭載していませんが、Ubuntu 24.04 には今もこのバージョンが同梱されています。この事実だけで、多くの結果の説明がつきます。
• 明示的な設定：ssl_ecdh_curve、SSLOpenSSLConfCmd Groups、CurvePreferences、jdk.tls.namedGroups、KexAlgorithms といったグループや暗号方式のリストを検索します。どれも、アップグレードによるデフォルトの変更が及ばない箇所です。
• コード：RSA、ECDSA、ECDH、Ed25519 の API の直接利用、鍵長、JWT の alg の値、データベースに保存された公開鍵を検索します。データ形式の中に保存された署名は、後から変更するのが最も難しい部分です。
• 長期間使われる鍵と証明書：プライベート CA のルート、コード署名鍵とファームウェアの鍵、文書署名、SSH の CA、HSM に保管された鍵。それぞれの有効期限と、HSM が対応しているアルゴリズムを記録します。
• ベンダー：ロードバランサー、WAF、TLS を検査するプロキシ、VPN コンセントレーター、マネージドデータベース、SaaS の API。各ベンダーに、ML-KEM と ML-DSA のロードマップを書面で求めます。

結果は機械可読な形式で記録します。CycloneDX は、まさにこの目的のために暗号部品表（CBOM）を追加しました。CBOM は、アルゴリズム、鍵、証明書、プロトコルをソフトウェアインベントリのコンポーネントとして記述するもので、すでに生成しているかもしれないパッケージの SBOM と並べて扱えます。

ステップ 2：鍵交換の移行を完了する

自分で管理している TLS の終端ポイントごとに、次の作業を行います。

1. TLS ライブラリをアップグレードする：OpenSSL 3.5、Go 1.24 以降、JDK 27、または最新の BoringSSL や AWS-LC のビルドを使います。
2. 固定されたグループリストを削除するか、リストの先頭に X25519MLKEM768 を置きます。古いガイドからコピーした堅牢化のための設定行は、最新のサーバーが単なる X25519 をネゴシエートしてしまう最もよくある原因です。仕組みは X25519MLKEM768 の解説で説明しています。
3. 実際のネットワーク経路を通してテストする：ハイブリッドの ClientHello は約 1.5 KB です。ファイアウォール、ロードバランサー、TLS を検査するプロキシの中には、2 つのパケットにまたがる ClientHello を処理できないものがあります。サーバーを疑う前に、同じ経路でハイブリッドのハンドシェイクと従来型のみのハンドシェイクを比較してください。
4. 両方の区間を確認する：CDN やロードバランサーの背後では、エッジからオリジンへの接続は別の TLS セッションです。この区間で記録された通信も、同じように収集され、後で解読される対象になります。
5. 可能な箇所では TLS 1.2 を廃止する：ハイブリッドのグループは TLS 1.3 でのみ定義されています。

次に、Web 以外の通信経路です。

• SSH：OpenSSH 9.0 以降は、両端が対応していれば、すでにポスト量子ハイブリッドをネゴシエートします。古いサーバー、ネットワークアプライアンス、組み込みの SSH スタックは、多くの場合対応していません。OpenSSH 10.1 以降のクライアントは、リスクを明示した警告「This session may be vulnerable to 'store now, decrypt later' attacks.」を表示します。
• VPN と IPsec：IKEv2 は追加の鍵交換（RFC 9370）をサポートしており、ベンダーはこれを使って ML-KEM を追加しています。ゲートウェイのファームウェアのリリースノートを確認してください。
• アプリケーションレベルの暗号化：エンベロープ暗号化、暗号化されたバックアップ、エンドツーエンドのメッセージングなど、データ鍵を RSA や ECDH でラップするものにはすべて、ML-KEM またはハイブリッド KEM の経路が必要です。ハイブリッド KEM と組み合わせた HPKE（RFC 9180）が一般的な構成要素です。HPKE プレイグラウンドで、各要素がどのように組み合わさるかを確認できます。

ステップ 3：署名と証明書

こちらは、まだエコシステムが代わりに対応してくれる段階にないため、2026年の作業は準備が中心です。

• 公開 Web 証明書は待ちつつ備える：公開 CA が発行した ML-DSA 証明書を受け入れるブラウザーはありません。Chrome は 2026年2月に、ポスト量子の鍵を持つ X.509 証明書をルートストアに追加する当面の予定はないと表明しました。Chrome は、IETF の PLANTS ワーキンググループで標準化が進むマークルツリー証明書（Merkle Tree Certificates）を中心に、別個の耐量子ルートストアを構築しています。それが実現するまでは、自動化に取り組むのが有益です。どの証明書も数分でローテーションできるチームなら、アルゴリズムも容易に切り替えられます。証明書の有効期間の短縮も、同じ方向への後押しになります。
• プライベート PKI では今すぐ ML-DSA を試験導入する：内部の mTLS、サービスメッシュ、デバイスの ID、VPN の証明書は、両端とも自分で管理できます。OpenSSL 3.5、Go 1.27、Java 24 以降、.NET 10、BouncyCastle は、いずれも ML-DSA の鍵と証明書を扱えます。ML-DSA-65 ではリーフ証明書が約 5.5 KB になることを見込み、バッファーサイズ、ヘッダーの上限、HSM の対応状況など、何が動かなくなるかをテストしてください。開発者のための ML-DSA で、動作するコードと鍵の形式に関する落とし穴を紹介しています。
• 長期間使われるトラストアンカーを優先する：2026年に作成したルート鍵やファームウェアの鍵は、2035年より後も信頼され続けます。ファームウェアとソフトウェアのアップデートの署名について、CNSA 2.0 はステートフルなハッシュベースの方式である LMS または XMSS（SP 800-208）を要求し、2030年までの排他的使用を求めています。署名の状態を管理できない場合は、ステートレスな SLH-DSA（FIPS 205）が保守的な代替手段になります。
• 検証可能な状態を保つ必要がある署名済みアーティファクト：現在 ECDSA で署名されている文書、アーカイブ、ログは、その署名が信頼できなくなる前に保護し直さなければなりません。PDF の長期検証が期限切れになる証明書に対してすでに行っているように、タイムスタンプの更新とアーカイブの再署名を計画してください。
• トークンと API：JOSE と COSE には ML-DSA のコードポイントがあります（RFC 9964）。3.3 KB の署名によって JWT は base64url で約 4.5 KB になり、Cookie やヘッダーでは問題になります。切り替える前に計測してください。

ステップ 4：次の変更を低コストにする

移行は一度の切り替えでは終わりません。ハイブリッド鍵交換は、いずれ ML-KEM 単体に置き換わるかもしれません。ML-DSA には、NIST が FIPS 206 として策定を予定している FN-DSA が加わるかもしれません。複合署名とハイブリッド署名は、まだ設計段階にあります。こうした変更のたびに新たな複数年がかりのプロジェクトが発生するのを防ぐのが、クリプトアジリティです。

• アルゴリズム識別子（OID、JOSE の alg、バージョンバイト）がデータとともに受け渡され、検証者は決め打ちせずにその識別子に基づいて処理を振り分けます。
• 鍵長と署名サイズはハードコードしません。カラム、バッファー、プロトコルのフィールドには、キロバイト単位のデータが入る余裕を持たせます。
• 鍵の生成、保管、ローテーションは自動化で行います。人が PEM ファイルを設定にコピーすることはありません。
• 設定はスタックごとに 1 か所にまとめ、次にグループやアルゴリズムを変更するときは 1 回の編集で済むようにします。

よくある間違い

• 古いクライアントでテストする：OpenSSL 3.0 の openssl s_client や、それにリンクされた curl は、ハイブリッドを一切提示しません。そのため、すでに移行済みのサーバーも含め、すべてのサーバーが従来型に見えてしまいます。
• CDN のエッジを接続全体とみなす：ブラウザーからエッジまでの区間はポスト量子であることが多い一方、同じリクエストでもエッジからオリジンまでの区間はそうなっていません。
• 不具合のあるミドルボックスに対処するためにハイブリッドを無効にする：これでは、すべての接続から保護が失われます。その機器を修正するか、交換してください。
• 公開 ML-DSA 証明書が登場するまで何もしない：インベントリの作成、ライブラリのアップグレード、証明書の自動化はいずれにしても必要で、しかも待つ期間よりも長くかかります。
• 「2030年より後は非推奨」を「2035年までは使用可」と解釈する：2029年に従来型の鍵交換で暗号化したデータは、機密性を保つべき期間全体にわたって危険にさらされます。期限はコンプライアンスのためのものであり、安全性のためのものではありません。

2026年の残りの期間に向けたチェックリスト

1. 公開・内部のすべての TLS エンドポイントを OpenSSL 3.5 でスキャンし、グループ、証明書のアルゴリズム、ライブラリのバージョンを記録します。
2. ベースイメージの TLS ライブラリをアップグレードします。固定されたグループリストを削除します。再スキャンします。
3. エッジからオリジンまでの区間を含め、経路上のすべてのミドルボックスを通してハイブリッドをテストします。
4. ML-KEM に対応するため、SSH サーバーを OpenSSH 9.9 以降にアップグレードします（9.0 以降はすでに sntrup761 ハイブリッドを提供しています）。ネットワークアプライアンスも、ファームウェアが提供されていればアップグレードします。
5. 長期間使われるすべての署名鍵とトラストアンカーを、有効期限と、HSM が対応しているアルゴリズムとともに一覧にします。
6. ML-DSA のテスト用 CA を立ち上げ、1 つの内部サービスに証明書を発行します。
7. 証明書の発行とローテーションが今も手作業になっている箇所は、すべて自動化します。
8. ベンダーに、ML-KEM と ML-DSA への対応時期を書面で問い合わせます。

出典

• NIST IR 8547（初期公開ドラフト）『ポスト量子暗号標準への移行』（2024年11月）、表 2〜4
• NSA、商用国家安全保障アルゴリズムスイート 2.0 の発表（CSA PP-22-1338、2022年9月）：アルゴリズムと移行スケジュール
• ポスト量子暗号への移行に向けた協調実施ロードマップ、EU PQC ワークストリーム、バージョン 1.1、2025年6月11日
• NCSC、ポスト量子暗号への移行のタイムライン（2025年3月）
• FIPS 203、FIPS 204、FIPS 205、SP 800-208
• OpenSSH のポスト量子暗号のページと、OpenSSH 9.0、9.9、10.0、10.1 のリリースノート
• OpenSSL のリリース戦略（3.5 LTS は 2030年4月8日まで）。Go 1.24 のリリースノート、JEP 527
• Google セキュリティブログ、堅牢で効率的な耐量子 HTTPS の育成（2026年2月）

スキャンは 2026年10月20日に、node:24.22.0-trixie（OpenSSL 3.5.7、OpenSSH 10.0p2）から実行しました。