performing-post-quantum-cryptography-migration

ポスト量子暗号への移行の実施

使用するタイミング

• NIST のポスト量子暗号への移行に向けて、組織の準備状況を評価するとき
• インフラストラクチャ全体で量子計算機に脆弱なアルゴリズムを特定するため、暗号インベントリを作成するとき
• X25519MLKEM768 鍵交換を使用するハイブリッド TLS 1.3 構成を評価するとき
• CRYSTALS-Kyber（ML-KEM）および CRYSTALS-Dilithium（ML-DSA）のアルゴリズムサポートをテストするとき
• 従来のアルゴリズムとポスト量子アルゴリズムの両方をサポートするため、クリプトアジリティを実装するとき
• NIST IR 8547 の廃止スケジュールに沿った移行ロードマップを準備するとき
• ポスト量子アルゴリズムをサポートするため、OpenSSL 3.x で oqs-provider を構成するとき

前提条件

• cryptography、requests、pyOpenSSL ライブラリを備えた Python 3.8 以降
• OpenSSL 3.0 以降（ネイティブの ML-KEM/ML-DSA サポートには 3.5 以降を推奨）
• 古い OpenSSL でハイブリッド TLS をテストする場合は、OpenSSL 用の oqs-provider
• TLS 評価を行う対象サーバーへのネットワークアクセス
• インフラストラクチャスキャンを行うための管理者権限
• PKI、TLS、暗号プロトコルに関する基礎知識

コアコンセプト

NIST ポスト量子暗号標準

NIST は 2024 年 8 月 13 日に、3 つの確定した PQC 標準を公開しました。

標準	アルゴリズム	改称後	用途	基盤
FIPS 203	CRYSTALS-Kyber	ML-KEM	鍵カプセル化メカニズム	モジュール格子
FIPS 204	CRYSTALS-Dilithium	ML-DSA	デジタル署名	モジュール格子
FIPS 205	SPHINCS+	SLH-DSA	デジタル署名（バックアップ）	ステートレスハッシュ

ML-KEM（FIPS 203） -- 鍵交換と暗号化のための主要標準です。鍵確立において RSA と ECDH を置き換えます。セキュリティレベルは ML-KEM-512、ML-KEM-768、ML-KEM-1024 の 3 種類です。

ML-DSA（FIPS 204） -- デジタル署名のための主要標準です。署名において RSA と ECDSA を置き換えます。セキュリティレベルは ML-DSA-44、ML-DSA-65、ML-DSA-87 の 3 種類です。

SLH-DSA（FIPS 205） -- ハッシュベースの手法を用いたバックアップ署名標準です。格子ベースの ML-DSA に脆弱性が見つかった場合のフォールバックとして想定されています。署名サイズは大きくなりますが、セキュリティの前提はより保守的です。

量子計算機に脆弱なアルゴリズム

以下の従来型アルゴリズムは、Shor のアルゴリズムによる量子攻撃に対して脆弱です。

アルゴリズム	用途	量子の脅威	移行の優先度
RSA-2048/4096	鍵交換、署名、暗号化	Shor のアルゴリズムが素因数分解を破る	重大
ECDH（P-256、P-384）	TLS 鍵交換	Shor のアルゴリズムが ECDLP を破る	重大
ECDSA	コード署名、TLS 証明書	Shor のアルゴリズムが ECDLP を破る	重大
DSA	従来の署名	Shor のアルゴリズムが DLP を破る	重大
DH（Diffie-Hellman）	鍵交換	Shor のアルゴリズムが DLP を破る	重大
AES-128	対称暗号化	Grover のアルゴリズムにより鍵強度が半減する	中（AES-256 へのアップグレード）
SHA-256	ハッシュ	Grover のアルゴリズムにより 128 ビット相当に低下する	低（依然として十分）

NIST 移行タイムライン（IR 8547）

• 2024 年: 標準が公開され、移行の計画を開始すべき時期
• 2030 年: ほとんどの連邦政府システムにおいて、量子計算機に脆弱なアルゴリズムを廃止
• 2035 年: NIST 標準から量子計算機に脆弱なアルゴリズムを完全に削除
• 現在: 「今収集して後で復号する（Harvest now, decrypt later）」攻撃により、長期間機密性を保つ必要がある秘密情報やデータについては、早期の移行が不可欠です

ハイブリッド TLS 鍵交換

移行期間中、ハイブリッド鍵交換では従来型アルゴリズムとポスト量子アルゴリズムを組み合わせます。いずれか一方のアルゴリズムが安全であれば、接続は保護されたままです。

