« 中国 2023年8月から2024年12月末までに届出があった生成的AIサービスは302件、API利用したサービス105件 | Main | 欧州連合 欧州経済・社会委員会 (EESC) プロワーカーAI:雇用・労働市場政策に関連するAIの可能性を活用し、リスクを緩和するための手段 (2024.01.09) »

2025.01.13

米国 国家安全保障局 商用国家安全保障アルゴリズム・スイート2.0および量子コンピューティングに関するFAQ更新 (2024.12.31)

こんにちは、丸山満彦です。

米国の国家安全保障局が、商用国家安全保障アルゴリズム・スイート2.0および量子コンピューティングに関するFAQを公表していますね...

耐量子暗号への移行についても記載がありますね...

量子コンピュターを米国以外が実用化し、既存の暗号が危殆化することに対する警戒は高いように感じます...

 

U.S. National Security Agency

・2024.12.31 [PDF] CSI: Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) FAQ (December 2024 Update)

20250112-73847

仮対訳...

 

商用国家安全保障アルゴリズム・スイート2.0

Algorithm  Function  Specification  Parameters 
General Purpose Algorithms 
Advanced Encryption Standard (AES)  Symmetric block cipher for information protection  FIPS PUB 197  Use 256-bit keys for all classification levels. 
ML-KEM (previously CRYSTALS-Kyber)  Asymmetric algorithm for key establishment  FIPS PUB 203  ML-KEM-1024 for all classification levels. 
ML-DSA (previously CRYSTALS-Dilithium)  Asymmetric algorithm for digital signatures in any use case, including signing firmware and software  FIPS PUB 204  ML-DSA-87 for all classification levels. 
Secure Hash Algorithm (SHA)  Algorithm for computing a condensed representation of information  FIPS PUB 180-4  Use SHA-384 or SHA-512 for all classification levels. 
Algorithms Allowed in Specific Applications 
Leighton-Micali Signature (LMS)  Asymmetric algorithm for digitally signing firmware and software  NIST SP 800-208   All parameters approved for all classification levels. LMS SHA256/192 is recommended. 
Xtended Merkle Signature Scheme (XMSS)  Asymmetric algorithm for digitally signing firmware and software  NIST SP 800-208  All parameters approved for all classification levels. 
Secure Hash Algorithm 3 (SHA3)  Algorithm used for computing a condensed representation of information as part of hardware integrity  FIPS PUB 202  SHA3-384 or SHA3-512 allowed for internal hardware functionality only (e.g., boot-up integrity checks) 

 

 

 

 

