GMOコネクト執行役員CTO 菅野 哲（かんの さとる）でございます。
暗号の2030年問題の対策として暗号移行を行う必要があるのですが、これが めちゃくちゃ難しい のです。
難しくさせる要因が2つあって、1つ目が「Crypto Inventory」と呼ばれる「データ・資産の棚卸しと暗号利用状況」の実施、もう1つが「Crypto Agility」と呼ばれる「暗号アルゴリズムをシステム全体に大きな影響なく柔軟かつ迅速に置き換える能力」という関門があります。
この記事では、関門の2つ目である「Crypto Agility」について解説します。
解説対象の情報
- タイトル: Considerations for Achieving Crypto Agility: Strategies and Practices
- 文書番号: NIST CSWP 39
- 発行日: 2025年12月19日
- 発行機関: NIST (National Institute of Standards and Technology)
- 著者: Elaine Barker, Lily Chen, David Cooper, Dustin Moody, Andrew Regenscheid, Murugiah Souppaya, Bill Newhouse, Russ Housley, Sean Turner, William Barker, Karen Kent
- DOI: https://doi.org/10.6028/NIST.CSWP.39
Crypto Agilityの定義
総括的な定義
NISTは、このNIST CSWP 39にて"Crypto Agility"を以下のように定義しています（Abstract）：
Cryptographic (crypto) agility refers to the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations.
Crypto Agilityとは、プロトコル、アプリケーション、ソフトウェア、ハードウェア、ファームウェア、インフラストラクチャにおいて、セキュリティと継続的な運用を維持しながら暗号アルゴリズムを置換・適応する能力を指しています。
この事からわかる事は、ただ単に暗号アルゴリズムを置き換えられればよいということではないことに注目ですね！
コンテキスト別の定義
NIST CSWP 39では、適用される技術的コンテキストによって3つの異なる定義を提示しています（Section 1, Introduction）
1. システムにおけるCrypto Agility
Crypto Agility for a Computing System: Cryptographic algorithms are implemented in software, hardware, firmware, and infrastructures to facilitate their use in applications. For example, replacing a cryptographic algorithm in applications often requires changes to application programming interfaces (APIs) and software libraries. It may also necessitate the replacement of hardware to incorporate new hardware accelerators. In a system, crypto agility is the ability to adopt new cryptographic algorithms and stop the use of vulnerable algorithms in applications without disrupting the running system.
要点: 稼働中のシステムを中断させることなく、新しい暗号アルゴリズムを採用し、脆弱なアルゴリズムの使用を停止する能力。
2. 通信プロトコルにおけるCrypto Agility
Crypto Agility for a Communication Protocol: In a communication protocol, parties must agree on a common cipher suite: a common set of cryptographic algorithms used for key establishment, signature generation, hash function computation, encryption, and/or data authentication. Any update of algorithms must be reflected in the protocol specifications. In a protocol, crypto agility is the ability to maintain interoperability when introducing new cryptographic algorithms and preventing the use of vulnerable algorithms.
要点: 新しい暗号アルゴリズムを導入し、脆弱なアルゴリズムの使用停止する際に相互運用性（Interoperability）を維持する能力。
3. エンタープライズにおけるCrypto Agility
Crypto Agility for an Enterprise IT Architect: Achieving crypto agility is not only a task for product designers, implementors, and operators but also for information technology (IT) and cybersecurity architects, software and standards developers, hardware designers, and executives. In an enterprise, crypto agility is a capacity to seamlessly and rapidly transition away from vulnerable cryptographic algorithms and adopt new, stronger ones without incurring significant changes to their infrastructure or experiencing unnecessary disruptions.
要点: インフラへの大幅な変更や不要な混乱を招くことなく、脆弱なアルゴリズムからより強力なアルゴリズムへシームレスかつ迅速に移行する能力。
なぜCrypto Agilityが必要なのか
Crypto Agilityが必要なのか？という点について、PQC移行の緊急性や歴史的な教訓を振り返ることで得られる知見があります。
PQC移行の緊急性（Section 1）
The threats posed by future cryptographically relevant quantum computers (CRQCs) to public-key cryptography demand an urgent migration to quantum-resistant cryptography. The impact of transitioning to post-quantum cryptography (PQC) will be much larger in scale than previous transitions because all public-key algorithms will need to be replaced rather than just a single algorithm.
量子計算機の脅威により、素因数分解や離散対数問題の困難性を安全性の根拠にしている現行の公開鍵暗号アルゴリズム全体を置換する必要があります。これは過去の単一アルゴリズムの置き換えとは規模が根本的に異なる点がポイントとなります。
歴史的教訓：移行の長期化（Section 2）
NIST CSWP 39では、過去の暗号移行が長期化した具体例を挙げています。
DESからAESへの移行（Section 2.1）
In 1977, the Data Encryption Standard (DES) became the first published encryption standard... Triple DES continued to be used in many applications until it was finally disallowed in 2024. In all, the complete transition from Triple DES to AES took 23 years.
- 1977年: DES標準化
- 1999年: Triple DES導入
- 2001年: AES標準化
- 2024年: Triple DES使用禁止
- 移行期間: 23年
SHA-1の段階的廃止（Section 2.2）
In 2005, SHA-1 was found to provide fewer than 80 bits of collision resistance. In 2006, NIST responded by urging federal agencies to "stop relying on digital signatures that are generated using SHA-1 by the end of 2010."... NIST now recommends a complete transition away from SHA-1 by the end of 2030.
- 2005年: 衝突耐性の問題発見
- 2006年: NISTが移行を勧告
- 2030年末: 完全廃止予定
- 移行期間: 25年以上
どちらの事例も20年以上の歳月を費やして、社会に浸透した暗号アルゴリズムを廃止してきたことがわかります。
実際にはレガシーなサーバ等ではこれらのアルゴリズムが利用されていることは回避することができない事実かなと思います。
NIST CSWP 39では、このような長期化の原因について、文書は以下のように指摘しています（Section 2）：
Most early cryptographic applications were deployed using algorithms that were expected to be used throughout the lifetime of the applications or systems... Algorithms were sometimes implemented in a manner that was difficult to change, making maintenance and the addition of new algorithms hard to accomplish.
これって、初期の暗号アプリケーションは「生涯同じアルゴリズムを利用する」っていう前提であり、アルゴリズムを変更するという考えで作られたため、アルゴリズムが変更しにくい形で実装されてしまい、後からメンテナンスや新アルゴリズム追加が困難になったという背景があることを振り返っております。
この事象から人類に伝えたいことは「同じ失敗を繰り返すな！ PQC移行では Crypto Agilityを最初から考慮しろ！！」ってことだと思います。
これを読んでいる読者の皆さん、目を瞑り胸に手を当てて問いかけてください。大丈夫ですよね...ｺﾞｸﾘ
暗号アルゴリズムのハードコーディングとか固定バッファサイズでの実装とかしてないですよね？笑
具体例：Crypto Agilityの実装戦略
プロトコル設計における具体例
1. アルゴリズム識別（Section 3.1）
TLSにおける実装例:
In some security protocols, a combination of the protocol version number and explicit algorithm or cipher suite identifiers is defined. For example, in TLS version 1.2 (TLSv1.2) and TLS version 1.3 (TLSv1.3), the version number specifies the hash function that is used as a binder for external pre-shared keys (PSKs).
- TLS 1.2とTLS 1.3では、バージョン番号とCipher Suite識別子を組み合わせて使用
- プロトコルバージョン変更なしにアルゴリズムを追加可能
2. Mandatory-to-Implement Algorithmsの更新（Section 3.1.1）
S/MIMEにおける実装例:
For example, support for the AES algorithm was introduced in S/MIME v3.1 in 2004, and the AES algorithm became mandatory to implement in S/MIME v3.2 in 2010.
- 2004年: S/MIME v3.1でAESサポート導入
- 2010年: S/MIME v3.2でAESが必須実装に
- 段階的な導入により移行期間を確保
3. Hybrid暗号アルゴリズム（Section 3.2.4）
PQC移行期における重要な戦略として、Hybrid構成が挙げられています：
A hybrid signature algorithm combines a traditional signature algorithm and a PQC signature algorithm (e.g., combining Elliptic Curve Digital Signature Algorithm [ECDSA] and ML-DSA).
Hybrid構成の署名は、現行暗号の署名アルゴリズム（ECDSA等）とPQCの署名アルゴリズム（ML-DSA等）を組み合わせることで、移行期間中の安全性を確保する。これにより、仮にPQCアルゴリズムに未知の脆弱性が発見されても、従来型アルゴリズムが防御できるという利点がある。
証明書の課題：
Hybrid署名を使用する場合、2つの公開鍵（現行とPQC）の両方を証明書で認証する必要がある。NISTは2つの実装アプローチを提示している：
1. 単一証明書方式（Single Certificate Approach）:
One option is to include the two public keys in a single certificate, where the public keys would always be used together.
-
実装: 1つの証明書に従来型公開鍵とPQC公開鍵の両方を含める
-
利点: 2つの公開鍵が常にセットで使用されるため、一貫性が保証される
-
欠点: 原文では以下のように指摘されている
The PKI root of trust must be known to all of the relying parties to validate a certificate, and the cost of deploying a PKI root of trust is significant, so the expense associated with a transition to the use of a hybrid root of trust followed by a potential second transition to using only a PQC algorithm for a root of trust must be considered.
- PKI root of trustの展開コストが大きい
- Hybrid → Pure PQCへの2段階移行が必要となり、2回のroot更新コストが発生
2. 分離証明書方式（Separate Certificate Approach）:
Another option is the deployment of a traditional root of trust and a PQC root of trust using separate certificates.
-
実装: 現行とPQCで別々の証明書（別々のPKI Root of Trust）を使用
-
利点: 原文では以下のように述べられている
A significant advantage of using separate roots of trust is that once the traditional PKI is no longer needed, one can simply stop issuing certificates under the traditional root of trust, while the PQC trust anchor continues to be used.
- 現行暗号によるPKIが不要になった時点で、現行暗号での証明書の発行を停止するだけで移行完了
- Pure PQCへの移行が段階的かつシンプル
-
欠点:
In some cases, two certificates will be less expensive, but there are operational costs associated with validating two certification paths to establish a session key.
- 2つの証明書パスを検証する運用コストが発生
- 証明書管理の複雑性が増加
システム実装における具体例
1. Crypto API（Section 4.1）
A cryptographic service provider (CSP) is an implementation of one or more cryptographic algorithms that is accessible by applications through a crypto API... For example, crypto APIs can separate AES-CCM and AES-GCM, which are both authenticated encryption with associated data (AEAD) algorithms, from implementations by allowing an implementation to make the same crypto API calls to use either algorithm.
具体的な利点:
-
実装の独立性: アプリケーション実装者は暗号アルゴリズムの詳細から分離され、同一のCrypto API呼び出しで異なるアルゴリズム（例：AES-CCMとAES-GCM）を使用可能
-
管理者によるポリシー制御: システム管理者（CISO配下）が暗号アルゴリズムポリシーを設定し、特定アルゴリズムの使用可否（例：Triple DES暗号化は拒否、復号は許可）をアプリケーション横断的に制御可能
また、原文の内容から以下のような組織的な利点も挙げられるため、大変なだけではないということを示しておく。
-
1. 一元管理
- Crypto APIを使用することで、CISOが組織全体の暗号ポリシーを一元的に設定できる。このポリシーは全アプリケーションに自動的に適用されるため、個々の開発者がセキュリティ基準を個別に判断する必要がなくなる。これにより、組織内で統一されたセキュリティレベルを維持できる。
-
2. 段階的移行のサポート
- ポリシー設定により「新規暗号化は禁止、既存データの復号は許可」といった柔軟な制御が可能となる。これにより、システム運用を停止することなく移行期間を設定できる。例えば、2025年は非推奨アルゴリズムの使用時に警告を出し、2026年からはエラーとして拒否するといった段階的な移行計画を実装できる。
-
3. 監査とコンプライアンス
- Crypto APIを通じたアルゴリズム使用は全てログに記録されるため、どのアプリケーションがどの暗号アルゴリズムを使用したかを追跡可能である。これにより、FIPS、PCI-DSS等の規制要件への準拠を自動的にチェックでき、「誰がいつTriple DESを使おうとしたか」といった監査証跡を確保できる。
-
4. 緊急対応
- 暗号アルゴリズムに脆弱性が発見された場合、管理者は設定ファイルの変更のみで即座に当該アルゴリズムを無効化できる。この変更は全システムに適用され、個々のアプリケーションを再デプロイする必要がない。これにより、セキュリティインシデントへの迅速な対応が可能となる。
2. Crypto Gateway（Section 4.6）
レガシーシステムが抱える構造的課題：
NIST CSWP 39では、ミッションクリティカルなシステムやレガシーシステムにおけるCrypto Agilityの困難さを以下のように指摘している：
Legacy or monolithic mission-critical systems often have cryptographic functions tightly embedded within their components. Such systems were developed with obsolete technologies, and the original personnel are no longer available. The absence of abstraction between cryptographic operations and core system logic hampers the ability to support crypto agility.
これらのシステムでは、暗号機能がコンポーネントに密結合しており、レガシーな技術で開発され、元の開発者も既に不在である。暗号処理とコアロジックの間に抽象化層が存在しないため、Crypto Agilityの実現が本質的に困難となっている。
Crypto Gatewayによる解決アプローチ：
To address risks posed by vulnerable or disallowed cryptography across such systems, an architectural solution known as a "crypto gateway" or "bump-in-the-wire" can be implemented. This approach introduces a dedicated cryptographic gateway to intercept and perform cryptographic functions externally to one or more system components.
Crypto Gateway（別名：bump-in-the-wire）は、専用の暗号ゲートウェイをネットワーク経路上に配置し、レガシーシステムとの間で暗号処理を代行する。原文では以下のように説明されている：
This often results in modern cryptographic solutions that encapsulate the vulnerable cryptography that was built into the legacy systems. By centralizing cryptographic operations within this gateway, organizations can enforce updated cryptographic policies, rotate keys, and deploy new algorithms uniformly across the system without modifying or redeploying individual legacy components.
具体的な動作メカニズム：
Crypto Gatewayは、外部ネットワークとレガシーシステムの間に介在し、以下の処理を実行する：
- 外部通信の暗号化: 外部ネットワークとの通信には最新の暗号アルゴリズム（AES-256-GCM、SHA-256、将来的にはML-DSA等）を使用
- 内部通信の維持: レガシーシステムとの内部通信では既存の暗号方式（Triple DES、SHA-1等）を継続使用
- プロトコル変換: Gateway内部で新旧暗号プロトコル間の変換を実施
- 透過的な運用: レガシーシステムは暗号更新を一切意識せずに動作継続
主要な利点：
非侵襲的な保護の実現
レガシーシステム本体のコード、設定、デプロイメントを一切変更することなく、組織の最新暗号ポリシーを適用できる。原文では以下のように述べられている：
This approach can help provide crypto agility for mission-critical systems if direct modifications to embedded cryptographic code and functions are not feasible.
これは、ソースコードが失われたシステム、製造元がサポート終了したシステム、変更によるミッション影響が許容できないシステムにおいて特に有効である。
暗号機能の一元的な管理と更新
複数のレガシーシステムに対して、単一のGatewayで以下を統一的に管理：
- 鍵のローテーション：定期的な鍵更新をGateway側で実施し、個別システムの変更不要
- 新アルゴリズムの展開：PQCアルゴリズムへの移行をGatewayのソフトウェア更新のみで実現
- 証明書ライフサイクル管理：証明書の発行・更新・失効処理を一元化
- 暗号ポリシーの適用：組織のセキュリティポリシー変更をGateway設定変更のみで反映
- 監査ログの集約：全暗号処理のログをGatewayで一元的に記録・分析
実装上の考慮事項：
- パフォーマンス：Gateway経由による処理遅延の評価とキャパシティプランニング
- 可用性：Gateway自体がSPOF（単一障害点）とならないよう冗長構成の設計
- スケーラビリティ：多数のレガシーシステムを扱う場合の負荷分散機構
- セキュリティ境界：Gateway内部での暗号鍵の安全な保管とアクセス制御
3. クラウド環境におけるService Mesh（Section 4.3）
クラウドネイティブ環境におけるCrypto Agilityの課題：
マイクロサービスアーキテクチャでは、数百から数千の独立したサービスが相互通信を行う。各サービスが個別に暗号実装を持つ場合、暗号アルゴリズムの更新は組織的に困難となる。
Service Meshによる解決アプローチ：
NIST CSWP 39では、Service MeshとSidecar Proxyを活用したアプローチを以下のように説明している：
Emerging architectural patterns like service mesh and sidecar proxies in modern cloud-native environments can enhance crypto agility within distributed systems that are composed of numerous microservices. By abstracting cryptographic operations from application workloads and centralizing policy enforcement, the proxy acts as the cryptographic service provider and offers a uniform mechanism for negotiating, enforcing, and evolving cryptographic policies across all application components.
Service Meshアーキテクチャでは、各マイクロサービスに付随するSidecar Proxyが暗号サービス提供者として機能する。アプリケーションワークロードから暗号処理を抽象化し、ポリシー適用を一元化することで、全コンポーネント横断的に暗号ポリシーを適用・進化させる統一メカニズムを提供する。
技術的な実装メカニズム：
Service MeshにおけるCrypto Agilityは以下の構造で実現される：
- Sidecar Proxyによる暗号処理の代行: 各マイクロサービスに配置されたProxyが、サービス間通信の暗号化・復号を担当
- Control Planeによるポリシー配信: 中央のControl Planeから全Proxyに対して暗号ポリシー（使用アルゴリズム、鍵、証明書等）を配信
- アプリケーションからの分離: マイクロサービスのアプリケーションコードはTLS/mTLS等の暗号詳細を意識せず、localhost通信として実装
- 動的な設定更新: Control Planeの設定変更により、全Proxy（＝全サービス間通信）の暗号設定をリアルタイムに更新
主要な利点：
マイクロサービス全体での統一的な暗号ポリシー管理
NIST CSWP 39では以下のように述べられている：
This approach enables organizations to seamlessly update cryptographic libraries, manage key rotation, and introduce new algorithms with minimal disruption to running services. It also supports algorithm transitions defined in the organization's crypto policies in response to evolving security requirements.
数百のマイクロサービスに対して、以下を統一的に管理：
- 暗号ライブラリの更新：全Proxyのライブラリを一斉アップデート
- 鍵ローテーション：Control Planeからの指示で全サービス間通信の鍵を自動更新
- 新アルゴリズムの導入：PQCアルゴリズムへの移行をProxy更新のみで実現
- ポリシーベースの制御：「サービスA→サービスB間はML-KEM必須」等のきめ細かい制御
アプリケーション変更なしでの暗号更新
各マイクロサービスのアプリケーションコードは暗号処理を実装しないため：
- アプリケーション開発者は暗号アルゴリズムの詳細を知る必要がない
- 暗号アルゴリズム変更時にアプリケーションの再デプロイ不要
- セキュリティチームがControl Plane設定変更のみで組織全体の暗号ポリシーを更新可能
- 実行中のサービスへの影響を最小化しながら段階的な移行が可能
実装例：
主要なService Meshプラットフォームでは、以下のような暗号設定が可能：
- mTLS（mutual TLS）の自動設定と証明書の自動発行・更新
- サービス間通信のTLSバージョン・Cipher Suiteの一元管理
- 特定サービスペア間での暗号強度の個別設定
- 暗号通信の可視化とモニタリング
クラウド環境特有の考慮事項：
- Control Planeの可用性：ポリシー配信基盤の冗長化
- Proxyのオーバーヘッド：各サービスにSidecarを配置することによるリソース消費
- 証明書管理の自動化：短命証明書の自動発行・更新機構の整備
- ゼロトラストアーキテクチャとの統合：サービス間認証・認可との連携
組織レベルの戦略（Section 5）
Crypto Agility Strategic Plan
NISTは、組織レベルでの暗号リスク管理の枠組みとして、Crypto Agility Strategic Planを提示している（Section 5, Fig. 3）。
このプランは、ガバナンス、資産管理、リスク評価、自動化ツールを統合した包括的なアプローチです。
NIST CSWP 39では、このプランの必要性を以下のように説明している：
Organizations need to transition or migrate their cryptographic algorithms multiple times throughout the lifetimes of their IT systems. By incorporating crypto agility into their cryptographic policies during the design and development of the systems and technology acquisitions or scheduled replacements, updates, or modernization efforts, organizations can proactively address emerging threats, technological advances, system weaknesses, and evolving business requirements, standards, regulations, and mandates.
組織は、ITシステムのライフサイクル全体を通じて暗号アルゴリズムを複数回移行する必要がある。システムの設計・開発段階、技術調達、計画的な更新・近代化の各段階でCrypto Agilityを組み込むことで、新たな脅威、技術進歩、システムの脆弱性、ビジネス要件・標準・規制・マンデートの変化に対して先制的に対応できる。
1. ガバナンス（Governance）：
Integrate crypto agility into the organization's existing governance function to establish, communicate, and monitor the cybersecurity risk management strategy, expectations, and policies related to cryptography.
Crypto Agilityを組織の既存ガバナンス機能に統合し、暗号に関するサイバーセキュリティリスク管理戦略、期待値、ポリシーを確立・伝達・監視する。
NIST CSWP 39ではガバナンスの具体的な内容として以下を挙げている：
This includes understanding cryptographic standards, regulations, and mandates and communicating these requirements to data owners, IT and development teams, business partners, and technology supply chain vendors prioritized by the criticality of the data for the primary use cases.
ガバナンスに含まれる要素：
- 標準・規制の理解と遵守（Section 5.1）：NIST SP 800-131A等の移行スケジュール、FIPS認証要件、業界特有の規制（PCI-DSS、HIPAA等）を把握し、組織ポリシーに反映
- ステークホルダー間の調整：データ所有者、IT部門、開発チーム、ビジネスパートナー、サプライチェーンベンダーへの要件伝達
- 責任者の明確化：NIST CSWP 39では「Identify key stakeholders, including a responsible official to lead the effort and monitor the progress of the activities」と述べており、暗号移行を主導する責任者の任命が必要
- 優先順位付け：データの重要度に基づく移行の優先順位設定
2. 資産管理（Assets）：
Inventory the use of cryptography for data protection across the organization by adopting an assets-centric approach informed by the criticality of the data.
データの重要度に基づいた資産中心アプローチにより、組織全体での暗号使用状況を棚卸しする。
NIST CSWP 39では、資産管理の範囲を以下のように定義している：
...to identify the organization's use cases and most valuable assets, such as application codes, libraries, software, hardware, firmware, user-generated content, communication protocols, enterprise services, and systems.
棚卸し対象の資産：
- アプリケーションコード：どのコードでどの暗号ライブラリを使用しているか
- ライブラリ：OpenSSL、BoringSSL等のバージョンと設定
- ソフトウェア・ハードウェア・ファームウェア：組み込まれた暗号機能
- 通信プロトコル：TLS、IPsec、SSH等のバージョンとCipher Suite設定
- エンタープライズサービス：認証基盤（PKI）、鍵管理システム（KMS）、HSM
- システム：データベース暗号化、ディスク暗号化の設定
資産中心アプローチの意義：
従来の「どのアルゴリズムを使っているか」という視点ではなく、「どの重要資産がどの暗号で保護されているか」という視点で管理する。これにより、ビジネスへの影響度に基づいた移行計画の策定が可能となる。
3. 自動化ツール（Management Tools）：
Identify gaps in enterprise management tools... These tools should support cryptographic risk management and data protection functions by automating the identification, assessment, characterization, enforcement, and monitoring of cryptography across assets.
既存のエンタープライズ管理ツールのギャップを特定し、暗号の識別・評価・特性把握・適用・監視を自動化する機能を整備する。
NIST CSWP 39では、自動化ツールの具体的な機能として以下を挙げている：
For instance, vulnerability management and software/hardware development tools can help ensure comprehensive visibility and an inventory of assets, such as code, libraries, applications, and associated cryptographic algorithms.
自動化ツールの機能要件：
- Discovery（発見）：コード、ライブラリ、設定ファイル、証明書等から暗号使用状況を自動抽出
- Assessment（評価）：検出した暗号アルゴリズム・鍵長が組織ポリシーに準拠しているかを自動判定
- Characterization（特性把握）：各暗号使用箇所のコンテキスト（用途、データの重要度、更新容易性等）を分類
- Enforcement（適用）：ポリシー違反の検出と修正アクションの自動実行
- Monitoring（監視）：暗号使用状況の継続的な監視とダッシュボード表示
ツールの統合ポイント：
NIST CSWP 39では既存ツールとの統合を以下のように推奨している：
Identify gaps in enterprise management tools for managing assets, configurations, vulnerabilities, and logs.
- 資産管理ツール：CMDB（Configuration Management Database）との統合
- 脆弱性管理ツール：脆弱な暗号使用の自動検出
- ログ管理ツール：暗号処理の監査ログ収集
- 開発ツール：CI/CDパイプラインでの暗号ポリシーチェック
4. リスク評価と移行（Data-Centric Risk Management）：
A cryptographic policy-informed risk assessment engine should be used to analyze this data, form an implementation strategy, and recommend actions to reduce risks.
暗号ポリシーに基づくリスク評価エンジンを使用してデータを分析し、実装戦略を策定し、リスク低減のためのアクションを推奨する。
原文では、リスク評価のKPI（重要業績評価指標）について以下のように述べている：
Based on the organization's defined cryptographic policy, the engine will continuously measure, monitor, and report on the state of cryptography within the enterprise and focus on crypto agility key performance indicators (KPIs) for the level of effort needed to effectively and efficiently adapt and migrate. This may include the time, cost, and ease to migrate and mitigate in accordance with technology refresh cycles.
KPIの具体例：
- Time（時間）：各資産の暗号移行に要する推定期間
- Cost（コスト）：移行に伴う開発・テスト・デプロイコスト
- Ease（容易性）：Crypto Agilityの成熟度（後述のTierモデル）
リスク評価と優先順位付け：
原文では、評価結果に基づく優先順位付けを以下のように説明している：
Develop a prioritized list of assets to be mitigated based on the data collected in the previous steps.
評価軸の例：
- データの重要度：機密性・完全性・可用性への影響
- 脅威の緊急度：量子計算機の脅威、既知の脆弱性
- 移行の容易性：Crypto Agilityの実装状況
- ビジネスへの影響：ダウンタイム許容度、規制要件
移行実装のアプローチ：
The level of crypto agility will determine whether assets can be smoothly migrated or compensatory mitigation measures must be implemented to reduce risks.
- Crypto Agilityが高い資産：スムーズに移行（Crypto API経由で設定変更のみ）
-
Crypto Agilityが低い資産：補償的統制（Compensatory Controls）の実装
- 例：Crypto Gatewayの配置、ネットワーク分離、監視強化
継続的な改善サイクル：
原文では以下のように述べている：
These steps are continuously repeated to mitigate evolving cryptographic risks and progressively strengthen the crypto agility posture within organizations over time.
このプランは一度実施して終わりではなく、継続的に繰り返すことで、組織のCrypto Agility態勢を段階的に強化していく。これはPDCA（Plan-Do-Check-Act）サイクルに相当する。
リソース制約への対応（Section 2.4, Section 6.1）
原文では、リソース制約をCrypto Agilityの最大の課題として位置づけている：
Resource limitation is the most difficult challenge for achieving crypto agility.
PQC署名サイズの具体例：
For example, an RSA key size (modulus) of 3072 bits provides roughly 128 bits of classical security strength. The transition to the post-quantum Module-Lattice-Based Digital Signature Algorithm (ML-DSA) specified in FIPS 204 will result in a signature of 2420 bytes (i.e., 19,360 bits) to provide a roughly equivalent classical security strength of 128 bits.
- RSA-3072署名: 384 bytes
- ML-DSA署名（128-bit security）: 2,420 bytes
- 約6.3倍のサイズ増加
このサイズ増大は、通信帯域、メモリ容量、ストレージ、処理時間に直接影響するってことです。
この話題はいろんなところで言われているので耳タコですよね...笑
設計上の対策（Section 6.2）：
To achieve cryptographic agility, a product or system must be designed to accommodate new algorithms and parameters... The design should avoid making assumptions based on specific algorithms to ensure that buffers, memory, and storage can handle diverse cryptographic data.
具体的には：
- 固定サイズバッファではなく動的メモリ確保
- プロトコルでの可変長フィールド定義
- 将来の拡張を見越した余裕のある設計
短視眼的設計と本質的制約の区別：
It is important for protocol designers to consider resource demands to plan for future transitions and to distinguish intrinsic limitations from shortsighted design decisions.
- 短視眼的設計（回避可能）: 特定アルゴリズムを前提とした固定バッファ
- 本質的制約（技術的対処必要）: IoTデバイスの物理的メモリ容量
成熟度モデル（Section 6.5）
成熟度評価の目的：
原文では、組織が既存のリスク管理フレームワークにCrypto Agilityを統合すべきことを以下のように述べている：
Since organizations vary significantly in their mission, size, sector, country, regulatory regime, and risk tolerance, there is not a single crypto maturity model that effectively serves all needs. Instead, organizations should adapt their existing, mature risk management frameworks to include crypto agility.
組織の特性は多様であるため、既存のリスク管理フレームワーク（例：NIST CSF）をCrypto Agilityに適応させ、組織内での共通語彙として活用することを推奨している。
NIST CSFベースの4段階モデル：
原文では、NIST Cybersecurity Framework (CSF)の4つのTierを以下のように定義している：
The CSF has four tiers that show increasing sophistication in cybersecurity risk management:
• Tier 1 – Partial: An initial, informal, and reactive approach
• Tier 2 – Risk-Informed: Management-approved but not fully integrated practices
• Tier 3 – Repeatable: Standardized and consistently updated processes
• Tier 4 – Adaptive: Proactive, continuously improved, and dynamic approach to cybersecurity based on evolving risks
Tier 1 - Partial（部分的）
Crypto agility practices are unstructured and unplanned... The selection of cryptographic algorithms, schemes, libraries, and cryptographic products and services is not informed by current cryptographic-based exploits and evolving threat landscapes.
特徴：
- 暗号選定が場当たり的で、各チームが独自に判断
- 組織全体での暗号使用状況を把握していない
- 暗号ポリシーや移行計画が存在しない
- 脆弱性発見時に影響範囲を特定できない
Tier 2 - Risk-Informed（リスク認識あり）
The crypto agility strategy and plan include a cryptographic policy that has been defined and approved by management but has not been adopted consistently as an organization-wide policy... Crypto agility prioritization is determined and refined through risk assessments.
特徴：
- 暗号ポリシーは定義されているが、組織全体には浸透していない
- リスク評価に基づく優先順位付けを開始
- 暗号資産の棚卸しを実施中だが完全ではない
- 標準・規制要件を認識し、対応を検討
Tier 3 - Repeatable（反復可能）
Crypto agility is formally integrated into the organization's risk management plan... Integrated and automated cryptographic discovery and remediation tools are used to prioritize and continuously mitigate cryptographic risks.
特徴：
- 暗号ポリシーが組織のリスク管理計画に正式統合
- 自動化ツールによる暗号検出・修復の継続的実施
- 開発者向けの教育・訓練プログラムの整備
- 定期的な暗号移行演習とテストの実施
Tier 4 - Adaptive（適応的）
Crypto agility is a fundamental element of organizational risk management with defined objectives... Crypto agility is monitored, measured, and reported to executives as part of the risk register and linked to financial, business, and mission objectives.
特徴：
- Crypto Agilityが経営レベルのKPIとして測定・報告
- 脅威や技術変化にリアルタイムで適応
- すべてのコード変更で暗号ポリシーを自動チェック
- ビジネス目標・財務指標と連動した暗号リスク管理
組織的な活用方法：
このモデルは、現状評価と目標設定のベースラインとして使用できる。例えば「現在はTier 2、2年以内にTier 3到達」といった具体的な改善計画の策定が可能となる。また、経営層への報告や予算確保の根拠としても活用できるとされています！
結論
NIST CSWP 39は、Crypto Agilityを以下のように位置づけている（Section 7）：
Crypto agility is a future-proofing strategy to address changes in cryptographic algorithms. It demands communication among cryptographers, protocol designers, developers, implementers, and practitioners to accommodate evolving security, performance, and interoperability challenges.
Crypto Agilityは、将来の暗号アルゴリズムの変更に備える戦略であり、暗号研究者・プロトコル設計者・開発者・実装者・運用者間の連携を必要な活動です。
さらに、原文では移行メカニズムの重要性について以下のように述べている：
The security analysis and evaluation of protocols, systems, and applications must include mechanisms for transitions. When transition mechanisms are not available, organizations should have a plan to implement compensating controls to mitigate cryptographic vulnerabilities and evolving threats.
プロトコル・システム・アプリケーションのセキュリティ分析には移行メカニズムを含めるべきであり、それが利用できない場合は補償的統制（Compensating Controls）による代替策が必要である。
主要なポイント
1. PQC移行は過去最大規模
従来の単一アルゴリズム置換とは異なり、全公開鍵アルゴリズムの置き換えが必要となる。しかもこれが最後の移行ではなく、将来も継続的な暗号更新が求められる。
2. 歴史的教訓
DES→AESの移行に23年、SHA-1の完全廃止まで25年以上を要した。当初から移行を想定しない設計が長期化の主因である。
3. システム的アプローチ
プロトコル設計（Section 3）、システム実装（Section 4）、組織戦略（Section 5）の各レベルで統合的な対策が必要。単一レイヤーのみの対応では不十分。
4. 移行メカニズムの事前組み込み
設計段階からアルゴリズム識別、Cipher Suite交渉、Crypto API、ポリシー制御等の移行メカニズムを組み込むことで、将来の変更コストを大幅に削減できる。
5. 補償的統制（Compensating Controls）
レガシーシステム等、移行メカニズムが実装できない場合は、Crypto Gateway、ネットワーク分離、監視強化等の代替策による暗号リスク低減が必要。
参考情報
- 原文: https://doi.org/10.6028/NIST.CSWP.39
- NIST PQC標準:
- FIPS 203: ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)
- FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature Algorithm)
- 関連NIST文書:
- SP 800-131Ar2: Transitioning the Use of Cryptographic Algorithms and Key Lengths
- SP 800-227: Recommendations for Key-Encapsulation Mechanisms
- NIST IR 8547: Transition to Post-Quantum Cryptography Standards
Appendix: 他文献におけるCrypto Agilityの定義
文書のAppendix Bでは、他文献におけるCrypto Agilityの定義も紹介されているので参照してもらうと理解が深まると思います。
2016年NISTプレゼンテーション
- The ability for implementations to select from the available security algorithms in real time and based on their combined security functions;
- The ability to add new cryptographic features or algorithms to existing hardware or software, resulting in new, stronger security features; and
- The ability to gracefully retire cryptographic systems that have become either vulnerable or obsolete.
金融セクター向け定義
...a measure of an organization's ability to adapt cryptographic solutions or algorithms (including their parameters and keys) quickly and efficiently in response to developments in cryptanalysis, emerging threats, technological advances, and/or vulnerabilities...
ATIS（Alliance for Telecommunications Industry Solutions）
...the ability of a system or organization to adapt and switch to different cryptographic primitives, algorithms, or protocols easily and efficiently with limited impact on operations and with low overhead.
ETSI定義
...a property that permits changing or upgrading cryptographic algorithms or parameters.
注記: 本記事は NIST CSWP 39（2025年12月19日発行）の内容に基づいています。引用部分は原文からの直接引用です。技術的な詳細については原文を参照してください。
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。