Hybrid Key Exchange: X25519MLKEM768
  = X25519 (classical ECDH) + ML-KEM-768 (post-quantum)

Client Hello:
  supported_groups: X25519MLKEM768, X25519, secp256r1
  key_share: X25519MLKEM768

Server Hello:
  selected_group: X25519MLKEM768
  key_share: X25519MLKEM768

Shared Secret = KDF(X25519_shared || MLKEM768_shared)

手順

フェーズ 1：暗号アルゴリズムのインベントリースキャン

PQC 移行の最初のステップは、組織全体で使用されている暗号アルゴリズムをすべて特定することです。これには、TLS 設定、証明書、コードライブラリ、キーストア、プロトコル設定が含まれます。

# Scan TLS endpoints for quantum-vulnerable algorithms
python scripts/agent.py --action scan_tls \
    --targets targets.txt \
    --output tls_inventory.json

スキャナーは次の項目を特定します。

• 使用中の TLS プロトコルバージョン
• 鍵交換アルゴリズム（RSA、ECDH、DH — いずれも量子コンピューターに脆弱）
• 証明書の署名アルゴリズム（RSA、ECDSA）
• 暗号スイートの設定
• 証明書の鍵サイズと有効期限

フェーズ 2：暗号アジリティの評価

大規模なインフラ変更を伴わずに暗号アルゴリズムを切り替えられるか、組織の能力を評価します。

# Assess crypto-agility readiness
python scripts/agent.py --action assess_agility \
    --scan-results tls_inventory.json \
    --output agility_report.json

主な評価項目：

1. プロトコルの柔軟性：ダウンタイムなしで TLS 設定を更新できますか？
2. ライブラリのバージョン：導入済みの暗号ライブラリは PQC アルゴリズムをサポートしていますか？
3. 証明書インフラストラクチャ：CA は PQC 証明書を発行できますか？
4. 鍵管理：KMS はより大きな PQC 鍵サイズを扱えますか？
5. ハードウェアの制約：HSM は PQC 操作をサポートできますか？

フェーズ 3：ハイブリッド TLS 対応テスト

インフラストラクチャが X25519MLKEM768 によるハイブリッド鍵交換をサポートしているかテストします。

# Test hybrid TLS support on target servers
python scripts/agent.py --action test_hybrid_tls \
    --target server.example.com:443 \
    --output hybrid_tls_report.json

OpenSSL 3.5+（ML-KEM のネイティブサポート）：

# Test with native PQC support
openssl s_client -connect server.example.com:443 \
    -groups X25519MLKEM768

oqs-provider を使用する OpenSSL 3.0-3.4：