National Security Agency | Cybersecurity Information Sheet  国家安全保障局|サイバーセキュリティ情報シート
The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ  商用国家安全保障アルゴリズム・スイート2.0および量子コンピューティングに関するFAQ
These frequently asked questions (FAQ) and answers are intended to clarify Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) requirements for National Security Systems (NSS) and recommend guidance for the Department of Defense (DoD) and the Defense Industrial Base (DIB). This information may be useful more generally, especially for those who interact with NSS, DoD, or DIB systems.  これらのよくある質問(FAQ)と回答は、国家安全保障システム(NSS)に対する商用国家安全保障アルゴリズム・スイート2.0(CNSA 2.0)の要件を明確にし、国防総省(DoD)および防衛産業基盤(DIB)に対する推奨ガイダンスを提供することを目的としている。この情報は、特にNSS、DoD、またはDIBシステムとやりとりする人々にとって、より一般的に役立つ可能性がある。
Sections  セクション
• Background  • 背景 
• CNSA 2.0  • CNSA 2.0 
• Timeframe  • スケジュール 
• Preparation  • 準備 
• CNSSP 15  • CNSSP 15 
• Quantum alternatives  • 量子暗号の代替案 
• CSfC and NIAP  • CSfCとNIAP 
• Future cryptographic algorithms  • 将来の暗号アルゴリズム 
• Hybrids  • ハイブリッド 
• Further information  • 追加情報 
Background  背景 
Q: To whom are these requirements addressed?  Q: これらの要件は誰を対象としているのか? 
A. These are mainly addressed to the following audiences:  A. これらの要件は主に以下の対象者向けである。 
• National Security System (NSS) owners and operators, who need to know the requirements for their systems  • 国家セキュリティシステム(NSS)の所有者および運用者。自らのシステムに必要な要件を知っておく必要がある 
• Vendors, who need to know what to implement to meet NSS requirements  • ベンダー:NSS要件を満たすために実装すべき事項を知っておく必要がある
NSA is not using these requirements to dictate to any other entity outside of NSS what algorithms they should use, although NSA recognizes that interoperability requirements or other interests may lead to scenarios where these recommendations are used by a larger community.  NSAは、NSS以外の事業体にどのようなアルゴリズムを使用すべきかを指示するためにこれらの要件を使用しているわけではないが、NSAは、相互運用性の要件やその他の利害関係により、これらの推奨事項がより広範なコミュニティで使用されるシナリオにつながる可能性があることを認識している。
Q: What is a quantum computer, and how is it different from the computers we use today?  Q: 量子コンピュータとは何ですか?また、現在使用されているコンピュータとどのように異なるのですか?
A: In place of ordinary bits used by today’s computers, quantum computers use “qubits” that behave in surprising ways, efficiently performing certain mathematical algorithms exponentially faster than a classical computer. Small examples of quantum computers have been built.  A: 量子コンピュータは、現在のコンピュータで使用されている通常のビットの代わりに、「キュービット」を使用する。このキュービットは驚くべき挙動を示し、特定の数学的アルゴリズムを従来のコンピュータよりも指数関数的に高速に効率的に実行する。量子コンピュータの小規模な例はすでに構築されている。
Q: What is a “cryptanalytically relevant quantum computer” (CRQC)?  Q: 「暗号解析的に関連する量子コンピュータ」(CRQC)とは何ですか?
A: Also written as “cryptographically relevant quantum computer,” CRQC describes quantum computers that are capable of attacking real world cryptographic systems.  A: 「暗号解析的に関連する量子コンピュータ」とも表記されるCRQCは、現実の暗号システムを攻撃できる量子コンピュータを指す。
Whether the “C” indicates “cryptanalytically” or “cryptographically” is a matter of writer’s preference, as the two terms are essentially equivalent in this context. This term distinguishes a CRQC from any other “quantum computer” technologies used in other settings without the performance metrics required to attack real world cryptographic systems.  「C」が「暗号解析上」を意味するのか、「暗号上」を意味するのかは、書き手の好みの問題である。なぜなら、この文脈では、この2つの用語は本質的に同等だからである。この用語は、現実世界の暗号システムを攻撃するために必要な性能指標を持たない、他の環境で使用される「量子コンピュータ」技術とCRQCを区別するものである。
Q: What is the threat if a CRQC were developed?  Q: CRQCが開発された場合の脅威とはどのようなものか?
A: A CRQC, if built, would be capable of undermining the widely deployed public-key algorithms currently used for asymmetric key exchanges and digital signatures with potentially devastating impact to systems. National security systems (NSS) use publickey cryptography as a critical component to protect the confidentiality, integrity, and authenticity of national security information.  A: CRQCが構築された場合、現在広く展開されている非対称鍵交換やデジタル署名に使用されている公開鍵アルゴリズムを無効化することが可能となり、システムに壊滅的な影響を及ぼす可能性がある。 国家安全保障システム(NSS)では、国家機密情報の機密性、完全性、および真正性を防御する重要な要素として公開鍵暗号を使用している。
Q: Can I continue to use larger sizes of RSA or ECC to address the threat?  Q: 脅威に対処するために、より大きなサイズのRSAやECCを引き続き使用することは可能か?
A: No. RSA and Elliptic Curve Cryptography are the main algorithms that need to be replaced to achieve quantum resistance.  A: いいえ。RSAと楕円曲線暗号は、量子耐性を実現するために置き換える必要がある主なアルゴリズムである。
Q: What is “quantum-resistant” or “post-quantum” cryptography?  Q: 「量子耐性」または「耐量子」暗号とは何なのか? 
A: “Quantum-resistant” (QR), “quantum-safe,” and “post-quantum” (PQ) cryptography are all terms used to describe cryptographic algorithms that can be run on computers today and are believed to be resistant to cryptanalytic attacks from both classical and quantum computers.  A: 「耐量子暗号」(QR)、「量子安全」、および「耐量子暗号」(PQ)は、いずれも現在コンピュータ上で実行可能であり、従来のコンピュータおよび量子コンピュータによる暗号解読攻撃に耐性を持つと考えられている暗号アルゴリズムを指す用語である。 
Q: What is the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)?  Q: 商用国家暗号アルゴリズム・スイート2.0(CNSA 2.0)とは何ですか?
A: CNSA 2.0 is the suite of QR algorithms approved for NSS use. The following table lists the algorithms and their functions, specifications, and parameters.  A: CNSA 2.0 は、NSS での使用が承認された QR アルゴリズムのセットである。以下の表は、アルゴリズムとそれぞれの機能、仕様、パラメータを一覧にしたものである。
Table: Commercial National Security Algorithm Suite 2.0  表:商用国家安全保障アルゴリズム・スイート 2.0 
CNSA 2.0  CNSA 2.0 
Q: Where should CNSA 2.0 algorithms be used?  Q: CNSA 2.0 アルゴリズムはどこで使用されるべきか?
A: CNSA 2.0 algorithms will be required for all products that employ public-standard algorithms in NSS, whether a future design or currently fielded. Any usage of Suite B or CNSA 1.0 algorithms will be required to transition to CNSA 2.0. The Timeframe section of this FAQ and CNSSP 15 provide transition timeframe information. More details will be released on an ongoing basis as industry adjusts to the new technology.  A: NSSで公開標準アルゴリズムを採用しているすべての製品(将来設計のもの、現在実用化されているもの)にCNSA 2.0アルゴリズムが必要となる。Suite BまたはCNSA 1.0アルゴリズムを使用している場合は、CNSA 2.0への移行が必要となる。このFAQの「移行期間」のセクションおよびCNSSP 15に、移行期間に関する情報が記載されている。業界が新しい技術に適応するにつれ、詳細が順次発表される予定である。
Q: How did NSA choose the CNSA 2.0 algorithms?  Q: NSAはどのようにしてCNSA 2.0アルゴリズムを選択したのか?
A: NSA chose algorithms from among those selected for standardization by the National Institute of Standards and Technology (NIST), the U.S. Government lead for commercial algorithm approval. NSA believes they offer optimal performance for given NSS security requirements.  A: NSAは、商業用アルゴリズム承認の米国政府主導機関である国立標準技術研究所(NIST)が標準化のために選択したアルゴリズムの中から選択した。NSAは、それらが特定のNSSセキュリティ要件に対して最適なパフォーマンスを提供すると考えている。
Q: How strong does NSA believe CNSA 2.0 algorithms are?  Q: NSAはCNSA 2.0アルゴリズムをどの程度強力だと考えているのか?
A: NSA performed its own analysis of CNSA 2.0 algorithms and considers them appropriate for long-term use in protecting the varied missions of U.S. NSS.  A: NSAはCNSA 2.0アルゴリズムの独自の分析を行い、米国のNSSの多様な任務を防御する長期的な使用に適切であると見なしている。 
Q: Does NSA intend to produce guidance for CNSA 2.0 similar to the IETF RFCs[1] produced for CNSA 1.0?  Q: NSAはCNSA 1.0のために作成されたIETF RFCs[1]と同様のCNSA 2.0の指針を作成する予定があるか?
A: NSA will provide direction for using CNSA 2.0 algorithms securely in a variety of use cases, and is working with the IETF to produce informational guides to aide with protocol deployment through the RFC series. RFCs detail protocol options in addition to algorithm choices, and NSA expects to provide protocol guidance to ensure smooth and secure operation with CNSA 2.0 algorithms.  A: NSAは、さまざまな使用事例においてCNSA 2.0アルゴリズムを安全に使用するための指針を提供し、IETFと協力してRFCシリーズを通じてプロトコルの展開を支援する情報ガイドを作成している。RFCはアルゴリズムの選択に加えてプロトコルのオプションを詳細に説明しており、NSAはCNSA 2.0アルゴリズムの円滑かつ安全な運用を確保するためのプロトコル指針を提供できると期待している。
Q: For whom is this guidance intended?  Q: このガイダンスは誰を対象としているのか?
A: NSA makes CNSA 2.0 requirements, anticipated timing, and this related FAQ widely available primarily to assist NSS owners and operators in their transition planning, as well as to inform industry and vendors of NSS requirements. This guidance may also be useful to those seeking to interoperate with NSS or those aiming at similar robust security and interoperability requirements.  A: NSAは、主にNSSの所有者および運用者が移行計画を立てる際に役立つよう、また業界およびNSS要件のベンダーに情報を提供するために、CNSA 2.0の要件、予定時期、および関連するFAQを広く公開している。このガイダンスは、NSSとの相互運用を検討している人々や、同様の強固なセキュリティおよび相互運用要件を目指している人々にも役立つ可能性がある。
Q: Does CNSA 2.0 apply to fielded equipment?  Q: CNSA 2.0は実戦配備された機器にも適用されるのか?
A: Even NSS that are in current use will need to be upgraded in a timely fashion unless the system received a waiver through the approved process. This is consistent with National Security Memorandums (NSMs) 8[2] and 10[3] as well as CNSSP 11 and CNSSP  A: 承認されたプロセスを通じて免除措置を受けていない限り、現在使用中のNSSであっても、適時にアップグレードする必要がある。これは、国家安全保障覚書(NSM)8[2]および10[3]、ならびにCNSSP 11およびCNSSPと一致している 
Q: What policies should I follow to meet NSS algorithm requirements?  Q: NSSアルゴリズム要件を満たすために従うべきポリシーは?
A: High-grade equipment will follow the guidance in CJCSN 6510[4] and CNSSAM 01-07NSM[5]. Commercial equipment will follow CNSA 1.0 until the transition mandated by CNSSP 15[6], expected to occur sometime between 2025 and 2030, depending on equipment type. In accordance with NSM-10 and CNSSP-11, QR algorithms should be implemented in NSS mission systems as National Information Assurance Partnership (NIAP) validated products or in accordance with other implementation-specific guidance. Typically, this will include, but not be limited to, requiring modules be validated by the NIST Cryptographic Module Validation Program (CMVP).  A: 高水準の機器は、CJCSN 6510[4]およびCNSSAM 01-07NSM[5]の指針に従う。商業用機器は、CNSSP 15[6]で義務付けられた移行が完了するまで、CNSA 1.0に従う。移行は、機器の種類によって、2025年から2030年の間に完了する見込みである。NSM-10およびCNSSP-11に従い、QRアルゴリズムはNIAP(National Information Assurance Partnership)が検証した製品として、またはその他の実装固有のガイダンスに従ってNSSミッションシステムに実装されるべきである。通常、これにはNIST暗号モジュール妥当性確認プログラム(CMVP)によるモジュールの妥当性確認が含まれるが、これに限定されるものではない。
Q: What is the difference between ML-KEM and CRYSTALS-Kyber or between MLDSA and CRYSTALS-Dilithium?  Q: ML-KEMとCRYSTALS-Kyber、MLDSAとCRYSTALS-Dilithiumの違いは何ですか?
A: ML-KEM and ML-DSA are fully specified standards described by NIST in FIPS 203 and 204, respectively. CRYSTALS-Kyber is the name of the proposed algorithm submitted to NIST that eventually became ML-KEM, and similarly CRYSTALS-Dilithium became ML-DSA. In particular, the CRYSTALS algorithms had a variety of versions that were slightly tweaked prior to the publication of the FIPS documents. Once NIST announced the drafting of CRYSTALS-Kyber and CRYSTALS-Dilithium into standards, NSA announced that the standards would be part of CNSA 2.0. NSA clarified the CNSA  A: ML-KEMとML-DSAは、それぞれNISTがFIPS 203および204で規定した完全な標準仕様である。CRYSTALS-Kyberは、最終的にML-KEMとなったNISTに提出されたアルゴリズムの提案名称であり、同様にCRYSTALS-DilithiumはML-DSAとなった。特に、CRYSTALSアルゴリズムには、FIPS文書が発表される前に、若干の調整が加えられたさまざまなバージョンが存在していた。NISTがCRYSTALS-KyberとCRYSTALS-Dilithiumの標準化ドラフトを発表すると、NSAは、この標準がCNSA 2.0の一部になることを発表した。NSAは、FIPS文書が発表された際に、CNSA 
2.0 language when the FIPS documents were published. Only ML-KEM and ML-DSA are in CNSA 2.0; any algorithm that is called CRYSTALS-Kyber or CRYSTALSDilithium but does not adhere to FIPS 203 or 204 is not CNSA 2.0 compliant.  FIPS文書が公開された際に、NSAはCNSA 2.0の言語を明確にした。CNSA 2.0に含まれるのはML-KEMとML-DSAのみであり、CRYSTALS-KyberまたはCRYSTALSDilithiumと呼ばれているアルゴリズムであっても、FIPS 203または204に準拠していないものはCNSA 2.0に準拠していない。
Q: Where can I learn more about hash-based signatures?  Q: ハッシュベース署名について、どこでさらに詳しく学ぶことができるか?
A: Refer to NIST standardized stateful hash-based signatures in NIST SP 800-208[7]. This standard also provides references to other technical documentation on the topic. NSA recommends using Federal Information Processing Standards (FIPS)-validated LMS or XMSS hash-based signatures to protect NSS in the specialized scenarios outlined in the standard—e.g., for firmware signing and software signing. NSA’s preferred parameter set is Section 4.2, LMS with SHA-256/192.  A: NIST SP 800-208[7]のNIST標準ステートフルハッシュベース署名を参照すること。この標準では、このトピックに関する他の技術文書への参照も提供されている。NSAは、標準で概説されている専門的なシナリオ(例えば、ファームウェア署名やソフトウェア署名)においてNSSを防御するために、連邦情報処理規格(FIPS)で妥当性確認されたLMSまたはXMSSハッシュベース署名の使用を推奨している。NSAが推奨するパラメータセットは、セクション4.2のLMS(SHA-256/192)である。 
Q: Can I use HSS or XMSSMT from NIST SP 800-208?  Q: NIST SP 800-208 の HSS または XMSSMT を使用することは可能か?
A: From NIST SP 800-208, NSA has only approved LMS and XMSS for use in NSS. The multi-tree algorithms HSS and XMSSMT are not allowed.  A: NIST SP 800-208 において、NSA が NSS での使用を承認しているのは LMS と XMSS のみである。マルチツリーアルゴリズムである HSS と XMSSMT は許可されていない。
Q: Can I use SLH-DSA (aka SPHINCS+) to sign software?  Q: SLH-DSA(別名 SPHINCS+)を使用してソフトウェアに署名することは可能か?
A: While SLH-DSA is hash-based, it is not part of CNSA and is not approved for any use in NSS.  A: SLH-DSA はハッシュベースではあるが、CNSA の一部ではなく、NSS での使用は承認されていない。
Q: I'm going to adopt LMS or XMSS for software/firmware validation for NSS. Which components need to be validated, and how? If my hardware security module (HSM) is not FIPS-validated, can I get a waiver?  Q: NSS のソフトウェア/ファームウェアの妥当性確認に LMS または XMSS を採用しようとしている。どのコンポーネントをどのように妥当性確認する必要があるか? ハードウェアセキュリティモジュール(HSM)が FIPS 認証を受けていない場合、免除を受けることは可能か?
A: Signature verification is expected to be performed by code that has been validated by NIST’s Cryptographic Algorithm Validation Program (CAVP). It is expected that signed code may be received from a variety of sources (signers). If your product is only verifying signatures, CAVP testing is all that is required.  A: 署名の検証は、NISTの暗号アルゴリズム妥当性確認プログラム(CAVP)によって妥当性確認されたコードによって実行されることが期待されている。署名されたコードは、さまざまなソース(署名者)から受け取られることが想定されている。貴社の製品が署名の検証のみを行う場合は、CAVPテストのみが必要である。
Code sources (signers) that are NSS are required to produce signatures according to  NSSであるコードソース(署名者)は、NIST SP 800-208に従って署名を行うことが求められる。
NIST SP 800-208, which requires hardware validated by NIST’s Cryptographic Module Validation Program (CMVP), or via other NSA guidance. Waivers will not be granted for this.  NISTの暗号モジュール妥当性確認プログラム(CMVP)によって妥当性確認されたハードウェア、またはその他のNSAの指針によるものが必要である。これについては免除は認められない。
While some code sources (signers) are not considered NSS themselves and may not be subject to CNSA requirements, they are expected to use code that meets the same development and operational quality as the validated code, that is, code that can pass CAVP testing for use in NSS components.  一部のコードソース(署名者)はNSSとは見なされず、CNSA要件の対象外となる可能性があるが、妥当性確認済みのコードと同じ開発および運用品質を満たすコード、すなわちNSSコンポーネントでの使用にCAVPテストに合格できるコードを使用することが求められる。 
Note: To avoid weakening the security of these signatures, one should implement signing and state management in hardware, such as an HSM. Backup flows, which may involve transferring keys between modules, must prevent state re-use.  注:これらの署名のセキュリティを弱めないように、署名とステート管理はHSMなどのハードウェアで実装すべきである。バックアップフローでは、モジュール間で鍵を転送する場合があるが、ステートの再利用を防止しなければならない。
Q: As a commercial vendor, how do I know if my NIST SP 800-208 implementation meets CNSA 2.0?  Q: 商用ベンダーとして、NIST SP 800-208の実装がCNSA 2.0に準拠しているかどうかをどのように確認すればよいか?
A: NIAP validates products against its published Protection Profiles, which will start including quantum-resistant signatures consistent with NSA’s published transition timelines. For commercial vendors, NSA does not anticipate NIAP Protection Profiles performing signature generation within the Target of Evaluation (TOE) boundary, only signature verification. As signature generation is the component of LMS/XMSS that requires state management, if only signature verification is being performed, only CAVP validation (not CMVP) will be expected to meet CNSA 2.0 for such products.  A: NIAPは、公開された保護プロファイルに照らして製品の妥当性確認を行う。この保護プロファイルには、NSAが公開した移行スケジュールに沿った量子耐性署名が含まれるようになる。商用ベンダーの場合、NSAはNIAP保護プロファイルが評価対象(TOE)の境界内で署名生成を行うことは想定しておらず、署名検証のみを行うことを想定している。署名生成はLMS/XMSSのコンポーネントであり、状態管理が必要であるため、署名検証のみが実行される場合、そのような製品ではCNSA 2.0を満たすのはCAVP妥当性確認(CMVPではない)のみとなる。 
Q: Why are signatures for software- and firmware-signing listed separately?  Q: ソフトウェア署名とファームウェア署名の署名が別々にリストされているのはなぜか?
A: The reasons for choosing separate algorithms for software- and firmware-signing are as follows:  A: ソフトウェア署名とファームウェア署名に別々のアルゴリズムを選択した理由は以下の通りである。 
• NIST standardized the algorithms in NIST SP 800-208 earlier and has CAVP validation available, while other quantum-resistant signatures may not be as easily available for integration;  • NISTは以前にNIST SP 800-208でアルゴリズムを標準化しており、CAVPの妥当性確認が利用可能であるが、他の量子耐性署名は統合が容易に利用可能ではない可能性がある。 
• This signature use-case is more urgent;  • この署名のユースケースはより緊急である。
• This selection places hash-based algorithms, with their substantial history of cryptanalysis, in a use case where their well-described potential performance issues have minimal impact. In particular, this usage coincides well with the requirement for keeping track of state—that is, ensuring a given node with its private data is not used more than once in signing software or firmware when deploying these signatures.  この選択により、暗号解読の歴史が長いハッシュベースのアルゴリズムが、その潜在的なパフォーマンスの問題が十分に説明されているため、その影響が最小限に抑えられるユースケースに置かれることになる。特に、この使用法は、状態を追跡する要件、つまり、署名ソフトウェアまたはファームウェアを展開する際に、特定のノードとそのプライベートデータが署名ソフトウェアまたはファームウェアで2回以上使用されないようにする要件にうまく適合する。
Q: Why are firmware signatures more urgent?  Q: ファームウェア署名がより緊急である理由は?
A: In many firmware-signing cases the validation algorithm is not easily updated. Thus, firmware-signing algorithms are frequently locked in for the life of a system. Even in systems that are designed for extensibility and cryptographic agility, a quantumresistant root of trust may be required in the firmware years before the rest of the system upgrades to quantum-resistance. NSA prioritizes this in its timelines to avoid unexpected costs and security issues later in the NSS transition.  A: 多くのファームウェア署名の場合、妥当性確認アルゴリズムは容易に更新できない。そのため、ファームウェア署名アルゴリズムはシステムの寿命期間中、固定されることが多い。拡張性と暗号の機敏性を目的として設計されたシステムであっても、量子コンピュータ耐性のあるルート・オブ・トラストが、他のシステムが量子コンピュータ耐性を備えるよりも何年も前にファームウェアに必要となる場合がある。NSAは、NSS移行の後に予期せぬコストやセキュリティ問題を回避するために、この点を優先事項としている。 
Q: Under what circumstances is SHA-3 available for use?  Q: SHA-3はどのような状況で使用可能か?
A: At a vendor’s discretion, for internal components of a hardware system that do not interoperate outside a vendor’s environment, SHA3-384 or -512 may also be used as part of a system’s integrity-checking process, such as secure boot. This is specifically being allowed in CNSA 2.0 to speed the transition process when vendor-specific internal processes make use of the properties of a cryptographic hash to enable them to transition to the new post-quantum signatures with minimal disruption to their workflow. In order not to be prescriptive in these cases, and due to the particular threat vectors inherent in these processes, NSA is allowing the use of either SHA-384, SHA-512, SHA3-384, or SHA3-512 for these purposes.  A: ベンダーの判断により、ベンダーの環境外で相互運用しないハードウェアシステムの内部コンポーネントでは、SHA-384または-512をシステムの完全性確認プロセス(セキュアブートなど)の一部として使用することもできる。これは、ベンダー固有の内部プロセスで暗号ハッシュの特性を利用し、ワークフローへの影響を最小限に抑えながら新しい耐量子署名への移行を可能にする場合、移行プロセスを迅速化するために、CNSA 2.0で特に許可されている。このようなケースで規定を設けないこと、およびこれらのプロセスに内在する特定の脅威ベクトルを考慮し、NSAはこれらの目的のためにSHA-384、SHA-512、SHA3-384、またはSHA3-512のいずれかの使用を許可している。
Q: Can I use SHA-3 as a hash?  Q: SHA-3 をハッシュとして使用できるか?
A: No, neither SHA-3 nor SHAKE are approved for use in CNSA 2.0 as a general purpose hash algorithm. While NSA allows any parameter set of LMS, including some that call SHA-3 as a function, NSA has not approved SHA-3 as a general purpose hash algorithm. Its use is strictly limited to those cases where it is prescribed by the standard describing an NSA-approved algorithm, such as LMS within NIST SP 800-208, or for internal hardware system processes as described above.  A: いいえ、SHA-3 も SHAKE も、汎用ハッシュアルゴリズムとして CNSA 2.0 での使用は承認されていない。NSAは、SHA-3を機能として呼び出すものを含む、LMSのあらゆるパラメータセットを許可しているが、SHA-3を汎用ハッシュアルゴリズムとして承認しているわけではない。その使用は、NSAが承認したアルゴリズムを記載した標準(NIST SP 800-208内のLMSなど)で規定されている場合、または前述の内部ハードウェアシステムプロセスに厳密に限定される。 
The SHA-2 selections are sufficient for security, and their ubiquity in the commercial world ensures interoperability. Using SHA-3 or SHAKE outside those narrowly defined applications where it is completely self-contained, such as when called within an algorithm function, significantly increases the interoperability testing burden and breaks many use cases for CNSA 2.0.  SHA-2の選択はセキュリティ上十分であり、商業世界におけるその普及率の高さは相互運用性を保証する。アルゴリズム機能内で呼び出される場合など、完全に自己完結している狭義のアプリケーション以外でSHA-3またはSHAKEを使用すると、相互運用性テストの負担が大幅に増大し、CNSA 2.0の多くの使用事例が破綻する。
Q: Where can I learn more about lattice-based key encapsulation mechanisms (KEMs) and digital signatures?  Q: ラティスベースの鍵カプセル化メカニズム(KEM)とデジタル署名について、どこで詳しく学ぶことができるか?
A: NIST’s post-quantum standardization page includes reports from previous rounds of the standardization effort which detail why NIST chose lattice-based cryptography.  A: NISTの耐量子標準化ページには、標準化作業の過去のラウンドからの報告書が含まれており、NISTがラティスベースの暗号学を選択した理由が詳細に説明されている。
These reports include summaries of all the cryptography under consideration and many references.  これらの報告書には、検討中のすべての暗号学の概要と多くの参照資料が含まれている。
Q: Why did NSA choose ML-DSA over FN-DSA (aka Falcon)?  Q: NSAはなぜFN-DSA(別名ファルコン)ではなくML-DSAを選択したのか?
A: For NSS, NSA agrees with NIST: ML-DSA is preferred, as FN-DSA seems more susceptible to implementation errors that may affect security. As NIST has prioritized standardizing ML-DSA, FN-DSA is not available yet, and NSA does not anticipate adding it to CNSA 2.0 when it is.  A: NSSでは、NSAはNISTの見解に同意している。FN-DSAは実装エラーの影響を受けやすく、セキュリティに影響を与える可能性があるため、ML-DSAが推奨される。NISTがML-DSAの標準化を優先しているため、FN-DSAはまだ利用可能ではなく、NSAはそれがCNSA 2.0に追加されることは想定していない。 
Q: Can I use ML-DSA for firmware or software signing?  Q: ML-DSAをファームウェアやソフトウェアの署名に使用することは可能か?
A: Yes, however firmware roots of trust are a critical component to upgrade and NSA expects this to be implemented for some long-lived signatures in 2025, before validated ML-DSA is widely available. At this time, validated LMS and XMSS are commercially available. NSA prefers to see this transition begin now (using LMS and XMSS) rather than wait for ML-DSA due to the long timeframes involved in moving from small components and/or early designs to completed products.  A: はい、ただしファームウェアの信頼の基点はアップグレードに不可欠な要素であり、NSAは、妥当性確認済みのML-DSAが広く利用可能になる前の2025年までに、いくつかの長寿命の署名にこれが実装されることを期待している。現時点では、妥当性確認済みのLMSおよびXMSSは市販されている。NSAは、小規模なコンポーネントや初期設計から完成品に移行するには長い期間を要することから、ML-DSAを待つよりも、今すぐに(LMSおよびXMSSを使用して)この移行を開始することを望んでいる。
Validated ML-DSA is approved for all signing use cases and when it is available it may be the most appropriate choice for some software/firmware signing use cases. For example, when a user’s software signing strategy requires more signatures than can be reasonably used with a single LMS or XMSS key, or in software development environments with a distributed signing system, it would be reasonable to use ML-DSA.  妥当性確認済みのML-DSAは、すべての署名ユースケースで承認されており、利用可能になれば、一部のソフトウェア/ファームウェア署名ユースケースでは最も適切な選択肢となる可能性がある。例えば、ユーザーのソフトウェア署名戦略で、単一のLMSまたはXMSSキーで合理的に使用できる数を超える署名が必要な場合、または分散署名システムを使用するソフトウェア開発環境では、ML-DSAを使用するのが妥当である。
Q: Is HashML-DSA, aka the pre-hash mode of ML-DSA, allowed in CNSA 2.0?  Q: HashML-DSA(別名、ML-DSAのプレハッシュモード)はCNSA 2.0で許可されているか?
A: Not at the present time. HashML-DSA is a variant on ML-DSA in FIPS 204, which describes a method of compressing a message before signing while intentionally breaking interoperability with ML-DSA to prevent a vulnerability in the case of key reuse. Because HashML-DSA does not offer any functionality not already offered by the CNSA hash functions combined in a standard way with ML-DSA-87, and because standard ML-DSA-87 is expected to be widely supported, NSA anticipates there will be no need for HashML-DSA in NSS. Hence, at this time, HashML-DSA is not allowed. If at a later date protocol usage demands it, NSA will provide specific guidance on its limited usage at that time.  A: 現時点では許可されていない。HashML-DSAはFIPS 204におけるML-DSAの変形であり、鍵の再利用による脆弱性を防ぐために、ML-DSAとの相互運用性を意図的に断ち切って署名前にメッセージを圧縮する方法を記述している。HashML-DSAは、CNSAハッシュ関数とML-DSA-87を標準的な方法で組み合わせたものにすでに提供されていない機能を提供するものではないため、また、標準的なML-DSA-87は広くサポートされることが予想されるため、NSAはNSSにおいてHashML-DSAの必要はないと見込んでいる。したがって、現時点ではHashML-DSAは許可されていない。将来、プロトコルの使用状況により必要が生じた場合、NSAはその時点での限定的な使用に関する具体的なガイダンスを提供する。
Q: Will NSA add more selections to CNSA in the future?  Q: NSAは今後、CNSAにさらに選択肢を追加する予定はあるか?
A: NSA does not currently plan to add future NIST post-quantum standards to CNSA. Circumstances could change in ways not currently foreseen, but adding more algorithms generally makes interoperability more complex (although admittedly less so for algorithms for software and firmware signing).  A: NSAは現時点では、CNSAに将来のNIST耐量子標準を追加する計画はない。状況は現在予期されていない方法で変化する可能性があるが、アルゴリズムを追加すると一般的に相互運用性がより複雑になる(ただし、ソフトウェアおよびファームウェア署名用のアルゴリズムについては、その可能性は低い)。
Q: What if my solution uses hash functions other than SHA-384 or SHA-512?  Q: 私のソリューションがSHA-384またはSHA-512以外のハッシュ機能を使用している場合はどうなるか?
A: SHA-384 remains approved in the CNSA 2.0, as NSA believes it provides sufficient security for NSS. Designers often prefer to use SHA-512 for performance reasons. This is now supported by CNSA 2.0; however, customers need to be certain that using SHA512 does not lead to interoperability issues.  A: SHA-384は、NSAがNSSに十分なセキュリティを提供すると考えているため、CNSA 2.0では承認されたままである。設計者は、パフォーマンス上の理由からSHA-512を使用することを好むことが多い。これは現在、CNSA 2.0でサポートされているが、顧客はSHA512を使用することで相互運用性の問題が発生しないことを確認する必要がある。
Where NSA has approved an algorithm or cryptographic application that incorporates a truncated hash value (e.g., SHA-256/192) or other NIST-approved hash function (e.g., SHA-3) as part of its design, using those hash functions is acceptable within the scope of the algorithm or cryptographic application. Also, use of SHA3-384 and SHA3-512 is allowed in internal hardware processes, but general purpose use of such hash functions is not approved at this time for NSS.  NSAが、短縮ハッシュ値(例:SHA-256/192)やその他のNIST承認のハッシュ関数(例:SHA-3)を設計の一部として組み込んだアルゴリズムや暗号化アプリケーションを承認している場合、それらのハッシュ関数は、そのアルゴリズムや暗号化アプリケーションの範囲内であれば使用可能である。また、SHA3-384およびSHA3-512は内部のハードウェア処理での使用は許可されているが、このようなハッシュ機能の汎用的な使用は、現時点ではNSSでは承認されていない。
Just as SHA-512 was added to CNSA, NSA may in the future add another NIST algorithm if it achieves ubiquity in a key area of the ecosystem, satisfies NSA’s independent security requirements, and is unlikely to interfere with interoperability.  SHA-512がCNSAに追加されたように、NSAは将来、エコシステムの主要分野で普及し、NSA独自のセキュリティ要件を満たし、相互運用性を妨げる可能性が低い場合、別のNISTアルゴリズムを追加する可能性がある。 
Q: How is CNSA 2.0 implementation enforced in NSS?  Q: CNSA 2.0の実装は、NSSでどのように実施されるのか?
A: Authorizing officials will be reporting regularly on adoption of CNSA 2.0 in accordance with NSM-10. It is important they use the tools and resources available to ensure all systems that use cryptography for security (including software update mechanisms) implement CNSA 2.0 algorithms. The authorizing officials must report any deviations to NSA in accordance with NSM-10 processes.  A: 認可当局は、NSM-10に従って、CNSA 2.0の採用状況について定期的に報告する。暗号化技術をセキュリティに利用するすべてのシステム(ソフトウェア更新メカニズムを含む)がCNSA 2.0アルゴリズムを実装していることを確認するために、利用可能なツールやリソースを使用することが重要である。認可当局は、NSM-10のプロセスに従って、逸脱事項をNSAに報告しなければならない。 
Q: Can a commercial product be used in my NSS that runs cryptography other than in CNSA 2.0?  Q: 商用製品をNSSで使用して、CNSA 2.0以外の暗号化を実行することは可能か?
A: If a commercial product does not use CNSA 2.0 algorithms, it is not allowed to be used to protect NSS, unless NSA has provided specific written guidance otherwise. CNSA 2.0 relies on NIST standardized algorithms, which have been widely vetted as quantum resistant, and other algorithms should not be employed. Further, CNSSP-11 requires that commercial products used in NSS be NIAP validated, and this validation will generally require CNSA 2.0 compliance.  A: 商用製品がCNSA 2.0アルゴリズムを使用していない場合、NSAが書面で別段の指示を出していない限り、NSSの防御に使用することは許可されない。CNSA 2.0はNIST標準アルゴリズムに依存しており、このアルゴリズムは量子耐性があることが広く検証されているため、他のアルゴリズムを使用すべきではない。さらに、CNSSP-11では、NSSで使用される商用製品はNIAPの妥当性確認を受けていることが求められており、この妥当性確認には一般的にCNSA 2.0への準拠が必要となる。
Q: When should deployment of CNSA 2.0 algorithms in mission systems begin?  Q: 業務システムへのCNSA 2.0アルゴリズムの展開はいつ開始すべきか?
A: When validated products become available, they should be deployed in mission systems. NIAP and the Commercial Solutions for Classified (CSfC) program both intend to swiftly update profiles as validation with new products becomes feasible. For systems outside these programs, please refer to CNSSP 15 and future guidance for deprecation schedules of quantum-vulnerable cryptography. Meanwhile, NSA encourages responsible testing in vendor and government research environments now to understand the effects of deployment of the new algorithms on particular systems given the increased sizes used in these algorithms.  A: 妥当性確認済みの製品が入手可能になった時点で、業務システムに展開すべきである。NIAPおよび商用分類ソリューション(CSfC)プログラムの両者は、新製品に対する妥当性確認が可能になった時点でプロファイルを迅速に更新する予定である。これらのプログラム以外のシステムについては、量子脆弱暗号の廃止スケジュールについては、CNSSP 15および今後のガイダンスを参照のこと。一方、NSAは、これらのアルゴリズムで使用されるサイズが増加していることを踏まえ、特定のシステムにおける新アルゴリズムの展開の影響を理解するために、現在、ベンダーおよび政府の研究環境における責任あるテストを推奨している。 
Timeframe  スケジュール
Q: What timeframe information can NSA provide for adoption of CNSA 2.0?  Q: NSAはCNSA 2.0の採用について、どのようなスケジュール情報を提供できるか?
A: NSA intends that all NSS will be quantum-resistant by 2035, in accordance with the goal espoused in NSM-10. NSA’s recent update to CNSSP 15 has set several dates to aid in this transition in the commercial space, with the hope of completing much of the transition sooner.  A: NSAはNSM-10で提唱された目標に従い、2035年までにすべてのNSSが量子耐性を持つことを目指している。NSAはCNSSP 15の最近の更新で、商業分野におけるこの移行を支援するためにいくつかの日付を設定し、移行の大部分をより早期に完了することを期待している。 
Any NSS currently validated against a NIAP or CSfC profile continues to be approved for the life of that validation, and no requirement to transition will be enforced prior to December 31, 2025. However, any NSS not CNSA 1.0 compliant has six months from the publication date of the updated CNSSP 15 to come into compliance with CNSA 2.0, or 90 days to request a waiver.  NIAPまたはCSfCプロファイルに対して現在妥当性確認されているNSSは、その妥当性確認が有効である限り承認され続ける。また、2025年12月31日以前に移行を強制されることはない。ただし、CNSA 1.0に準拠していないNSSは、更新されたCNSSP 15の発行日から6か月以内にCNSA 2.0に準拠するか、または90日以内に免除を申請しなければならない。 
CNSSP 15 states that by January 1, 2027, all new acquisitions for NSS will be required to be CNSA 2.0 compliant unless otherwise noted.  CNSSP 15では、2027年1月1日までに、特に記載のない限り、NSSのすべての新規取得品はCNSA 2.0に準拠することが義務付けられると規定している。
By December 31, 2030, all equipment and services that cannot support CNSA 2.0 must be phased out unless otherwise noted, and by December 31, 2031, CNSA 2.0 algorithms are mandated for use unless otherwise noted.  2030年12月31日までに、CNSA 2.0をサポートできないすべての機器およびサービスは、特に記載がない限り段階的に廃止され、2031年12月31日までに、特に記載がない限りCNSA 2.0アルゴリズムの使用が義務付けられる。
Q: Will I need to transition all my algorithms to CNSA 2.0 at once?  Q: すべてのアルゴリズムを一度にCNSA 2.0に移行する必要があるのか? 
A: As NSS transition to CNSA 2.0 by 2031, NSA expects to have a long period of systems using both CNSA 1.0 and 2.0 in different places. New NSS developments will be required to support CNSA 2.0 algorithms once appropriate standards for the given technology are in place. All appropriate system components should be configured to prefer CNSA 2.0 algorithms. As products mature, those components should be configured to accept only CNSA 2.0 algorithms.  A: NSS が 2031 年までに CNSA 2.0 へ移行するにつれ、NSA は、さまざまな場所で CNSA 1.0 と 2.0 の両方を使用するシステムが長期間にわたって存在すると予想している。特定の技術に関する適切な標準が策定された後は、新しい NSS の開発では CNSA 2.0 アルゴリズムをサポートすることが求められる。すべての適切なシステムコンポーネントは、CNSA 2.0 アルゴリズムを優先するように構成すべきである。製品が成熟するにつれ、それらのコンポーネントはCNSA 2.0アルゴリズムのみを受け入れるように設定されるべきである。
NSA will provide guidance and updated protection profiles as Standard Development Organizations (SDOs) develop the appropriate standards because product lines may develop at different speeds, and not every profile supporting CNSA 2.0 will support it for every cryptographic service offered. CNSA 1.0 algorithms will continue to be used until current solutions can operate in a CNSA 2.0 mode.  製品ラインは異なる速度で開発される可能性があり、CNSA 2.0をサポートするすべてのプロファイルが、提供されるすべての暗号化サービスをサポートするわけではないため、NSAは、標準開発機関(SDO)が適切な標準を策定する際に、ガイダンスと更新された防御プロファイルを提供する。現在のソリューションがCNSA 2.0モードで動作するようになるまでは、CNSA 1.0アルゴリズムが引き続き使用される。 
Q: What is the timeline for new deployments?  Q: 新たな展開のスケジュールはどのようになっているか?
A: NIAP and the CSfC program will update their profiles and requirements in accordance with industry adoption. NSA intends an aggressive timeframe for adoption (see above) and requests industry support. Starting January 1, 2027, NSA expects new deployments to be compliant with CNSA 2.0, unless otherwise explicitly noted in profiles.  A: NIAPおよびCSfCプログラムは、業界での採用状況に応じてプロファイルと要件を更新する。NSAは積極的な採用期間(上記参照)を想定しており、業界の支援を求めている。2027年1月1日より、NSAはプロファイルに特に明記されていない限り、新たな展開はCNSA 2.0に準拠するものと想定している。
Q: What is the timeline for transitioning fielded equipment?  Q: 実装済みの機器の移行のスケジュールは?
A: As industry adopts CNSA 2.0 algorithms, NSA will require transition of fielded equipment to CNSA 2.0 as well. In some circumstances, this may require a hardware refresh. NSA encourages NSS owners and operators to plan for this.  A: 業界が CNSA 2.0 アルゴリズムを採用するのに伴い、NSA は実装済みの機器の CNSA 2.0 への移行も要求する。状況によっては、ハードウェアの更新が必要になる場合もある。NSA は NSS の所有者および運用者に、この計画を立てることを推奨する。
Cryptographic agility is necessary to accomplish this transition in a timely manner; even equipment purchased before support is mandated should have sufficient memory and processing power when possible to run new algorithms, as well as capacity for future algorithms and protocols so that any future enhancements can be included via a software update.  この移行を迅速に完了するには、暗号化の機敏性が必要である。サポートが義務化される前に購入された機器であっても、新しいアルゴリズムを実行できるだけの十分なメモリと処理能力を備えていることが望ましい。また、将来的なアルゴリズムやプロトコルに対応できる容量も備えておくことで、ソフトウェアの更新を通じて将来的な機能強化を盛り込むことができる。
NSA expects these equipment transitions to be completed by December 31, 2030.  NSAは、これらの機器の移行が2030年12月31日までに完了することを期待している。
Q: When will IETF RFCs containing guidance on configurations for CNSA 2.0 compliant protocols be available?  Q: CNSA 2.0 準拠のプロトコルの構成に関する指針を含む IETF RFC はいつ入手可能になるのか?
A: IETF and other SDOs are independent bodies that are in charge of their own publication schedules. Due to the interest in this guidance beyond standard NSA customers, and to facilitate quantum-resistant deployment more broadly, NSA is working with IETF and other SDOs to produce RFCs and other documentation with the appropriate level of security and implementation analysis. NSA encourages CNSA 2.0 adoption in standards and deployment in vendor products, but it is not a requirement beyond NSS.  A: IETF およびその他の SDO は、独自の発行スケジュールを管理する独立した団体である。NSA の標準的な顧客以外にもこのガイダンスに関心があること、および量子耐性のある展開をより広く促進するために、NSA は IETF およびその他の SDO と協力し、適切なレベルのセキュリティと実装分析を含む RFC およびその他の文書を作成している。NSA は、標準への CNSA 2.0 の採用とベンダー製品への展開を奨励しているが、NSS 以外の要件ではない。 
CNSSP 15 and NSM 10  CNSSP 15およびNSM 10
Q: What is National Security Memorandum (NSM) 10?  Q: 国家安全保障覚書(NSM)10とは何ですか?
A: National Security Memorandum 10: Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems lays out a variety of tasks for the federal government to undertake with the goal of achieving quantum resistance by 2035, including the creation of quantum-resistant standards and the deprecation of quantum-vulnerable standards. NSA is explicitly called out to provide timely guidance for quantum resistance in NSS, and NSS owners are given annual reporting requirements for quantum-vulnerable systems.  A: 国家安全保障覚書10(National Security Memorandum 10)は、「脆弱な暗号システムに対するリスクを緩和しながら、量子コンピューティングにおける米国のリーダーシップを推進する」という内容であり、2035年までに量子耐性を実現することを目標に、連邦政府が取り組むべきさまざまなタスクを定めている。これには、量子耐性のある標準の策定や、量子脆弱性のある標準の廃止などが含まれる。NSSでは、NSAに対して量子耐性に関するタイムリーなガイダンスの提供が明確に求められており、NSSのオーナーには、量子脆弱性のあるシステムに関する年次報告要件が課されている。
Q: What is CNSSP 15?  Q: CNSSP 15とは何ですか?
A: Committee on National Security Systems Policy 15 (CNSSP 15) specifies commercial cryptographic algorithms for protecting NSS, in conjunction with other CNSS- and NSA-documented processes. Originally, it specified “NSA Suite B” as the required commercial algorithms for protecting NSS, and then it was revised to specify the CNSA 1.0 Suite in CNSSP 15 Annex B. It now includes CNSA 2.0 algorithms as NIST has completed its initial standards from its Post-Quantum Standardization Process. Further details about CNSS are at www.cnss.gov.  A: 国家安全保障システム政策委員会15(CNSSP 15)は、他のCNSSおよびNSA文書化プロセスと併せて、NSS防御のための商用暗号アルゴリズムを規定している。当初は、NSS防御に必要な商用暗号アルゴリズムとして「NSA Suite B」が指定されていたが、その後、CNSSP 15の附属書BでCNSA 1.0 Suiteを指定するように改訂された。現在では、NISTが耐量子標準化プロセスから初期標準を完成させたため、CNSA 2.0アルゴリズムも含まれている。CNSSの詳細については、www.cnss.govを参照のこと。 
Q: What changes are in the CNSSP 15 update?  Q: CNSSP 15のアップデートにはどのような変更が含まれているのか?
A: The 2024 update to CNSSP 15 makes three significant changes in order to execute NSM 10 for its users. These are as follows:  A: 2024年のCNSSP 15のアップデートでは、NSM 10をユーザーに実行させるために、3つの重要な変更が加えられた。 変更点は以下の通りである。
1. It updated the list of allowed algorithm standards, which was previously defined as CNSA 1.0, to now require CNSA 2.0. This deprecated all quantum-vulnerable algorithms, added quantum-resistant public key mechanisms, as well as added SHA-512 into general usage and SHA3 into specific applications.  1. 許可されたアルゴリズム標準のリストが更新され、以前はCNSA 1.0と定義されていたものが、現在はCNSA 2.0を必要とするようになった。これにより、量子脆弱性のあるアルゴリズムはすべて廃止され、量子耐性のある公開鍵メカニズムが追加されたほか、SHA-512が一般用途に、SHA3が特定の用途に追加された。 
2. It set out dates for the transition from CNSA 1.0 to CNSA 2.0, including adoption dates for new systems, as well as deprecation dates for currently deployed systems.  2. CNSA 1.0 から CNSA 2.0 への移行期限を定め、新しいシステムの採用日と現在展開されているシステムの廃止日を定めた。
3. It revoked the previous eight years of waivers to CNSSP 15, which therefore requires modernization of several NSS.  3. CNSSP 15 に対する過去8年間の免除を取り消し、これにより複数の NSS の近代化が求められることになった。 
Q: As an NSS owner, when will my quantum-resistant transition be completed with regard to the reporting requirements under NSM 10?  Q: NSS の所有者として、NSM 10 の報告要件に関して、私の量子耐性移行はいつ完了するのか?
A: As noted in CNSSP 15, as long as any component of an NSS is still not quantumresistant, there will still be reporting requirements under NSM 10. Hence, while CNSSP 15 allows the use of currently validated profiles that rely on CNSA 1.0, as long as a profile requires any non-CNSA 2.0 algorithm to function securely (such as those in CNSA 1.0) it will be reportable under NSM 10. NSA expects this to continue for many customers through December 31, 2031, when the vast majority of cryptography in an NSS should be quantum resistant.  A: CNSSP 15 に記載されているように、NSS のいずれかのコンポーネントが依然として量子耐性でない限り、NSM 10 の報告要件は引き続き存在する。したがって、CNSSP 15では、CNSA 1.0に基づく現在妥当性確認済みのプロファイルの使用が認められているが、プロファイルが安全に機能するためにCNSA 2.0以外のアルゴリズム(CNSA 1.0のものなど)を必要とする限り、NSM 10に基づく報告が必要となる。NSAは、NSSの暗号化技術の大半が量子耐性を持つべきである2031年12月31日まで、多くの顧客に対してこの状態が継続すると見込んでいる。
Q: How does CNSSP 15 relate to CNSSI 1253, NIST SP 800-53, and the RMF process?  Q: CNSSP 15は、CNSSI 1253、NIST SP 800-53、およびRMFプロセスとどのように関連しているのか?
A: CNSS Instruction 1253[8] mandates using the Risk Management Framework (RMF) as documented in NIST SP 800-39[9] and NIST SP 800-5310 in managing National Security Information Systems. NIST SP 800-53 includes security controls (e.g., SC-12) that relate to cryptography. NSS requires the “NSA Approved” selection. Unless NSA states otherwise, the “NSA Approved” cryptography selection includes CNSA 2.0 algorithm requirements as well as all other relevant NSA guidance on product validation and operation.  A: CNSS 指令 1253[8] は、国家機密情報システムの管理において、NIST SP 800-39[9] および NIST SP 800-5310に記載されているリスクマネジメント枠組み(RMF)の使用を義務付けている。 NIST SP 800-53 には、暗号化に関連するセキュリティ管理(SC-12 など)が含まれている。 NSS では、「NSA 承認済み」の選択を要求している。NSAが特に言及しない限り、「NSA Approved」暗号化方式の選択には、CNSA 2.0アルゴリズム要件および製品妥当性確認と運用に関するその他のすべての関連NSAガイダンスが含まれる。
Q: How should the broader government community understand CNSSP 15 requirements?  Q: 政府機関全体は、CNSSP 15要件をどのように理解すべきか?
A: NSA establishes NSS requirements. Often these systems require protection for long periods against sophisticated targeted efforts and well-resourced adversaries in potential wartime settings. NIST establishes cryptographic standards for other government systems.  A: NSAはNSS要件を策定する。これらのシステムは、潜在的な戦時設定における高度な標的型攻撃や豊富なリソースを持つ敵対者に対して、長期間にわたって防御することが求められることが多い。NISTは、他の政府システム向けの暗号化標準を策定している。
NSA selected the algorithms in CNSSP 15 from those chosen by NIST in order to satisfy both NSA requirements for NSS and to simplify implementation and interoperability by aligning with NIST standards for general government use. If you are uncertain whether NSS requirements apply to a specific system, contact NSA for assistance. Also see NIST SP 800-59[10].  NSAは、NSSに対するNSAの要件を満たすと同時に、一般政府利用向けのNIST標準に整合させることで実装と相互運用性を簡素化するために、NISTが選定したアルゴリズムの中からCNSSP 15のアルゴリズムを選定した。特定のシステムにNSS要件が適用されるかどうか不明な場合は、NSAに問い合わせること。また、NIST SP 800-59[10]も参照すること。
Quantum alternatives  量子コンピューターの代替策
Q: Can I mitigate the quantum threat to NSS by using a pre-shared key?  Q: 事前共有鍵を使用することで、NSSに対する量子コンピューターの脅威を緩和できるか?
A: Many commercial protocols allow a pre-shared key option that may mitigate the quantum threat, and some allow the combination of pre-shared and asymmetric keys in the same negotiation. However, this issue can be complex. Customers who wish to explore this option should contact NSA or follow guidance the CSfC program provides.  A: 多くの商業用プロトコルでは、量子脅威を緩和する可能性のある事前共有鍵オプションが利用でき、一部のプロトコルでは、同じネゴシエーションで事前共有鍵と非対称鍵の組み合わせも可能である。しかし、この問題は複雑である可能性がある。このオプションを検討したいお客様は、NSAに問い合わせるか、またはCSfCプログラムが提供するガイダンスに従うべきである。
Q: Will quantum computers affect non-public-key (i.e., symmetric) algorithms?  Q: 量子コンピュータは非公開鍵(すなわち、対称)アルゴリズムに影響を与えるか?
A: Quantum computing techniques are generally considered much less effective against symmetric algorithms than against current widely used public-key algorithms. While public-key cryptography requires fundamental design changes, symmetric algorithms are considered secure, provided the key size is sufficiently large. CNSA 2.0 symmetric algorithms, which essentially are the same as their CNSA 1.0 counterparts, are quantum-resistant.  A: 一般的に、量子コンピューティング技術は、現在広く使用されている公開鍵アルゴリズムよりも対称アルゴリズムに対してはるかに有効ではないと考えられている。公開鍵暗号化方式では基本的な設計変更が必要となるが、対称アルゴリズムは、鍵のサイズが十分に大きい場合、安全であると考えられている。CNSA 2.0の対称アルゴリズムは、基本的にCNSA 1.0の対称アルゴリズムと同じであり、量子コンピューティングに耐性がある。
Q: Why does NSA care about quantum computing today? Isn’t quantum computing a long way off?  Q: なぜNSAは今日、量子コンピューティングを気にかけているのか?量子コンピューティングはまだ先の話ではないのか?
A: NSA has specific requirements documented in NSM 10 to provide quantum resistance for NSS by 2035, which requires concrete steps to be taken over the next decade to achieve. NSA does not know when there will be a CRQC. Expert assessments disagree significantly about timing. Because NSS often have very long lifecycles, NSA must produce requirements today for systems that will be used many decades in the future. Consequently, the data these systems protect will still require cryptographic protection for decades after these systems are at end of life. There is growing research in the area of quantum computing, and enough progress that NSA must act now to protect NSS by providing the requirements for the transition to CNSA 2.0.  A: NSAはNSM 10に具体的な要件を文書化しており、2035年までにNSSに量子耐性を持たせることを求めている。これは今後10年間で達成すべき具体的なステップを必要とする。NSAはCRQCがいつ起こるかを知らない。専門家のアセスメントでは、時期について大きく意見が分かれている。NSSのライフサイクルは非常に長い場合が多いため、NSAは数十年後に使用されるシステムに対する要件を今日作成しなければならない。その結果、これらのシステムが寿命を迎えた後も、これらのシステムが防御するデータは数十年間暗号化による防御が必要となる。量子コンピューティングの分野では研究が進んでおり、NSAはCNSA 2.0への移行要件を提供することでNSSを防御するために、今行動を起こさなければならないほど十分な進歩を遂げている。 
Q: What is quantum key distribution (QKD)?  Q: 量子鍵配送(QKD)とは何ですか?
A: The field of quantum cryptography involves specialized hardware using the physics of quantum mechanics to protect the confidentiality of sensitive information. The most common example today uses quantum physics to distribute keys for use in a traditional symmetric algorithm, known as “quantum key distribution” or QKD. This technology exists today and is distinct from the quantum computing technology that might one day attack cryptographic algorithms. The sole function of QKD is to distribute keys between users. Hence, it is only one part of a cryptographic system.  A: 量子暗号化の分野では、量子力学の物理的特性を利用した専用ハードウェアを使用して、機密性の高い情報の機密性を保護している。今日最も一般的な例としては、量子物理学を使用して、従来の対称アルゴリズムで使用する鍵を配布する「量子鍵配送」またはQKDと呼ばれる技術がある。この技術は現在すでに存在しており、暗号化アルゴリズムを攻撃する可能性のある量子コンピューティング技術とは異なる。QKDの唯一の機能は、ユーザー間で鍵を配布することである。したがって、暗号化システムの一部にすぎない。
Q: Can I use a QKD system to protect my national security system from a quantum computer?  Q: QKDシステムを使用して、量子コンピュータから国家安全保障システムを防御することは可能か?
A: No. The technology involved is of significant scientific interest, but it only addresses some security threats and requires significant engineering modifications to NSS communications systems. NSA does not generally consider QKD a practical security solution for protecting NSS. NSS owners should not use or research QKD at this time without consulting NSA directly. For specific questions, NSS owners can contact NSA.  A: いいえ。この技術は科学的に非常に興味深いものですが、一部のセキュリティ脅威に対処するだけであり、NSSコミュニケーションシステムに大幅な技術的変更を加える必要があります。NSAは、一般的にQKDをNSSを防御するための実用的なセキュリティソリューションとは考えていません。NSSの所有者は、NSAに直接相談することなく、現時点でQKDを使用したり研究したりすべきではありません。具体的な質問については、NSSの所有者はNSAに問い合わせることができます。
Q: What is a quantum random number generator (quantum RNG)?  Q: 量子乱数生成器(量子RNG)とは何ですか? 
A: Quantum random number generators are hardware random number generators that use specific quantum effects to generate nondeterministic randomness. The decision on which RNG is appropriate in a specific scenario depends on many factors. In addition, any properly certified/approved RNG should be acceptable if you implement it within the constraints of that approval.  A: 量子乱数生成器は、特定の量子効果を利用して非決定論的なランダム性を生成するハードウェア乱数生成器である。特定のシナリオにおいてどのRNGが適切であるかは、多くの要因に依存する。さらに、適切に認証/承認されたRNGであれば、承認の制約内で実装する場合は、いずれも受け入れられるはずである。
Commercial Solutions for Classified (CSfC) and National Information Assurance Partnership (NIAP)  機密情報分類(CSfC)および国家情報保証パートナーシップ(NIAP)のための商用ソリューション 
Q: Can I use any CNSA-capable product(s) in my NSS without going through NIAP/CSfC?  Q: NIAP/CSfCの認証を受けずに、CNSA対応製品をNSSで使用することはできますか?
A: No, CNSSP 11 states that all commercial-off-the-shelf information assurance (IA) and IA-enabled information technology products acquired to protect information on NSS shall comply with NIAP program requirements according to NSA-approved processes and, where applicable, the requirements of FIPS cryptographic validation programs. Furthermore, CNSSP 7 states that a CSfC solution may protect NSS, provided the appropriate Authorizing Official approved it and registration with NSA’s CSfC Program Management Office showed it is compliant with an NSA-provided Capability Package.  A: いいえ、CNSSP 11では、NSS上の情報を防御するために取得されたすべての市販情報保証(IA)およびIA対応情報技術製品の使用にあたっては、NSAが承認したプロセスに従ってNIAPプログラム要件を満たし、該当する場合はFIPS暗号妥当性確認プログラムの要件も満たさなければならないと規定されている。さらに、CNSSP 7では、適切な認可当局が承認し、NSAのCSfCプログラム管理室への登録によりNSAが提供する能力パッケージに準拠していることが示されている場合、CSfCソリューションがNSSを防御できる可能性があると述べている。
Q: I have long data life concerns and want to adopt CSfC solutions. How can I ensure my communications and data remain secure against an adversary with a quantum computer?  Q: データの長期保存に懸念があり、CSfCソリューションを採用したいと考えている。量子コンピュータを搭載した敵対者に対して、通信とデータのセキュリティを確保するにはどうすればよいか?
A: Some CSfC solutions may be implemented today using symmetric, pre-shared keys that protect against the long-term quantum computing threat. NSA considers using preshared symmetric keys in a standards-compliant fashion a better near-term postquantum solution than implementing unvalidated post-quantum asymmetric algorithms. Eventually, NSA will provide Capability Packages—to coincide with commercial technological development—to support CNSA 2.0 algorithms.  A: 対称型事前共有鍵を使用することで、量子コンピューティングの長期的な脅威から防御するCSfCソリューションを現在実装できるものもある。NSAは、検証されていない耐量子非対称アルゴリズムを実装するよりも、標準に準拠した事前共有対称鍵を使用する方が、より優れた短期的なポスト量子ソリューションであると考えている。最終的には、NSAはCNSA 2.0アルゴリズムをサポートするために、商業技術開発と歩調を合わせて、能力パッケージを提供する予定である。
For details, contact the CSfC program office.  詳細については、CSfCプログラムオフィスまでお問い合わせください。
Future cryptographic algorithms  今後の暗号化アルゴリズム
Q: What algorithms should I use for other areas of cryptography (e.g., Blockchain, Private Information Retrieval, Identity Based Encryption)?  Q: 暗号化の他の分野(ブロックチェーン、プライベート情報検索、IDベース暗号化など)では、どのようなアルゴリズムを使用すべきか?
A: NSA wants to know about potential use cases for any of the innovative cryptography listed below (or other similar cryptographic innovation). CNSSP 15 mandates using public standards, while allowing exceptions for additional NSA-approved options when needed. Neither NSA nor NIST has produced standards for these areas, and NSA has not issued any general approval for using these technologies on NSS.  A: NSAは、以下に列挙する革新的な暗号化技術(またはその他の類似の暗号化技術)の潜在的な使用事例について知りたいと考えている。CNSSP 15では、公開標準の使用が義務付けられているが、必要に応じてNSAが承認した追加オプションの例外を認めている。NSAもNISTも、これらの分野の標準を策定しておらず、NSAはNSSでこれらの技術を使用することに対する一般的な承認を発行していない。 
Many of these topics involve novel security properties requiring further scrutiny. NSS owners should consult NSA before using any cryptography that CNSA 1.0 or CNSA 2.0 and other published guidance do not specify. In particular, the following have no generally approved solutions:  これらのトピックの多くは、さらなる精査を必要とする新しいセキュリティ特性を含んでいる。NSSの所有者は、CNSA 1.0またはCNSA 2.0およびその他の公開された指針が指定していない暗号化技術を使用する前にNSAに相談すべきである。特に、以下のものについては、一般的に承認されたソリューションは存在しない。
• Distributed ledgers or blockchains  • 分散台帳またはブロックチェーン 
• Private information retrieval (PIR)  • プライベート情報検索(PIR) 
• Private set intersection (PSI)  プライベート共通集合(PSI)
• Identity-based encryption (IBE)  IDベース暗号(IBE)
• Attribute-based encryption (ABE)  属性ベース暗号(ABE)
• Homomorphic encryption (HE)  準同型暗号(HE)
• Group signatures  グループ署名
• Ring signatures  リング署名
• Searchable encryption  検索可能暗号
• Threshold signatures  閾値署名
Q: I have a novel cryptographic solution. How do I get my solution “NSA Approved?”   Q: 斬新な暗号化ソリューションを思いついた。どうすれば私のソリューションを「NSA承認」にできるか?
A: NSA has programs for certifying solutions built to protect classified information. This certification process applies to developments intended specifically for government use or control. NSA also manages efforts, such as NIAP and the CSfC program, that require strict compliance with traditional cryptographic standards and designs.  A: NSAには、機密情報を防御するために構築されたソリューションを認証するプログラムがある。この認証プロセスは、政府による使用または管理を目的として開発されたものに適用される。NSAはまた、NIAPやCSfCプログラムなどの取り組みも管理しており、これらは従来の暗号化標準や設計に厳格に準拠することが求められる。 
NSA does not accept direct requests from commercial vendors to validate their products or offer a general use vendor certification for novel cryptographic solutions. If an NSS customer believes they have a mission need to use cryptography beyond what is currently available, they should engage with NSA directly to discuss their unique situation.  NSAは、商業ベンダーから直接、その製品を妥当性確認したり、新しい暗号ソリューションの汎用ベンダー認証を提供したりするよう依頼を受けることはない。NSSの顧客が、現在利用可能なもの以上の暗号化技術をミッション上必要だと考える場合、その顧客は独自の状況について直接NSAと話し合うべきである。
Q: Will NSA be adopting the standards from NIST’s Lightweight Cryptography effort?  Q: NSAはNISTの軽量暗号化技術の取り組みから標準を採用する予定はあるか?
A: NSA does not intend to add the ciphers resulting from NIST’s Lightweight Cryptography effort to CNSA. The Lightweight Cryptography effort resulted in the selection of symmetric primitives based on the Ascon family. Their targeted security is substantially less than AES-256, rendering them generally unsuitable for NSS use cases. If CNSA 2.0 algorithms do not meet mission system performance requirements, early consultation with NSA is required.  A: NSAは、NISTの軽量暗号化作業による暗号をCNSAに追加するつもりはない。軽量暗号化作業では、Asconファミリーに基づく共通鍵暗号プリミティブが選択された。その目標とするセキュリティはAES-256よりも大幅に低く、NSSの使用事例には一般的に適さない。CNSA 2.0のアルゴリズムがミッションシステムのパフォーマンス要件を満たさない場合は、NSAとの早期協議が必要である。
Hybrids  ハイブリッド
Q: What is a hybrid cryptographic solution?  Q: ハイブリッド暗号ソリューションとは何ですか?
A: A hybrid solution for a protocol is one using multiple algorithms to perform the same function, such as key agreement or authentication. The solution uses algorithms in a way that requires an attacker to break each one to compromise system security. Hybrid solutions can consist of many traditional or QR algorithms. “Component algorithms” are individual algorithms used in a hybrid solution.  A: プロトコル用のハイブリッドソリューションとは、鍵共有や認証など、同じ機能を実行するために複数のアルゴリズムを使用するものを指す。このソリューションでは、攻撃者がシステムセキュリティを侵害するには、それぞれのアルゴリズムを破らなければならないようにアルゴリズムを使用する。ハイブリッドソリューションは、多くの従来のアルゴリズムまたはQRアルゴリズムで構成することができる。「コンポーネントアルゴリズム」とは、ハイブリッドソリューションで使用される個々のアルゴリズムを指す。 
Q: What is NSA’s position on the use of hybrid solutions?  Q: ハイブリッドソリューションの使用に関して、NSAはどのような立場をとっているのか?
A: NSA has confidence in CNSA 2.0 algorithms and will not require NSS developers to use hybrid certified products for security purposes. However, product availability and interoperability requirements may lead to adopting hybrid solutions.  A: NSAはCNSA 2.0アルゴリズムに信頼を寄せており、NSS開発者にセキュリティ目的でハイブリッド認証製品を使用することを要求することはない。しかし、製品の入手可能性や相互運用性の要件から、ハイブリッドソリューションを採用することになる可能性もある。 
NSA recognizes that some protocols may require using hybrid-like constructions to accommodate the larger sizes of ML-KEM-1024 or ML-DSA-87 and will work with industry and SDOs to identify the best options for implementation.  NSAは、ML-KEM-1024やML-DSA-87のようなより大きなサイズに対応するために、一部のプロトコルではハイブリッドのような構造を使用する必要があることを認識しており、業界や標準化団体と協力して実装に最適なオプションを識別する。 
Q: What complications can using a hybrid solution introduce?  Q: ハイブリッドソリューションを使用することで、どのような問題が生じる可能性があるか? 
A: Hybrid solutions add complexity to protocols and crypt libraries, as designers need to incorporate additional negotiation and error handling and implementers need to modify APIs and testing.  A: ハイブリッドソリューションは、プロトコルと暗号ライブラリに複雑性を加える。設計者は追加のネゴシエーションとエラー処理を組み込む必要があり、実装者はAPIとテストを修正する必要があるためだ。
Rather than ease the transition to quantum resistance, hybrid deployments introduce additional interoperability concerns because all the algorithms and the method of hybridization must be features common to all parties to a communication. Similarly, hybrid deployments add a second transition later as users eventually move away from classical algorithms in the future entirely and use only quantum-resistant algorithms. At the same time, hybrid solutions make the implementations more complex, so one must balance the risk of flaws in an increasingly complex implementation with the risk of a cryptanalytic breakthrough. Because more security products fail due to implementation or configuration errors than failures in their underlying cryptographic algorithms, spending limited resources to add cryptographic complexity can at times weaken security rather than improve it.  ハイブリッドソリューションの展開は、量子耐性への移行を容易にするどころか、むしろ相互運用性に関する新たな懸念をもたらす。なぜなら、すべてのアルゴリズムとハイブリッド化の手法は、コミュニケーションに関わるすべての当事者にとって共通の機能でなければならないからだ。同様に、ハイブリッドソリューションの展開は、将来的にユーザーが従来のアルゴリズムから完全に離れ、量子耐性アルゴリズムのみを使用するようになるという、2つ目の移行を後から追加することになる。同時に、ハイブリッドソリューションは実装をより複雑にするため、実装の複雑化に伴う欠陥リスクと暗号解読の画期的な進歩のリスクのバランスを取る必要がある。暗号アルゴリズムの欠陥による障害よりも実装や設定のエラーによる障害の方が多いセキュリティ製品があるため、限られたリソースを暗号の複雑化に費やすことは、セキュリティを改善するどころか、むしろ弱体化させる場合がある。
In many scenarios, adding a hybrid option will require the standards community to determine non-obvious choices, such as how to negotiate hybrid algorithms or how to combine keys securely, which may slow down the process of standardization past NSA’s deployment goals.  多くのシナリオにおいて、ハイブリッドオプションを追加するには、標準化団体がハイブリッドアルゴリズムのネゴシエーション方法や安全な鍵の組み合わせ方など、明白ではない選択を決定する必要があり、NSAの展開目標を上回る標準化のプロセスが遅れる可能性がある。
Where NSA recognizes a need to support a hybrid solution, extensive work will be performed to ensure that it can be safely implemented, including engineering to a high degree of robustness, and facilitation of a straightforward transition to QR-only solutions.  NSAがハイブリッドソリューションのサポートの必要性を認識している場合、高度な堅牢性エンジニアリングやQRのみのソリューションへのスムーズな移行の促進など、安全な実装を確実にするための広範な作業が行われる。
Q: Is there an example where NSA will recommend hybrid solutions?  Q: NSAがハイブリッドソリューションを推奨する例はあるか?
A: Due to difficulties introduced when unencrypted IKEv2 messages exceed a certain byte size, it is not possible to directly replace the CNSA 1.0 public key algorithms with ML-KEM-1024 and its larger public key. Because there is no straightforward way to construct a solution that uses a standalone ML-KEM-1024 key establishment without dramatic changes to this part of IKEv2, NSA anticipates using the solution standardized within IETF, which effectively manages this problem by performing a smaller key establishment, followed by a larger but encrypted key establishment. As a result, for the  A: 暗号化されていないIKEv2メッセージが一定のバイトサイズを超えると問題が生じるため、CNSA 1.0の公開鍵アルゴリズムをML-KEM-1024およびそれより大きな公開鍵に直接置き換えることはできない。IKEv2のこの部分に大幅な変更を加えずにスタンドアローンのML-KEM-1024鍵確立を使用するソリューションを構築する直接的な方法がないため、NSAは、より小さい鍵確立を行った後に、より大きいものの暗号化された鍵確立を行うことでこの問題を効果的に管理する、IETFで標準化されたソリューションの使用を想定している。その結果、 
foreseeable future, NSA’s profile of this solution will continue the use of CNSA 1.0 key establishment algorithms, but fortified by key establishment using ML-KEM-1024.  当面は、NSAのこのソリューションのプロファイルでは、CNSA 1.0の鍵確立アルゴリズムの使用を継続するが、ML-KEM-1024を使用した鍵確立によって強化する。
Q: Should one use a hybrid or other non-standardized QR solution while waiting for a final NIST post-quantum standard?  Q: NISTの最終的な耐量子標準規格が発表されるまで、ハイブリッドまたは他の標準化されていないQRソリューションを使用すべきか? 
A: Do not use a hybrid or other non-standardized QR solution on NSS mission systems except for those exceptions NSA specifically recommends to meet standardization or interoperability requirements. NSA encourages limited purchase and use for research and planning, but only to prepare for transitioning to a CNSA 2.0 Suite. Because NSA is confident that CNSA 2.0 algorithms will sufficiently protect NSS, it does not require a hybrid solution for security purposes. Except as noted above, hybrid solutions will not be integrated into eventual deployable solutions.  A: NSAが標準化または相互運用性の要件を満たすために特に推奨する例外を除き、NSSのミッションシステムではハイブリッドまたはその他の標準化されていないQRソリューションを使用しないこと。NSAは、研究および計画のために限定的に購入および使用することを推奨するが、CNSA 2.0スイートへの移行に備えるためだけに使用すること。NSAは、CNSA 2.0アルゴリズムがNSSを十分に防御できると確信しているため、セキュリティ目的でハイブリッドソリューションを必要としない。上記の場合を除き、ハイブリッドソリューションは最終的な展開可能なソリューションに統合されない。
Using non-standard solutions entails a significant risk of establishing incompatible solutions. Using a hybrid solution that involves a symmetric key in accordance with established standards (e.g., RFC 8773, RFC 8784) may be appropriate, but key management complexity generally restricts this to specialized applications.  非標準ソリューションを使用すると、互換性のないソリューションが確立されるリスクが大きい。確立された標準(例えば、RFC 8773、RFC 8784)に従って対称鍵を使用するハイブリッドソリューションは適切である可能性があるが、鍵管理の複雑性により、これは通常、専門アプリケーションに限定される。
Further information  詳細情報 
Q: Where can I get more information?  Q: さらに詳しい情報はどこで入手できますか?
A: For CSfC-specific questions, customers should contact the Commercial Solutions for Classified Program Management Office at CSfC@nsa.gov.  A: CSfC 固有の質問については、CSfC@nsa.gov の機密情報向け商用ソリューションプログラム管理室までお問い合わせください。 
Other specific questions from NSS users may be addressed via e-mail to NSACryptoToday@nsa.gov or through normal business channels.  NSS ユーザーからのその他の具体的な質問については、NSACryptoToday@nsa.gov 宛てに電子メールでお問い合わせいただくか、通常の業務ルートを通じてお問い合わせください。
Disclaimer of endorsement  推奨の否認 
The information and opinions contained in this document are provided "as is" and without any warranties or guarantees. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.  本書に記載される情報および意見は「現状のまま」提供され、いかなる保証または担保も付帯しない。本書における特定の商業製品、プロセス、またはサービスに関する商号、商標、製造事業者などによる言及は、米国政府による推奨、推奨、または支持を意味するものではなく、また、そのような意味を暗示するものでもない。また、本ガイドラインは広告または製品推奨の目的で使用されるものではない。 
Purpose  目的 
This document was developed in furtherance of NSA’s cybersecurity missions, including its responsibilities to identify and disseminate threats to National Security Systems, Department of Defense, and Defense Industrial Base information systems, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.  本書は、国家安全保障システム、国防総省、および防衛産業基盤の情報システムに対する脅威を識別し、周知すること、ならびにサイバーセキュリティ仕様および緩和策を策定し、発行することといった、NSAのサイバーセキュリティ任務の遂行を目的として作成された。本情報は、すべての適切な利害関係者に周知するために広く共有される可能性がある。
Contact  連絡先
Cybersecurity Report Inquiries and Feedback: [mail]
サイバーセキュリティ報告書に関する問い合わせおよびフィードバック:[mail]
Defense Industrial Base Inquiries and Cybersecurity Services: [mail] 防衛産業基盤に関する問い合わせおよびサイバーセキュリティサービス: [mail]
Media Inquiries / Press Desk: 443-634-0721, [mail] メディアからの問い合わせ/プレスデスク:443-634-0721、[mail]
[1] Internet Engineering Task Force Requests for Comments.  [1] インターネット技術タスクフォースの意見要求。
[2] Memorandum on Improving the Cybersecurity of National Security, Department of Defense, and Intelligence Community Systems, 19 January 2022.  [2] 2022年1月19日付、国防総省、インテリジェンス・コミュニティ・システムのサイバーセキュリティ改善に関する覚書。
[3] National Security Memorandum on Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems, 4 May 2022.  [3] 2022年5月4日付、脆弱な暗号システムへのリスクを緩和しつつ、量子コンピューティングにおける米国のリーダーシップを推進する国家安全保障に関する覚書。
[4] Chairman of the Joint Chiefs of Staff Notice 6510, Information Assurance Cryptographic Device Modernization Requirements, August 2019.  [4] 統合参謀本部議長通知 6510、情報保証暗号化装置の近代化要件、2019年8月。
[5] Committee on National Security Systems Advisory Memorandum 01-07-NSM, Cryptographic Equipment Modernization Planning, 20 March 2022.  [5] 国家安全保障システム委員会諮問覚書 01-07-NSM、暗号化装置の近代化計画、2022年3月20日。
[6] Committee on National Security Systems Policy 15, Use of Public Standards for Secure Information Sharing.  [6] 国家セキュリティシステム委員会方針15、安全な情報共有のための公開標準の使用。
[7] NIST Special Publication 800-208, Recommendation for Stateful Hash-Based Signature Schemes.  [7] NIST特別刊行物800-208、ステートフルハッシュベース署名スキームの推奨。
[8] Committee on National Security Systems Instruction 1253, Security Categorization and Control Selection for National Security Systems.  [8] 国家セキュリティシステム委員会指示1253、国家セキュリティシステムのセキュリティ分類および管理選択。
[9] NIST Special Publication 800-39, Managing Information Security Risk: Organization, Mission, and Information System View. 10 NIST Special Publication 800-53 Rev.5, Security and Privacy Controls for Information Systems and Organizations.  [9] NIST特別刊行物800-39『情報セキュリティリスクのマネジメント:組織、ミッション、および情報システムビュー』。 10 NIST特別刊行物800-53 Rev.5『情報システムおよび組織のためのセキュリティおよびプライバシー管理』。 
[10] NIST Special Publication 800-59, Guideline for Identifying an Information System as a National Security System.  [10] NIST特別刊行物800-59『情報システムを国家セキュリティシステムとして識別するためのガイドライン』。

 

 

|

« 中国 2023年8月から2024年12月末までに届出があった生成的AIサービスは302件、API利用したサービス105件 | Main | 欧州連合 欧州経済・社会委員会 (EESC) プロワーカーAI:雇用・労働市場政策に関連するAIの可能性を活用し、リスクを緩和するための手段 (2024.01.09) »

Comments

Post a comment



(Not displayed with comment.)


Comments are moderated, and will not appear on this weblog until the author has approved them.



« 中国 2023年8月から2024年12月末までに届出があった生成的AIサービスは302件、API利用したサービス105件 | Main | 欧州連合 欧州経済・社会委員会 (EESC) プロワーカーAI:雇用・労働市場政策に関連するAIの可能性を活用し、リスクを緩和するための手段 (2024.01.09) »