SLH-DSA
FIPS 205 ステートレスハッシュベースデジタル署名標準 Stateless Hash-Based Digital Signature Standard
https://csrc.nist.gov/pubs/fips/205/final
doi:10.6028/NIST.FIPS.205
RFC 9814 Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
FIPS 205
連邦情報処理標準規格
ステートレスハッシュベースデジタル署名標準
カテゴリ: コンピュータセキュリティ サブカテゴリ: 暗号化
情報技術研究所
米国国立標準技術研究所
メリーランド州ゲイサーズバーグ 20899-8900
この出版物は以下から無料で入手できます:
https://doi.org/10.6028/NIST.FIPS.205
公開日: 2024年8月13日
概要
この規格は、ステートレスハッシュベースデジタル署名アルゴリズム(SLH-DSA)を規定する。デジタル署名は、データへの不正な変更を検出し、署名者の身元を認証するために使用される。さらに、署名されたデータの受信者は、デジタル署名を証拠として、署名が実際に署名者によって生成されたことを第三者に示すことができる。
署名者が後日容易に署名を否認できないため、これは否認不可性と呼ばれる。SLH-DSAは、NIST耐量子暗号標準化プロセスの一環として標準化対象として選定されたSPHINCS+に基づいている。
キーワード:コンピュータセキュリティ、暗号化、デジタル署名、連邦情報処理標準、ハッシュベース署名、耐量子、公開鍵暗号。
連邦情報処理標準規格(FIPS)205
発行日: 2024年8月13日
発効日: 2024年8月13日
ステートレスハッシュベースデジタル署名標準の発表
連邦情報処理標準(FIPS)出版物は、米国国立標準技術研究所(NIST)が15 U.S.C. 278g-3に基づき策定し、商務長官が40 U.S.C. 11331に基づき発行する。
1. 標準名称. ステートレスハッシュベースデジタル署名標準(FIPS 205)。
2. 標準カテゴリ. コンピュータセキュリティ。サブカテゴリ. 暗号化。
3. 説明. 本標準は、手書き署名ではなくデジタル署名を必要とするアプリケーション向けに、ステートレスハッシュベースデジタル署名方式(SLH-DSA)を規定する。追加のデジタル署名方式は、他のNIST特別出版物およびFIPS出版物(例:FIPS 186-5 1)で規定および承認されている。デジタル署名は、コンピュータ内でビット列として表現され、署名者の身元とデータの整合性を検証するための一連の規則とパラメータを用いて計算される。デジタル署名は、保存データと送信データの両方に対して生成できます。
署名生成では、秘密鍵を用いてデジタル署名を生成します。署名検証では、秘密鍵に対応する公開鍵を使用しますが、秘密鍵と同一ではありません。各署名者は、秘密鍵と公開鍵のペアを保有します。公開鍵は公開できますが、秘密鍵は秘密に保持する必要があります。署名者の公開鍵を用いることで、誰でも署名を検証できます。署名生成を実行できるのは、秘密鍵を保有するユーザーのみです。
デジタル署名は、署名されたデータと共に、意図された検証者に提供されます。検証者は、署名者の公開鍵を用いて署名を検証します。同様の手順を用いて、保存データと送信データの両方に対して署名を生成および検証することができます。
本規格は、SLH-DSAの使用が承認されている複数のパラメータセットを規定しています。追加のパラメータセットは、将来のNIST特別刊行物において規定および承認される可能性があります。
4. 承認機関. 商務長官
5. 保守機関. 商務省、国立標準技術研究所、情報技術研究所(ITL)。
6. 適用範囲. 本規格は、米国法典第10編第2315条または米国法典第44編第3502条(2)の適用を受けない、機微な非機密情報の保護に関して、すべての連邦政府省庁および機関に適用される。連邦政府省庁および機関が運用する、または契約に基づいて運用される公開鍵署名システムの設計および実装には、本規格、FIPS 204、FIPS 186-5、またはNIST特別出版物800-208のいずれかを使用するものとする。将来的には、FIPS出版物またはNIST特別出版物において、追加のデジタル署名方式が規定され、承認される可能性がある。
本規格は、民間組織および商業組織が採用および使用することができる。
7. 用途. デジタル署名アルゴリズムは、署名されたデータの整合性と署名者の身元を認証することを可能にする。署名されたメッセージの受信者は、デジタル署名を証拠として用い、第三者に対し、署名が実際に署名者によって生成されたことを証明することができる。これは、署名者が後から署名を容易に否認できないため、否認防止と呼ばれます。デジタル署名アルゴリズムは、電子メール、電子送金、電子データ交換、ソフトウェア配布、データストレージ、およびデータの完全性保証とデータ出所の認証を必要とするその他のアプリケーションでの使用を目的としています。
8. 実装. デジタル署名アルゴリズムは、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせで実装できます。NISTは、本規格のアルゴリズムへの実装の適合性をテストするための検証プログラムを開発します。本規格で規定されているすべての計算手順について、適合する実装では、指定された一連の手順を数学的に同等の任意のプロセスに置き換えることができます。言い換えれば、すべての入力に対して正しい出力を生成する異なる手順が許容されます。検証プログラムに関する情報は、https://csrc.nist.gov/projects/cmvp で入手できます。デジタル署名アルゴリズムの例は、https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines/example-values で入手できます。
機関は、デジタル署名鍵ペアを他の目的に使用しないよう勧告されます。
9. その他の承認済みセキュリティ機能. 本規格に準拠するデジタル署名の実装には、連邦政府の機密情報の保護のために承認された暗号アルゴリズムを採用するものとする。承認済みの暗号アルゴリズムおよび技術には、次のいずれかに該当するものが含まれる。
a. 連邦情報処理標準(FIPS)出版物で規定されているもの、
b. FIPSまたはNIST勧告で採用されているもの、または
c. SP 800-140Cの承認済みセキュリティ機能リストで規定されているもの。
10. 輸出管理. 特定の暗号装置およびそれらに関する技術データは、連邦輸出規制の対象となります。本規格を実装した暗号モジュールおよびそれらに関する技術データの輸出は、これらの連邦規制に準拠し、米国商務省産業安全保障局の許可を得る必要があります。輸出規制に関する情報は、https://www.bis.doc.gov で入手できます。
11. 特許. 本規格のアルゴリズムは、米国特許または外国特許によって保護されている場合があります。
12. 実装スケジュール. 本規格は、最終発行後直ちに発効します。
13. 仕様. 連邦情報処理標準(FIPS)205、ステートレスハッシュベースデジタル署名標準(添付)。
14. 資格. デジタル署名システムのセキュリティは、署名者の秘密鍵の機密性に依存します。したがって、署名者は秘密鍵の漏洩を防ぐ必要があります。本規格は、デジタル署名生成に関する一般的なセキュリティ要件を規定することを意図していますが、本規格への適合は特定の実装のセキュリティを保証するものではありません。デジタル署名機能を実装するモジュールが安全な方法で設計および構築されていることを保証するのは、実装者の責任です。
同様に、本規格に準拠した実装を含む製品の使用は、その製品が使用されるシステム全体のセキュリティを保証するものではありません。各機関または省庁の責任当局は、全体的な実装が許容可能なレベルのセキュリティを提供することを保証する必要があります。
この種の規格は、科学技術の進歩と革新に適応できる柔軟性を備えていなければならないため、本規格は5年ごとにその適切性を評価するために見直されます。
15. 免除手続き. 連邦情報セキュリティマネジメント法(FISMA)は、商務長官によって義務付けられた連邦情報処理標準(FIPS)の適用免除を認めていません。
16. 標準のコピーの入手先. この出版物は、https://csrc.nist.gov/publications にアクセスすることで入手できます。その他のコンピュータセキュリティに関する出版物も、同じウェブサイトから入手できます。
17. この出版物の引用方法. NISTは、NIST技術シリーズ出版物識別子構文に基づき、このFIPSの出版物識別子としてNIST FIPS 205を割り当てています。NISTは、以下の引用方法を推奨しています。
米国国立標準技術研究所(NIST)(2024)ステートレスハッシュベースデジタル署名標準。(商務省、ワシントンD.C.)、連邦情報処理標準出版物(FIPS)NIST FIPS 205。https://doi.org/10.6028/NIST.FIPS.205
18. お問い合わせおよびご意見. この FIPS に関するお問い合わせやご意見は、fips-205-comments@nist.gov までお送りください。
連邦情報処理標準規格205
ステートレスハッシュベースデジタル署名標準の仕様
1. はじめに
1.1 目的と適用範囲
本規格は、バイナリデータ(一般にメッセージと呼ばれる)の保護、およびそれらのデジタル署名の検証と妥当性確認に使用可能なデジタル署名生成方法を定義する。$ ^1
1 NIST Special Publication (SP) 800-175B 2、「連邦政府における暗号標準の使用に関するガイドライン:暗号メカニズム」には、デジタル署名に関する一般的な説明が含まれている。
ステートレスハッシュベースデジタル署名アルゴリズム(SLH-DSA)のセキュリティは、ハッシュ関数の原像を見つけるのが困難であると想定されていること、および同じハッシュ関数の関連するいくつかの特性に基づいている。FIPS 186-5 1 で規定されているアルゴリズムとは異なり、SLH-DSAは大規模量子コンピュータからの攻撃に対する耐性を提供するように設計されている。
本規格は、鍵生成、署名生成、および署名検証に必要な数学的手順を規定する。デジタル署名の有効性には、追加の保証(例えば、同一性や秘密鍵の保有の保証)が必要です。SP 800-89「デジタル署名アプリケーションの保証取得に関する推奨事項」3では、必要な保証とこれらの保証を取得する方法が規定されています。
1.2 背景
過去数年間、量子コンピュータの構築は着実に進歩してきました。
大規模な量子コンピュータが実現した場合、一般的に使用されている多くの公開鍵暗号システムのセキュリティが危険にさらされることになります。これには、整数因数分解と離散対数(有限体上および楕円曲線上)に基づく鍵確立スキームやデジタル署名が含まれます。その結果、2016年にNISTは、標準化に向けて量子耐性を持つ公開鍵暗号アルゴリズムを選定するための公開耐量子暗号(PQC)標準化プロセスを開始しました。合計82の候補アルゴリズムが検討のためにNISTに提出されました。 NISTは3回にわたる評価と分析を経て、標準化に向けて最初の4つのアルゴリズムを選定しました。これらのアルゴリズムは、暗号学的に関連する量子コンピュータの登場後も含め、予見可能な将来にわたって米国政府の機密情報を保護することを目的としています。本標準には、選定されたアルゴリズムの1つである、ステートレスハッシュベースデジタル署名方式であるSPHINCS+の仕様が含まれています。この標準には、NIST PQC標準化プロセスの第3ラウンドの開始時に提出されたバージョン3 4 と比較して、いくつかの小さな変更が含まれています。変更内容は付録Aに記載されています。本標準では、SPHINCS+はステートレスハッシュベースデジタル署名アルゴリズム(SLH-DSA)と呼ばれます。
3. SLH-DSA署名方式の概要
SLH-DSAは、他のハッシュベース署名方式を構成要素として用いて構築されるステートレスなハッシュベース署名方式である。構成要素としては、(1) 少数時間署名方式であるForest of Random Subsets (FORS)、(2) 多重時間署名方式であるeXtended Merkle Signature Scheme (XMSS)がある。XMSSは、ハッシュベースワンタイム署名方式である Winternitz One-Time Signature Plus ($ WOTS^+)を構成要素として用いて構築されている。$ ^2
2 SLH-DSAの構成要素として使用されるWOTS+およびXMSS方式は、RFC 8391 11およびSP 800-208 12のWOTS+およびXMSS方式とは異なる。
概念的には、SLH-DSA 鍵ペアは非常に大きな FORS 鍵ペアの集合から構成されます。$ ^3少数回署名方式である FORS により、各鍵ペアは少数のメッセージに安全に署名できます。SLH-DSA 署名は、メッセージのランダムハッシュを計算し、得られたメッセージダイジェストの一部を使用して擬似ランダムに FORS 鍵を選択し、その鍵でメッセージダイジェストの残りの部分に署名することによって作成されます。SLH-DSA 署名は、FORS 署名と FORS 公開鍵を認証する情報から構成されます。認証情報は XMSS 署名を使用して作成されます。
3 この標準のパラメータセットでは、SLH-DSA 鍵ペアには $ 2^{63}, 2^{64}, 2^{66}, or 2^{68} 個の FORS 鍵が含まれており、これらの鍵は単一のシードから擬似ランダムに生成されます。
XMSS は、WOTS+ ワンタイム署名と Merkle ハッシュ木 13 を組み合わせて作成されるマルチタイム署名方式です。 XMSS鍵は2ℎ′個のWOTS+鍵で構成され、2ℎ′個のメッセージに署名できます。WOTS+公開鍵はMerkleハッシュツリーに形成され、ツリーのルートはXMSS公開鍵です。(WOTS+鍵から形成されたMerkleハッシュツリーは、XMSSツリーとも呼ばれます。)XMSS署名は、WOTS+署名と、WOTS+公開鍵のMerkleハッシュツリー内の認証パスで構成されます。図1では、三角形はXMSSツリー、四角形はWOTS+公開鍵、円はハッシュツリーの内部ノードを表しています。XMSSツリー内で、塗りつぶされた四角形と円は、署名の検証に必要なWOTS+公開鍵の認証パスを表しています。
FORS 公開鍵の認証情報はハイパーツリー署名です。ハイパーツリーは、図 1 に示すように、XMSS ツリーのツリーです。このツリーは 𝑑 層$ ^4 で構成され、最上位層 (層 𝑑 − 1) は単一の XMSS ツリー、次の層 (層 𝑑 − 2) は 2ℎ′ 個の XMSS ツリー、最下位層 (層 0) は 2(𝑑−1)ℎ′ 個の XMSS ツリーで構成されます。層 0 から 𝑑 − 2 までの各 XMSS 鍵の公開鍵は、次の上位層の XMSS 鍵によって署名されます。層 0 の XMSS 鍵には、合計で 2𝑑ℎ′ = 2ℎ 個の WOTS+ 鍵があり、これらは SLH-DSA 鍵ペアの 2ℎ FORS 公開鍵に署名するために使用されます。 FORS公開鍵を認証するために必要なXMSS署名のシーケンスは、レイヤー𝑑 − 1のXMSS鍵の公開鍵から開始し、ハイパーツリー署名となる。SLH-DSA署名は、FORS署名とハイパーツリー署名から構成される。
4 この標準のパラメータセットでは、dは7、8、17、または22です。
SLH-DSA公開鍵(図16)には、2つの𝑛バイトのコンポーネントが含まれています。(1) PK.rootはレイヤー𝑑 − 1のXMSS鍵の公開鍵であり、(2) PK.seedは異なるSLH-DSA鍵ペア間のドメイン分離を提供するために使用されます。 SLH-DSA秘密鍵(図15)は、WOTS+鍵とFORS鍵のすべての秘密値を擬似乱数生成するために使用されるnバイトのシードSK.seedと、メッセージのランダム化ハッシュの生成に使用されるnバイトの鍵SK.prfで構成されています。SLH-DSA秘密鍵には、PK.rootとPK.seedのコピーも含まれます。これらの値は、署名生成と署名検証の両方で必要となるためです。
WOTS+ワンタイム署名方式はセクション5で規定され、XMSSマルチタイム署名方式はセクション6で規定されています。セクション7では、ハイパーツリー署名の生成と検証について規定しています。FORS少数時間署名方式はセクション8で規定されています。最後に、セクション9では、SLH-DSA鍵生成、署名、および検証関数について規定しています。この標準で説明されているWOTS+、XMSS、ハイパーツリー、およびFORS方式は、スタンドアロン署名方式として使用することを目的としていないため、SLH-DSAを実装するために必要な方式のコンポーネントについてのみ説明しています。特に、これらのセクションには鍵ペア生成の機能は含まれておらず、署名検証機能はハイパーツリー署名に対してのみ規定されています。
この標準で使用される場合、WOTS+、XMSS、およびFORS署名は、メッセージと署名から公開鍵を生成する関数を使用して暗黙的に検証されます(セクション5.3、6.3、および8.4を参照)。 SLH-DSA 署名を検証する場合、メッセージのランダム化ハッシュと FORS 署名を使用して候補 FORS 公開鍵が計算されます。候補 FORS 公開鍵とレイヤー 0 XMSS 鍵からの WOTS+ 署名を使用して候補 WOTS+ 公開鍵が計算され、対応する認証パスと組み合わせて候補 XMSS 公開鍵が計算されます。候補レイヤー 0 XMSS 公開鍵は、レイヤー 1 XMSS 署名と一緒に使用され、候補レイヤー 1 XMSS 公開鍵が計算されます。このプロセスは、候補レイヤー 𝑑 − 1 公開鍵が計算されるまで繰り返されます。計算された候補レイヤー 𝑑 − 1 XMSS 公開鍵が SLH-DSA 公開鍵ルート PK.root と同じ場合、SLH-DSA 署名の検証は成功します。
3.1 追加要件
本節では、SLH-DSAを実装する暗号モジュールの要件を規定する。3.2節では、暗号モジュールの実装者が考慮すべき事項について、要件ではないが、その問題点について説明する。SP 800-89「デジタル署名アプリケーションの保証取得に関する勧告」3は、デジタル署名スキームの使用に適用される要件を規定している。
ランダム性生成. SLH-DSA鍵生成(アルゴリズム21)では、3つのランダムな𝑛バイト値(PK.seed、SK.seed、SK.prf)を生成する必要がある。𝑛は、パラメータセットに応じて16、24、または32である。鍵生成の各呼び出しにおいて、これらの値はそれぞれ、SP 800-90A、SP 800-90B、および SP 800-90C 14 , 15 , 16 に規定されている承認された乱数ビット生成器 (RBG) を使用して生成された新しい (つまり、以前に使用されていない) 乱数でなければなりません。さらに、使用される RBG は、少なくとも 8𝑛 ビットのセキュリティ強度を持つ必要があります。各パラメータセットの𝑛 の値については、表 2 を参照してください。
機密データの破壊. 鍵生成および署名アルゴリズムによって中間計算ステップで内部的に使用されるデータは、攻撃者が秘密鍵に関する情報を取得し、セキュリティを侵害するために使用される可能性があります。検証アルゴリズムによって内部的に使用されるデータは、ベアラトークンとして使用される署名 (つまり、認証シークレット) や機密扱いを意図した平文メッセージの署名の検証など、一部のアプリケーションでは同様に機密性が高いものです。検証アルゴリズムの中間値は、入力(メッセージ、署名、公開鍵)に関する情報を明らかにする可能性があり、一部のアプリケーションでは、セキュリティまたはプライバシーの観点から、これらの入力の1つ以上を機密にする必要があります。したがって、SLH-DSAの実装では、入力のローカルコピーおよび機密性の高い可能性のある中間データが不要になったらすぐに破棄されるようにする必要があります。
鍵チェック. SP 800-89は、公開鍵の有効性と秘密鍵の所有の保証に関する要件を定めています。公開鍵の検証が必要なSLH-DSAの場合、実装は公開鍵の長さが2𝑛バイトであることを検証する必要があります。秘密鍵の所有の保証が再生成によって得られた場合、秘密鍵の所有者は秘密鍵の長さが4𝑛バイトであることを確認し、SK.seedとPK.seedを使用してPK.rootを再計算し、新しく生成された値と現在保持されている秘密鍵の値を比較する必要があります。
浮動小数点演算. SLH-DSAの実装では、浮動小数点演算を使用しません。浮動小数点演算における丸め誤差により、場合によっては誤った結果が生じる可能性があるためです。この標準規格における、除算(例:𝑥/𝑦)が実行され、𝑦が𝑥を割り切れないすべての擬似コードでは、⌊𝑥/𝑦⌋または⌈𝑥/𝑦⌉のいずれかが使用されます。通常の整数除算𝑥/𝑦は⌊𝑥/𝑦⌋を計算し、非負整数𝑥と正整数𝑦に対して⌈𝑥/𝑦⌉ = ⌊(𝑥 + 𝑦 − 1)/𝑦⌋となるため、これらはどちらも浮動小数点演算を使用せずに計算できます。$ 𝑙𝑒𝑛_2 の値(式5.3参照)は浮動小数点演算(アルゴリズム1参照)を使用せずに計算できますが、この値は事前に計算しておくことが推奨されます。この標準規格のすべてのパラメータセットにおいて、$ 𝑙𝑒𝑛_2は3です。
アルゴリズム1 gen_len$ _2 (n, lg_u)