CNSA 2.0の特にソフト/ファームウェア署名に関するメモ
この図
PQC移行スケジュール（IPAの資料から抜粋）
を見たことがある人は多いかと思う。ソフト/ファームウェア署名においては2025年までにPQC移行を開始し、2030年までに完了しろという恐ろしい内容である。
NISTは2024年にML-DSA/SLH-DSAを標準化しており、私としてはこれらに期待していたのだが一部理解できてないところがあったのでメモしておく。
結論から言うとML-DSA/SLH-DSAはソフト/ファームウェア署名に使われないかも？である。少なくともSLH-DSAはCNSA承認されていないし、ML-DSAはハイブリッドにするかしないという議論がまだある。
Commercial National Security Algorithm Suite 2.0
CNSAは要は政府調達要件に足る暗号アルゴリズムを定めた文書であると思ってる。すべての企業がCNSAに準拠しなければならないわけではないが、大手のデバイスメーカーや金融など含む重要領域はこの文書に従うと思われる。
承認アルゴリズムスイートは
- AES-256
- SHA-384/512
- CRYSTALS-Kyber (ML-KEM-1024)
- CRYSTALS-Dilithium（ML-DSA-87）
- LMS（すべてのパラメータ。SHA-256/192推奨）
- XMSS（すべてのパラメータ）
ここでLMSとXMSSはソフト/ファームウェア署名のみに許されたアルゴリズムで、特にLMSを推奨している。
- NIST has standardized these algorithms already, while other post-quantum
signatures are not yet standardized,- This signature use-case is more urgent, and
- This selection places algorithms with the most substantial history of cryptanalysis
in a use case where their potential performance issues have minimal impact. In
particular, this usage coincides well with the requirement for keeping track of
state—that is, how many times a given public key was used in signing software
or firmware when deploying these signatures.
要はCNSA 2.0が発行された2022年時点ではまだNIST PQC標準化が進んでなかったので、緊急性の高いソフト/ファーム署名についてはすでに標準化されているLMS/XMSSがよくマッチするから使っとけ。ということである。
CNSA 2.0 FAQ
CNSAに対するFAQ
に重要なことがいくつか書いてある。
ハイパーツリー構造は利用できない
Q: Can I use HSS or XMSSMT from NIST SP 800-208?
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.
SLH-DSAは利用できない
Q: Can I use SLH-DSA (aka SPHINCS+) to sign software?
A: While SLH-DSA is hash-based, it is not part of CNSA and is not approved for any use in NSS.
ML-DSAはソフト/ファーム署名に利用可能
Q: Can I use ML-DSA for firmware or software signing?
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.
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.
HashML-DSA（別名、ML-DSAのプレハッシュモード）は許可されていない
Q: Is HashML-DSA, aka the pre-hash mode of ML-DSA, allowed in 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.
今後アルゴリズムが追加される予定はない
Q: Will NSA add more selections to CNSA in the future?
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).
承認されてないSHA-3等は、ハッシュ単体でなくML-DSAやLMSの内部では利用可能
Q: What if my solution uses hash functions other than SHA-384 or 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.
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.
ハイブリッドモードは要求しない
Q: What is NSA’s position on the use of hybrid solutions?
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.
他国の見解
PQC移行は米国主導で進んでいるが、米国以外の国の方針も各種の文書で表明されている。、FrodoやMcElieceなどのより保守的な手法を推奨しているところも多いが、基本的にはFIPSに従うということだと思う。
重要な点は、オランダ・ドイツ・フランスがハイブリッドモードを要求している点であり、この点は米国と異なるスタンスである。
しかし例えばANSSI文書では
all post-quantum PKC algorithms shall continue to be systematically included inside hybrid mechanisms (except for hash-based signatures whose hybridation is optional
とされており、ハッシュベース署名に関してはハイブリッドモードがoptionとされている。この点まで考慮するとソフト/ファーム署名にはML-DSA（+ECDSA）ではなくLMSが使われていく未来があるのかなあという気がする。
性能的にもLMSが良いだろうし、セキュアブートに利用する場合は検証コード自体がROMに入るかが問題になるだろう。その点ハイブリッドは不利な気がする。
Discussion