# Configure oqs-provider
# /etc/ssl/openssl-oqs.cnf
[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect

[default_sect]
activate = 1

[oqsprovider_sect]
activate = 1
module = /usr/lib/oqs-provider/oqsprovider.so

# Test hybrid TLS
OPENSSL_CONF=/etc/ssl/openssl-oqs.cnf \
openssl s_client -connect server.example.com:443 \
    -groups x25519_mlkem768

ハイブリッド TLS の Web サーバー設定：

Apache httpd：

SSLEngine on
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:prime256v1
SSLProtocol -all +TLSv1.2 +TLSv1.3

NGINX：

ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;

フェーズ 4：ML-KEM 鍵カプセル化の検証

環境内で ML-KEM（CRYSTALS-Kyber）の鍵カプセル化が正しく機能することを検証します。

# Test ML-KEM key encapsulation at all security levels
python scripts/agent.py --action test_mlkem \
    --output mlkem_validation.json

ML-KEM パラメーターの比較：

パラメーター	ML-KEM-512	ML-KEM-768	ML-KEM-1024
セキュリティレベル	NIST レベル 1	NIST レベル 3	NIST レベル 5
公開鍵サイズ	800 バイト	1,184 バイト	1,568 バイト
暗号文サイズ	768 バイト	1,088 バイト	1,568 バイト
共有シークレット	32 バイト	32 バイト	32 バイト
同等のもの	AES-128	AES-192	AES-256

フェーズ 5：ML-DSA デジタル署名の検証

ML-DSA（CRYSTALS-Dilithium）の署名操作を検証します。

# Test ML-DSA digital signatures
python scripts/agent.py --action test_mldsa \
    --output mldsa_validation.json

ML-DSA パラメーターの比較：

パラメーター	ML-DSA-44	ML-DSA-65	ML-DSA-87
セキュリティレベル	NIST レベル 2	NIST レベル 3	NIST レベル 5
公開鍵サイズ	1,312 バイト	1,952 バイト	2,592 バイト
署名サイズ	2,420 バイト	3,293 バイト	4,595 バイト
秘密鍵サイズ	2,560 バイト	4,032 バイト	4,896 バイト

フェーズ 6：移行ロードマップの生成

インベントリーと評価の結果に基づいて、優先順位付けされた移行ロードマップを生成します。

# Generate complete migration roadmap
python scripts/agent.py --action roadmap \
    --scan-results tls_inventory.json \
    --agility-results agility_report.json \
    --output migration_roadmap.json

ロードマップでは、次の基準でシステムの優先順位を決めます。

1. データの機密性：長期にわたって秘匿する必要のある情報を扱うシステムを最初に移行
2. 公開範囲：内部向けよりもインターネット公開サービスを優先
3. 暗号アジリティ：アルゴリズムを容易に切り替えられるシステムを優先
4. コンプライアンス要件：NIST IR 8547 のスケジュールに沿って、連邦政府・規制対象のシステムを優先
5. 依存関係の連鎖：アプリケーションよりもライブラリやフレームワークを先に移行

例

評価パイプライン全体

# Step 1: Scan all TLS endpoints
python scripts/agent.py --action scan_tls --targets hosts.txt --output scan.json

# Step 2: Assess crypto-agility
python scripts/agent.py --action assess_agility --scan-results scan.json --output agility.json

# Step 3: Test hybrid TLS on critical servers
python scripts/agent.py --action test_hybrid_tls --target critical.example.com:443

# Step 4: Validate ML-KEM support
python scripts/agent.py --action test_mlkem --output mlkem.json

# Step 5: Validate ML-DSA support
python scripts/agent.py --action test_mldsa --output mldsa.json

# Step 6: Generate migration roadmap
python scripts/agent.py --action roadmap --scan-results scan.json --agility-results agility.json --output roadmap.json

サーバーの簡易評価

# Single server PQC readiness check
python scripts/agent.py --action scan_tls --target server.example.com:443

検証チェックリスト

• 暗号インベントリが、すべての TLS エンドポイント、証明書、鍵ストアを網羅している
• 量子コンピュータに脆弱なすべてのアルゴリズム（RSA、ECDH、ECDSA、DH、DSA）が特定されている
• 暗号アジリティの評価で、ライブラリのバージョンとアップグレード経路が文書化されている
• ハイブリッド TLS（X25519MLKEM768）を、代表的なサーバー構成でテストしている
• ML-KEM の鍵カプセル化が、目標とするセキュリティレベル（推奨は 768）で検証されている
• 証明書チェーンでの利用に向けて、ML-DSA の署名検証が検証されている
• バックアップ用の署名アルゴリズムとして SLH-DSA（FIPS 205）が評価されている
• 移行ロードマップが、データの機密性とコンプライアンスのスケジュールに基づいて優先順位付けされている
• OpenSSL のバージョンと oqs-provider の互換性が確認されている
• 鍵サイズの増加が、ネットワークとストレージの容量計画に反映されている
• PQC アルゴリズムと HSM/KMS の互換性が検証されている
• PQC アルゴリズムの性能への影響が、本番環境の負荷下でベンチマークされている
• 機密データの通信経路について「Harvest now, decrypt later（今収集し、後で復号する）」のリスクが評価されている
• 証明機関（CA）が証明書を発行するための PQC 対応準備が確認されている

参考資料

• NIST PQC 標準: https://csrc.nist.gov/projects/post-quantum-cryptography
• FIPS 203（ML-KEM）: https://csrc.nist.gov/pubs/fips/203/final
• FIPS 204（ML-DSA）: https://csrc.nist.gov/pubs/fips/204/final
• FIPS 205（SLH-DSA）: https://csrc.nist.gov/pubs/fips/205/final
• NIST SP 1800-38 移行ガイド: https://www.nccoe.nist.gov/crypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms
• NIST IR 8547 移行タイムライン: https://csrc.nist.gov/pubs/ir/8547/ipd
• Open Quantum Safe Project: https://openquantumsafe.org/
• OpenSSL 向け oqs-provider: https://github.com/open-quantum-safe/oqs-provider
• OQS TLS 統合: https://openquantumsafe.org/applications/tls.html
• CISA PQC 移行戦略: https://www.cisa.gov/sites/default/files/2024-09/Strategy-for-Migrating-to-Automated-PQC-Discovery-and-Inventory-Tools.pdf
• IETF Hybrid Key Exchange ドラフト: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
• CycloneDX Crypto BOM: https://cyclonedx.org/use-cases/cryptographic-key/