[要約] RFC 10033は、耐量子計算機暗号であるステートフルハッシュベース署名（LMSやXMSSなど）を運用する際の状態管理とバックアップに関するガイダンスを提供する情報文書です。ステートフル署名では鍵の再利用による偽造を防ぐために厳格な状態追跡が必須であり、冗長鍵の同期やフェイルオーバー時の安全な対処法を提示します。システム障害や復元時に二重署名のリスクを排除し、安全にステートフル署名を導入・運用するためのセキュリティ考慮事項をまとめています。
Internet Engineering Task Force (IETF) T. Wiggers
Request for Comments: 10033 PQShield
Category: Informational K. Bashiri
ISSN: 2070-1721 BSI
S. Kölbl
Google
J. Goodman
Crypto4A Technologies
S. Kousidis
BSI
September 2026
Stateful Hash-Based Signature Schemes (Stateful HBS) such as Leighton-Micali Signature (LMS), Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT combine Merkle trees with One-Time Signatures (OTSs) to provide signatures that are resistant against attacks using large-scale quantum computers. Unlike conventional stateless digital signature schemes, Stateful HBS have a state to keep track of which OTS keys have been used, as double-signing with the same OTS key allows forgeries.
Leighton-Micali 署名 (LMS)、階層署名システム (HSS)、拡張マークル署名スキーム (XMSS)、XMSS^MT などのステートフル ハッシュベース署名スキーム (ステートフル HBS) は、マークル ツリーとワンタイム署名 (OTS) を組み合わせて、大規模な量子コンピューターを使用した攻撃に耐性のある署名を提供します。従来のステートレス デジタル署名スキームとは異なり、同じ OTS キーによる二重署名により偽造が可能になるため、ステートフル HBS にはどの OTS キーが使用されたかを追跡する状態があります。
This document provides guidance and catalogs security considerations for the operational and technical aspects of deploying systems that rely on Stateful HBS. Management of the state of the Stateful HBS, including any handling of redundant key material, is a sensitive topic. This document describes some approaches to handle the associated challenges. It also describes the challenges that need to be resolved before certain approaches should be considered.
このドキュメントでは、ステートフル HBS に依存するシステムの展開の運用面および技術面に関するセキュリティに関する考慮事項のガイダンスとカタログを提供します。ステートフル HBS の状態の管理 (冗長キー マテリアルの処理を含む) は、機密性の高いトピックです。このドキュメントでは、関連する課題に対処するためのいくつかのアプローチについて説明します。また、特定のアプローチを検討する前に解決する必要がある課題についても説明します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。IESG によって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではありません。RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10033.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10033 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. When are Stateful HBS Appropriate?
2. Specific Terminology in the Context of Stateful HBS
2.1. Private Key Components
2.2. State Management
2.3. Backup Management
2.4. Key Export, Key Import, and Key Transfer
3. Operational Considerations
3.1. Assessing Operational Costs
3.2. Ensuring Long-Lived Resilient Solutions
3.3. Training and Skills
3.4. Configurable Warning Thresholds
3.5. Selection of Appropriate Parameter Set
3.6. External Dependencies
4. Requirements for Secure State Management
5. Potential State Management Approaches
5.1. Multiple Public Keys (SP 800-208)
5.2. Distributed Multi-trees (SP 800-208)
5.3. Sectorization
5.4. Key/State Transfer
5.5. Key Rotation
5.6. Variable-Length Signature Chains
5.7. Pre-Assigning States
5.8. Time-Based State Management
5.9. Interval-Based Approaches
6. Backup Management Beyond NIST SP 800-208
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
Stateful Hash-Based Signature Schemes (Stateful HBS) such as Leighton-Micali Signature (LMS), Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT combine Merkle trees with One-Time Signatures (OTSs) in order to provide digital signature schemes that remain secure even when large-scale quantum computers become available. The theoretic security of Stateful HBS is well understood and depends only on the security of the underlying hash function. As such, Stateful HBS can serve as an important building block for quantum-resistant information and communication technology. Stateful HBS are specified in [RFC8391], [RFC8554], and NIST [SP.800-208], and we recommend Sections 1 and 3 of [SP.800-208] as background for this document.
Leighton-Micali 署名 (LMS)、階層署名システム (HSS)、拡張マークル署名スキーム (XMSS)、XMSS^MT などのステートフル ハッシュベース署名スキーム (ステートフル HBS) は、マークル ツリーとワンタイム署名 (OTS) を組み合わせて、大規模な量子コンピューターが利用可能になった場合でも安全なデジタル署名スキームを提供します。ステートフル HBS の理論上のセキュリティはよく理解されており、基礎となるハッシュ関数のセキュリティにのみ依存します。そのため、ステートフル HBS は、耐量子性情報および通信テクノロジの重要な構成要素として機能します。ステートフル HBS は [RFC8391]、[RFC8554]、および NIST [SP.800-208] で規定されており、この文書の背景として [SP.800-208] のセクション 1 および 3 を推奨します。
The private key of a Stateful HBS is a finite collection of OTS keys (typically generated on-demand from a seed) and an associated data structure that keeps track of which OTS keys have been used. This data structure is typically a simple counter and often called an index; this document refers to it as the *state* of the private key. Each Stateful HBS private key can be used to sign a finite number of messages and the state must be updated with each generated signature.
ステートフル HBS の秘密キーは、OTS キーの有限のコレクション (通常はシードからオンデマンドで生成されます) と、どの OTS キーが使用されたかを追跡する関連データ構造です。このデータ構造は通常、単純なカウンターであり、インデックスと呼ばれることもよくあります。このドキュメントでは、これを秘密キーの *状態* と呼びます。各ステートフル HBS 秘密キーは有限数のメッセージに署名するために使用でき、生成された署名ごとに状態を更新する必要があります。
One must not reuse any OTS key that is part of a Stateful HBS private key. If an attacker is able to obtain signatures for two different messages created using the same OTS key, it is computationally feasible for that attacker to create forgeries [BH16] [Fluhrer23]. As noted in [MCGREW] and [ETSI-TR-103-692], extreme care should be taken in order to avoid the risk that an OTS key will be reused accidentally. Whereas [MCGREW] identifies the fundamental failure modes of Stateful HBS and proposes architectural strategies such as a reservation approach, and [ETSI-TR-103-692] provides a broad analysis of state management challenges and risks, this document complements both by cataloging concrete operational patterns in Section 5 and by addressing backup and recovery considerations in Section 6 that are not covered in prior work.
ステートフル HBS 秘密キーの一部である OTS キーを再利用してはなりません。攻撃者が同じ OTS 鍵を使用して作成された 2 つの異なるメッセージの署名を取得できた場合、その攻撃者は偽造メッセージを作成することが計算上可能です [BH16] [Fluhrer23]。[MCGREW] および [ETSI-TR-103-692] に記載されているように、OTS キーが誤って再利用されるリスクを避けるために細心の注意を払う必要があります。[MCGREW] はステートフル HBS の基本的な障害モードを特定し、予約アプローチなどのアーキテクチャ戦略を提案し、[ETSI-TR-103-692] は状態管理の課題とリスクの広範な分析を提供しますが、このドキュメントは、セクション 5 で具体的な運用パターンをカタログ化し、以前の作業ではカバーされていないバックアップとリカバリの考慮事項をセクション 6 で取り上げることで両方を補完します。
In particular, the challenges below highlight why careful state and backup management are essential in Stateful HBS:
特に、以下の課題は、ステートフル HBS では慎重な状態とバックアップの管理が不可欠である理由を強調しています。
* Implementers must ensure that each creation of a signature updates the state correctly.
* 実装者は、署名を作成するたびに状態が正しく更新されることを確認する必要があります。
* If the Stateful HBS private key is distributed to multiple signers at the same time, implementers must ensure that they never use the same OTS key. This may require synchronization between all signers.
* ステートフル HBS 秘密キーが複数の署名者に同時に配布される場合、実装者は同じ OTS キーを決して使用しないようにする必要があります。これには、すべての署名者間の同期が必要になる場合があります。
* Additional operational complexity arises when part of the available OTSs are allocated to different devices (partial state transfer), or when state from different devices needs merging; these introduce risks of overlap, failure, and require careful coordination.
* 利用可能な OTS の一部が異なるデバイスに割り当てられる場合 (部分的な状態転送)、または異なるデバイスからの状態をマージする必要がある場合、操作はさらに複雑になります。これらは重複や障害のリスクをもたらし、慎重な調整が必要です。
* If key backups are required, implementers must ensure that any backup mechanism cannot lead to re-using a previously used OTS key.
* キーのバックアップが必要な場合、実装者は、バックアップ メカニズムによって以前に使用された OTS キーが再利用されないようにする必要があります。
The following sections present, recall, and discuss various strategies for a correct state and backup management for Stateful HBS.
次のセクションでは、ステートフル HBS の正しい状態とバックアップ管理のためのさまざまな戦略を示し、思い出し、説明します。
The issues with state management described above, as well as (for most parameter sets) the limited number of signatures, lead to new requirements that most developers will not be familiar with and that require careful handling in practice; Stateful HBS are not general-purpose signature schemes. Most applications, especially those that may produce unrestricted numbers of signatures, should use _stateless_ hash-based signature schemes like SLH-DSA [FIPS205], which use the same security assumptions, or schemes based on other assumptions, such as ML-DSA [FIPS204]. However, if run time, implementation size, or signature or key sizes of stateless alternatives are prohibitive, and the specific use case allows a very tight control of the signing environment, using Stateful HBS may be an appropriate solution. It seems likely that in many scenarios, it is only possible to meet the requirements set out in Section 4 when using purpose-designed hardware such as hardware-security modules.
上で説明した状態管理の問題と、(ほとんどのパラメーター セットの場合) 署名の数が限られているため、ほとんどの開発者には馴染みがなく、実際には慎重な取り扱いが必要となる新しい要件が生じます。ステートフル HBS は汎用の署名スキームではありません。ほとんどのアプリケーション、特に無制限の数の署名を生成する可能性のあるアプリケーションは、同じセキュリティ前提を使用する SLH-DSA [FIPS205] のようなステートレス ハッシュ ベースの署名スキーム、または ML-DSA [FIPS204] などの他の前提に基づくスキームを使用する必要があります。ただし、ステートレスな代替手段の実行時間、実装サイズ、または署名やキーのサイズが法外で、特定のユースケースで署名環境を非常に厳密に制御できる場合は、ステートフル HBS の使用が適切なソリューションとなる可能性があります。多くのシナリオでは、ハードウェア セキュリティ モジュールなどの専用設計のハードウェアを使用する場合にのみ、セクション 4 に記載されている要件を満たすことが可能であると思われます。
Stateful HBS are already profiled or discussed in several deployment-focused specifications and guidance documents. For example, [RFC9802] discusses suitable use cases for stateful HBS in X.509 (including firmware/software signing and CA certificates). [CRYPTO-IoT] defines an asymmetric profile that uses HSS-LMS, providing an interoperability target for software/firmware update IoT ecosystems. Additionally, the NSA [CNSA2.0] allows LMS (and XMSS) in specific application scenarios such as firmware/software signing.
ステートフル HBS は、展開に焦点を当てたいくつかの仕様およびガイダンス文書ですでにプロファイルまたは説明されています。たとえば、[RFC9802] では、X.509 でのステートフル HBS (ファームウェア/ソフトウェア署名および CA 証明書を含む) の適切な使用例について説明しています。[CRYPTO-IoT] は、HSS-LMS を使用する非対称プロファイルを定義し、ソフトウェア/ファームウェア更新 IoT エコシステムの相互運用性ターゲットを提供します。さらに、NSA [CNSA2.0] は、ファームウェア/ソフトウェア署名などの特定のアプリケーション シナリオで LMS (および XMSS) を許可します。
This section defines key notions that are important in the context of Stateful HBS.
このセクションでは、ステートフル HBS のコンテキストで重要な主要な概念を定義します。
This section describes the two conceptual components that make up the private key material used in Stateful HBS.
このセクションでは、ステートフル HBS で使用される秘密キー マテリアルを構成する 2 つの概念的なコンポーネントについて説明します。
*private key:* The static, long-lived secret(s) from which the underlying OTS private keys are derived. This material is stateless; given the scheme parameters, it deterministically defines the set of OTS private keys but does not change over time.
*秘密キー:* 基礎となる OTS 秘密キーの派生元となる、静的で長期間有効な秘密。このマテリアルはステートレスです。スキーム パラメータが与えられると、OTS 秘密キーのセットが決定的に定義されますが、時間の経過とともに変化することはありません。
*state:* The dynamically updated data structure that records which OTS key indices have been consumed (often a monotone counter). This material is mutable and must change on every successful signature.
*state:* どの OTS キー インデックスが消費されたかを記録する、動的に更新されるデータ構造 (多くの場合、単調なカウンター)。このマテリアルは変更可能であり、署名が成功するたびに変更する必要があります。
Conceptually, the private key and the state are distinct and should be handled accordingly: the private key is a static secret, while the state is mutable, evolves with each signature, and must be maintained with integrity and correctness. In some implementations, these two components may be packaged together and not directly separable; in such cases, this document's guidance applies to the combined artifact.
概念的には、秘密鍵と状態は別個のものであり、それに応じて処理する必要があります。秘密鍵は静的な秘密ですが、状態は変更可能であり、署名ごとに進化し、整合性と正確性を維持する必要があります。実装によっては、これら 2 つのコンポーネントが一緒にパッケージ化され、直接分離できない場合があります。このような場合、このドキュメントのガイダンスは結合された成果物に適用されます。
In this document, _state management_ refers to the handling and implementation of the state of the private key.
このドキュメントでは、状態管理とは秘密キーの状態の処理と実装を指します。
This includes mechanisms that aim to:
これには、以下を目的としたメカニズムが含まれます。
* securely update the state before the signature is released,
* 署名が解放される前に状態を安全に更新します。
* set up Stateful HBS where the state is separated in distinct, non-overlapping parts so that signatures can be generated from either part without risk of state reuse,
* ステートフル HBS を設定します。ステートフル HBS では、状態が重複しない個別の部分に分離されるため、状態を再利用するリスクなしにどちらの部分からも署名を生成できます。
* enable partial transfer of unused signature capacity between devices and optionally merging state fragments without overlap,
* デバイス間で未使用の署名容量の部分的な転送を可能にし、オプションで重複することなく状態フラグメントをマージします。
* enable effective but secure handling of private key and state backup material, and
* 秘密鍵と状態のバックアップ素材を効果的かつ安全に処理できるようにし、
* guarantee the availability of both the private key and its state across the lifetime of the key.
* 秘密キーとその状態の両方の可用性を、キーの有効期間全体にわたって保証します。
In particular, the state and private key might be inseparable in implementations of Stateful HBS or in alternative signature mechanisms. For example, puncturable schemes [BSW16] represent such an alternative; they are research-level constructions and are not (at the time of writing) standardized or deployed in practice. However, even in these scenarios, this document's guidance should still apply.
特に、ステートフル HBS の実装や代替の署名メカニズムでは、状態と秘密キーは分離できない場合があります。たとえば、パンクチャラブル スキーム [BSW16] はそのような代替案を表しています。これらは研究レベルの構造であり、(執筆時点では) 標準化されておらず、実際に導入されていません。ただし、このようなシナリオでも、このドキュメントのガイダンスは適用されます。
In order to mitigate failure of, e.g., devices storing key material and to facilitate other types of disaster recovery, backups of private keys and their associated states should be considered as part of a security architecture.
キーマテリアルを保存するデバイスなどの障害を軽減し、他の種類の災害復旧を容易にするために、秘密キーとその関連状態のバックアップをセキュリティ アーキテクチャの一部として考慮する必要があります。
In this document, _backup management_ refers to all mechanisms surrounding the goal to guarantee the availability of the private key and state, but with special care to avoid state reuse by not rolling back to a state in which already-used OTS keys are still available.
このドキュメントでは、「バックアップ管理」とは、秘密キーと状態の可用性を保証するという目標を囲むすべてのメカニズムを指しますが、すでに使用されている OTS キーが依然として使用可能な状態にロールバックしないことで、状態の再利用を避けるために特別な注意が必要です。
These mechanisms include procedures and protocols that aim to:
これらのメカニズムには、次のことを目的とした手順とプロトコルが含まれます。
* securely store this private key and state material outside the in-use signing device,
* この秘密鍵と状態資料を使用中の署名デバイスの外部に安全に保管します。
* import an externally stored private key and state to a newly initiated signing device, and
* 外部に保存された秘密鍵と状態を新しく開始された署名デバイスにインポートし、
* allow practicing with backup recovery and to ensure backups are valid.
* バックアップの復元を練習し、バックアップが有効であることを確認できます。
Backup management can be viewed as a more specific type of state management. The document makes this distinction to clarify the aims of our recommendations.
バックアップ管理は、より具体的なタイプの状態管理とみなすことができます。この文書では、私たちの推奨事項の目的を明確にするためにこの区別を行っています。
As part of state and backup management, this section discusses mechanisms to export, import, or transfer private key and state material. In order to avoid misunderstandings, these notions are specified more precisely.
状態とバックアップの管理の一環として、このセクションでは、秘密キーと状態マテリアルをエクスポート、インポート、または転送するメカニズムについて説明します。誤解を避けるために、これらの概念はより正確に指定されています。
*key export:* A mechanism of exporting secret data, which yields private key and state material, from the signing device to external storage.
*キー エクスポート:* 秘密キーと状態マテリアルを生成する秘密データを署名デバイスから外部ストレージにエクスポートするメカニズム。
*key import:* A mechanism of importing secret data, which loads private key and state material, from external storage to the signing device.
*key import:* 秘密キーと状態マテリアルを外部ストレージから署名デバイスにロードする、秘密データをインポートするメカニズム。
*key transfer:* A cryptographically protected transfer of ownership of private key and state material from one signing device to another.
*キー転送:* 秘密キーと状態マテリアルの所有権を、ある署名デバイスから別の署名デバイスへ暗号的に保護された転送。
Systems and architectures relying on key transfer are generally expected to require fewer operational and manually-executed steps and checks to avoid state reuse, because the transfer mechanism can provide controlled handover of key and state material, instead of relying on separate export, storage, and re-import procedures.
キーの転送に依存するシステムとアーキテクチャでは、一般的に、状態の再利用を避けるために必要な操作手順や手動実行の手順やチェックが少なくなることが予想されます。これは、転送メカニズムによって、個別のエクスポート、保存、再インポート手順に依存する代わりに、キーと状態マテリアルの制御された引き渡しが可能になるためです。
Note that, at times, secure variants of the aforementioned primitives may be required (e.g., securely importing/exporting the key). In these situations, cryptographic mechanisms should be utilized to provide assurances related to the confidentiality (e.g., utilizing symmetric or asymmetric encryption mechanisms) and/or integrity/ authenticity (e.g., utilizing digital signatures, hash functions, and keyed message authentication codes) of the associated operations.
場合によっては、前述のプリミティブの安全なバリアントが必要になる場合があることに注意してください (キーの安全なインポート/エクスポートなど)。このような状況では、暗号化メカニズムを利用して、関連する操作の機密性 (例: 対称または非対称暗号化メカニズムの利用) および/または完全性/信頼性 (例: デジタル署名、ハッシュ関数、およびキー付きメッセージ認証コードの利用) に関連する保証を提供する必要があります。
An important aspect of the evaluation of various HBS state and backup management options is to consider the operational costs associated with the options being evaluated.
さまざまな HBS 状態およびバックアップ管理オプションの評価の重要な側面は、評価対象のオプションに関連する運用コストを考慮することです。
In the past, a conventional trust infrastructure solution could utilize straightforward archival procedures to make copies of the keys, which may then be distributed geographically to ensure their availability and deliver a sufficiently resilient solution, all the while enforcing whatever security protocols and procedures were required. Unfortunately, Stateful HBS introduce an additional constraint in that they need to ensure the state is never reused. Hence, archival procedures used for conventional trust infrastructures have to be amended (including redesigned) to be used as viable options.
これまで、従来の信頼インフラストラクチャ ソリューションでは、簡単なアーカイブ手順を利用してキーのコピーを作成し、それを地理的に分散して可用性を確保し、必要なセキュリティ プロトコルと手順を強制しながら、十分な復元力を備えたソリューションを提供できました。残念ながら、ステートフル HBS では、状態が決して再利用されないようにする必要があるという追加の制約が導入されています。したがって、従来の信頼インフラストラクチャに使用されているアーカイブ手順は、実行可能なオプションとして使用するために修正（再設計を含む）する必要があります。
One of the most problematic aspects of providing a long-lived resilient solution is simply managing the physical media on which the keys/state are stored externally (i.e., outside of the signing device) throughout the course of their lifetime.
長寿命の回復力のあるソリューションを提供する上で最も問題となる側面の 1 つは、キー/状態が外部 (つまり、署名デバイスの外部) に保存される物理メディアを、その存続期間全体を通じて単純に管理することです。
Physical media/devices degrade over time, and the more complex the media/device is, the more likely it is to fail at some point in time (e.g., data stored on a CD vs. data stored on a USB drive vs. data stored in a Hardware Security Module). Combine that with the long lifetimes associated with Stateful HBS keys (e.g., 10-20+ years) and the difficulties associated with transferring keys between devices, and one finds oneself with a perplexing set of challenges that needs to be accounted for in any state selection process of a proper state and backup management solution.
物理メディア/デバイスは時間の経過とともに劣化し、メディア/デバイスが複雑になればなるほど、ある時点で障害が発生する可能性が高くなります (例: CD に保存されたデータ、USB ドライブに保存されたデータ、ハードウェア セキュリティ モジュールに保存されたデータ)。これに、ステートフル HBS キーに関連する長い寿命 (例: 10 ～ 20 年以上) やデバイス間でのキーの転送に伴う困難を組み合わせると、適切な状態とバックアップ管理ソリューションの状態選択プロセスで考慮する必要がある、複雑な一連の課題に直面していることがわかります。
Compounding these complexities is that any resilient state management system should also provide some means to verify the integrity of these long-lived backups to ensure they will be valid when they are required and to ensure the operators know how to execute the necessary recovery procedures.
これらの複雑さをさらに複雑にするのは、回復力のある状態管理システムでは、これらの長期バックアップの整合性を検証して、必要なときにバックアップが有効であることを確認し、必要な回復手順の実行方法をオペレーターが確実に理解できるようにするための何らかの手段も提供する必要があることです。
Many of the prescribed state management options require a high degree of operator involvement, so one should consider the costs associated with training the operator element. This training is needed to ensure processes and procedures are adhered to and failures are caught early and corrected before a catastrophic loss of security can occur (e.g., accidentally instantiating multiple instances of a Stateful HBS key/state).
規定の状態管理オプションの多くは、高度なオペレーターの関与を必要とするため、オペレーター要素のトレーニングに関連するコストを考慮する必要があります。このトレーニングは、プロセスと手順が確実に遵守され、セキュリティの壊滅的な損失が発生する前に障害を早期に発見して修正するために必要です (例: ステートフル HBS キー/状態の複数のインスタンスを誤ってインスタンス化するなど)。
Note that training is not a fixed one-time cost either, as long lifetimes will necessitate succession planning amongst the operator element and training of each successive generation of participants. Mechanisms should be put in place to mitigate the ever-present insider threat; these include M-of-N controls, least-privileges amongst participants, and a separation of duties, which ensure that an attack would require collusion by multiple parties. The separation of duties must persist across successive generations to ensure participants do not acquire multiple roles over time, thereby undermining the intended separation.
生涯が長いと、オペレーター要素間の後継計画と、参加者の連続する各世代のトレーニングが必要になるため、トレーニングも一度きりの固定コストではないことに注意してください。常に存在する内部関係者の脅威を軽減するメカニズムを導入する必要があります。これらには、M-of-N 制御、参加者間の最小限の権限、および攻撃に複数の当事者による共謀が必要となる職務の分離が含まれます。義務の分離は、参加者が時間の経過とともに複数の役割を獲得し、意図した分離が損なわれないように、世代を超えて継続する必要があります。
In addition to the state management, implementers may consider implementing mechanisms to prevent abrupt signature exhaustion.
状態管理に加えて、実装者は、突然の署名の枯渇を防ぐためのメカニズムの実装を検討する場合があります。
Implementations may consider providing a configurable warning threshold, M, which is triggered when M signatures remain. When the number of available signatures reaches this threshold, the system should return a 'signatures nearing exhaustion' warning. This warning condition should require explicit acknowledgment from the user through a mechanism that cannot be trivially skipped.
実装では、M 個の署名が残っているときにトリガーされる、構成可能な警告しきい値 M を提供することを検討できます。利用可能な署名の数がこのしきい値に達すると、システムは「署名が枯渇に近づいています」という警告を返す必要があります。この警告条件は、簡単にはスキップできないメカニズムを通じて、ユーザーからの明示的な承認を必要とする必要があります。
In distributed or partitioned deployments (e.g., sectorized or multi-tree architectures), warning thresholds may apply per device, per sector, or per subtree rather than globally. In such systems, coordination mechanisms may be required if a global exhaustion condition must be detected. In centrally managed deployments, warnings may be directed to system operators or management services rather than end users. The mechanism for acknowledging or acting upon such warnings therefore depends on the operational model and need not involve the end signer directly.
分散または分割された展開 (セクタ化またはマルチツリー アーキテクチャなど) では、警告しきい値がグローバルではなく、デバイスごと、セクタごと、またはサブツリーごとに適用される場合があります。このようなシステムでは、全体的な枯渇状態を検出する必要がある場合、調整メカニズムが必要になる場合があります。集中管理された展開では、警告はエンド ユーザーではなくシステム オペレーターまたは管理サービスに送信される場合があります。したがって、そのような警告を認識したり、警告に基づいて行動したりするためのメカニズムは運用モデルに依存し、エンド署名者が直接関与する必要はありません。
Another important consideration in deploying Stateful HBS is the selection of an appropriate parameter set.
ステートフル HBS を展開する際のもう 1 つの重要な考慮事項は、適切なパラメーター セットの選択です。
Given the flexibility of these schemes -- such as adjustable tree heights or Winternitz parameters -- there exists a large variety of possible configurations. The availability of these different configurations offers many trade-offs between signature generation/ verification time, signature size, and key generation time. Hence, careful attention during the design phase is essential to ensure that the chosen parameter set aligns optimally with the specific requirements of the intended use case.
これらのスキームの柔軟性 (調整可能な木の高さやウィンターニッツ パラメーターなど) を考慮すると、非常に多様な構成が可能です。これらのさまざまな構成を利用できるかどうかにより、署名の生成/検証時間、署名のサイズ、鍵の生成時間の間で多くのトレードオフが生じます。したがって、選択したパラメータ セットが意図した使用例の特定の要件に最適に適合することを保証するには、設計段階で細心の注意を払うことが不可欠です。
Costs associated with any external dependencies required by a particular solution (e.g., access to a public ledger or transparency log, providing accurate time references and synchronization mechanisms, access to attestation facilities, etc.) must be accounted for as well, particularly if a system is operating in an offline mode that makes delivering these additional capabilities all the more complicated and expensive.
特定のソリューションに必要な外部依存関係に関連するコスト (公開台帳や透明性ログへのアクセス、正確な時刻参照と同期メカニズムの提供、認証機能へのアクセスなど) も考慮する必要があります。特に、システムがオフライン モードで動作している場合、これらの追加機能の提供はさらに複雑で高価になります。
A system deploying Stateful HBS should fulfill certain requirements to allow securely handling the state. The system must ensure that no two signing operations can ever be issued from the same state. In addition, the generation of a signature and update of the state should appear to be an _atomic transaction_. This means that the system must not release a signature without irrevocably and correctly updating the state.
ステートフル HBS を導入するシステムは、状態を安全に処理できるようにするために、特定の要件を満たす必要があります。システムは、同じ状態から 2 つの署名操作を発行できないことを保証する必要があります。さらに、署名の生成と状態の更新は、_アトミック トランザクション_であるように見える必要があります。これは、システムが状態を取り消し不能かつ正しく更新することなく署名を解放してはならないことを意味します。
State management systems should satisfy all _ACID_ properties:
状態管理システムは、すべての _ACID_ プロパティを満たす必要があります。
* _Atomicity_: Each operation on the state must be indivisible -- such that it either commits completely or leaves the state unchanged.
* _Atomicity_: 状態に対する各操作は分割不可能である必要があります。つまり、完全にコミットするか、状態を変更しないままにしておく必要があります。
* _Consistency_: The state before and after each update must reflect a valid progression of available OTS indices, and no invalid or conflicting state is ever observable.
* _Consistency_: 各更新の前後の状態は、利用可能な OTS インデックスの有効な進行を反映する必要があり、無効な状態や競合する状態は決して観察できません。
* _Isolation_: Concurrent or overlapping operations (e.g., from separate processes or devices) must not interfere in ways that could lead to state reuse.
* _分離_: 同時または重複する操作 (例: 個別のプロセスまたはデバイスからの) は、状態の再利用につながる可能性のある方法で干渉してはなりません。
* _Durability_: Once a state transition (e.g., before issuing a signature) is committed, that transition must survive crashes, power loss, or device failure.
* _耐久性_: 状態遷移が (署名の発行前などに) コミットされると、その遷移はクラッシュ、電力損失、またはデバイスの障害に耐える必要があります。
These requirements impose significant restrictions on the underlying technical approach and a careful implementation of how the state will be updated or synchronized. The abstraction layers of modern systems can make it particularly difficult to guarantee that no two versions of the same state are present. The main concerns are as follows:
これらの要件は、基礎となる技術的アプローチと状態の更新または同期方法の慎重な実装に重大な制限を課します。最新のシステムの抽象化レイヤーにより、同じ状態の 2 つのバージョンが存在しないことを保証することが特に困難になる場合があります。主な懸念事項は次のとおりです。
* how the actual storage for the state is implemented,
* 状態の実際のストレージがどのように実装されるか、
* how it is modified, and
* どのように変更されるか、そして
* how an accidental/intentional failure/glitch might affect the state security.
* 偶発的/意図的な故障/不具合が国家の安全にどのような影響を与えるか。
A system may have a version of the private key stored in non-volatile memory (e.g., a disk) and will load it into volatile memory (e.g., RAM) while processing. Here, an implementer must ensure that these are always perfectly synchronized [MCGREW], meaning that no other parts of the system are allowed to read any version of the key during procedures that are currently loading, writing, or modifying keys. This can be particularly challenging if there are additional abstraction layers present in the system, like additional caches that may affect reading/writing the state and its potential existence in multiple locations.
システムは、不揮発性メモリ (ディスクなど) に秘密キーのバージョンを保存し、処理中にそれを揮発性メモリ (RAM など) にロードすることがあります。ここで、実装者は、これらが常に完全に同期されていることを保証する必要があります [MCGREW]。これは、現在キーをロード、書き込み、または変更しているプロシージャ中に、システムの他の部分がどのバージョンのキーも読み取ることができないことを意味します。これは、状態の読み取り/書き込みや複数の場所に存在する可能性がある追加のキャッシュなど、システム内に追加の抽象化レイヤーが存在する場合に特に困難になる可能性があります。
Cloning is another concern, as it can easily lead to re-using the same state. This can happen for instance if a process that issues a signing operation is forked and no proper synchronization is enforced in the implementation to guarantee correct state update. Virtual Machine (VM) cloning is another potential security risk here, as both backing up a VM into non-volatile memory or live cloning of a VM can easily lead to a state reuse [MCGREW]. With users shifting workloads to cloud service providers, the issue of VM cloning may become more prevalent.
クローン作成は、同じ状態の再利用に簡単につながる可能性があるため、もう 1 つの懸念事項です。これは、たとえば、署名操作を発行するプロセスがフォークされ、正しい状態の更新を保証する適切な同期が実装で強制されていない場合に発生する可能性があります。ここでは、仮想マシン (VM) のクローン作成も潜在的なセキュリティ リスクの 1 つです。VM を不揮発性メモリにバックアップすることも、VM のライブ クローンを作成することも、簡単に状態の再利用につながる可能性があるためです [MCGREW]。ユーザーがワークロードをクラウド サービス プロバイダーに移行するにつれて、VM のクローン作成の問題がさらに蔓延する可能性があります。
Using dedicated cryptographic hardware is recommended to enforce these requirements, ensure correct behavior, and handle the complexity of state management. In particular, this enables implementing rollback resistant counters, which can be difficult to achieve in a software-only fashion.
これらの要件を強制し、正しい動作を保証し、複雑な状態管理に対処するには、専用の暗号化ハードウェアを使用することをお勧めします。特に、これにより、ソフトウェアのみの方法では実現が難しいロールバック耐性のあるカウンターの実装が可能になります。
On the verifier side, no state management is required. However, the verifier needs to trust the signer to not have reused the state. A verifier may want to check that no state reuse happened in the past by a signer before accepting a signature.
検証者側では、状態管理は必要ありません。ただし、検証者は、署名者が状態を再利用していないことを信頼する必要があります。検証者は、署名を受け入れる前に、署名者によって過去に状態の再利用が行われていないことを確認したい場合があります。
In practice, this can be done if the verifier has access to all signatures issued by the signer. As the signatures contain the index of the OTS key used, detecting if an index was used more than once becomes trivial. In practice, such a (public) data structure that contains all signatures may already be present in some use cases (e.g., Certificate Transparency [RFC9162]) or could be built. It is worth noting that while trusting the signer to not reuse the state is a strong assumption, other signature schemes like the Elliptic Curve Digital Signature Algorithm (ECDSA) introduce similar assumptions by requiring the signer to never reuse the nonce.
実際には、これは、検証者が署名者によって発行されたすべての署名にアクセスできる場合に実行できます。署名には使用された OTS キーのインデックスが含まれているため、インデックスが複数回使用されたかどうかを検出するのは簡単になります。実際には、すべての署名を含むこのような (パブリック) データ構造は、いくつかのユースケース (例: Certificate Transparency [RFC9162]) ですでに存在しているか、構築されている可能性があります。署名者が状態を再利用しないことを信頼することは強力な前提条件ですが、楕円曲線デジタル署名アルゴリズム (ECDSA) などの他の署名スキームでは、署名者に nonce を決して再利用しないことを要求することで同様の前提条件が導入されていることは注目に値します。
A variety of potential solutions have been proposed both within the [SP.800-208] specification, as well as from external sources. This section describes a number of approaches and their potential advantages and disadvantages.
[SP.800-208] 仕様内と外部ソースの両方で、さまざまな潜在的な解決策が提案されています。このセクションでは、いくつかのアプローチとその潜在的な利点と欠点について説明します。
Each approach involves trade-offs in complexity, cost, and operational risk. The purpose of this section is to analyze these trade-offs rather than to recommend a single universally applicable solution.
各アプローチには、複雑さ、コスト、運用リスクのトレードオフが伴います。このセクションの目的は、普遍的に適用できる単一のソリューションを推奨することではなく、これらのトレードオフを分析することです。
[SP.800-208] proposes generating multiple Stateful HBS key pairs and configuring devices and clients to accept signatures created by any of these keys. Secondary Stateful HBS keys can be kept in storage until the first keypair is exhausted or lost.
[SP.800-208] では、複数のステートフル HBS キー ペアを生成し、これらのキーのいずれかによって作成された署名を受け入れるようにデバイスとクライアントを構成することを提案しています。セカンダリ ステートフル HBS キーは、最初のキーペアが使い果たされるか紛失するまでストレージに保管できます。
Accepting multiple public keys negatively impacts one of the advantages of using Stateful HBS by increasing the public key footprint within the client, which can be problematic if it has limited public key storage capacity. (Though public keys are typically equivalently sized to ECDSA rather than larger classical RSA keys often currently found.) [SP.800-208] addresses storage capacity concerns by suggesting using a mechanism such as that proposed in [RFC8649] to update the stored public key by having the current key endorse the next key that is to be installed. Unfortunately, for many constrained devices, the public key is embedded in immutable ROM or fuses due to security reasons, so it cannot be updated in this manner.
複数の公開キーを受け入れると、クライアント内の公開キーのフットプリントが増加するため、ステートフル HBS を使用する利点の 1 つに悪影響が及びます。これは、公開キーのストレージ容量が限られている場合に問題となる可能性があります。(ただし、公開鍵は通常、現在よく見られるより大きな古典的な RSA 鍵ではなく、ECDSA と同等のサイズです。) [SP.800-208] は、[RFC8649] で提案されているようなメカニズムを使用して、現在の鍵に次にインストールされる鍵を承認させることで、保存されている公開鍵を更新することを提案することで、ストレージ容量の問題に対処しています。残念ながら、制約のあるデバイスの多くでは、セキュリティ上の理由から公開キーが不変の ROM またはヒューズに埋め込まれているため、この方法では更新できません。
The proposal of using multiple Stateful HBS key pairs for a single instance also generates questions as to how to establish that approach in existing public key infrastructures. For example, issuing multiple certificates adds the storage needs of the certificate material to the public key footprint. In order to alternatively issue multiple public keys encoded inside a single certificate, one would need a standardized format if interoperability is a concern.
単一インスタンスに複数のステートフル HBS キー ペアを使用するという提案では、既存の公開キー インフラストラクチャでそのアプローチを確立する方法について疑問も生じます。たとえば、複数の証明書を発行すると、公開キーのフットプリントに証明書マテリアルのストレージ要件が追加されます。相互運用性が懸念される場合、単一の証明書内でエンコードされた複数の公開キーを代わりに発行するには、標準化された形式が必要になります。
[SP.800-208] also proposes creating multiple Stateful HBS keys across multiple cryptographic modules using a distributed multi-tree approach that is a variant of the standard hyper-tree-based Stateful HBS schemes HSS and XMSS^MT.
[SP.800-208] では、標準のハイパーツリーベースのステートフル HBS スキーム HSS および XMSS^MT の変形である分散マルチツリー アプローチを使用して、複数の暗号化モジュールにわたって複数のステートフル HBS キーを作成することも提案しています。
This architecture reflects the constraints in [SP.800-208], which does not permit export of private key material from cryptographic modules. The separation between root and subordinate devices enables compliance with this non-export model while maintaining a hierarchical signing structure.
このアーキテクチャは、暗号モジュールからの秘密鍵マテリアルのエクスポートを許可しない [SP.800-208] の制約を反映しています。ルート デバイスと下位デバイスを分離することで、階層的な署名構造を維持しながら、この非エクスポート モデルへの準拠が可能になります。
Trees are instantiated on a root device (HSM_root), as well as one or more subordinate devices (HSM_({sub_i})), and the root tree is used to sign the root nodes of the subordinate trees to synthesize a multi-level Stateful HBS key. The root device is only ever used to sign subordinate device root nodes, while the subordinate device(s) are used to sign messages. This is relatively straightforward to do using HSS, and [SP.800-208] describes the necessary algorithmic modifications when using XMSS^MT.
ツリーはルート デバイス (HSM_root) および 1 つ以上の下位デバイス (HSM_({sub_i})) 上でインスタンス化され、ルート ツリーは下位ツリーのルート ノードに署名してマルチレベル ステートフル HBS キーを合成するために使用されます。ルート デバイスは、下位デバイスのルート ノードに署名するためにのみ使用されますが、下位デバイスはメッセージに署名するために使用されます。これは HSS を使用して行うのが比較的簡単で、[SP.800-208] では XMSS^MT を使用する場合に必要なアルゴリズムの変更について説明しています。
One drawback of this approach is the increased signature size as an additional OTS needs to be generated, effectively doubling the overall signature size. Another concern is the single point of failure nature of relying on the root tree module to sign all of the subordinate trees; if the root tree device fails then no new subordinate trees can be signed. [SP.800-208] suggested that as many subordinate trees as possible be generated during the initial root key generation and subordinate-signing procedure. Unfortunately, this can incur a large capital expenditure to procure all of the necessary devices, many of which may not be used for a long period of time, if at all. The subordinate tree root node signing process must also be carefully managed to ensure top-level trees are only ever used to sign the root nodes of trusted/approved subordinate trees to ensure that no malicious signing request is accepted, which would effectively give a rogue entity the ability to generate valid signatures, thereby undermining the security of the entire system.
このアプローチの欠点の 1 つは、追加の OTS を生成する必要があるため、署名サイズが増加し、実質的に全体の署名サイズが 2 倍になることです。もう 1 つの懸念は、ルート ツリー モジュールに依存してすべての下位ツリーに署名するという単一障害点の性質です。ルート ツリー デバイスに障害が発生すると、新しい下位ツリーに署名できなくなります。[SP.800-208] は、最初のルート鍵生成および従属署名手順中に、できるだけ多くの下位ツリーを生成することを提案しました。残念ながら、必要なすべてのデバイスを調達するには多額の資本支出が発生する可能性があり、その多くはたとえ使用されたとしても長期間使用できない可能性があります。また、下位ツリーのルート ノードの署名プロセスは、悪意のある署名要求が受け入れられないように、トップレベルのツリーが信頼/承認された下位ツリーのルート ノードの署名にのみ使用されるように慎重に管理する必要があります。これにより、不正なエンティティに有効な署名を生成する能力が効果的に付与され、システム全体のセキュリティが損なわれることになります。
[SP.800-208] also suggests combining distributed multi-trees with multiple root public keys as a means to mitigate some of the concerns regarding having a single point of failure in the root tree. However, even if a system operator does everything right, use cases with exceptionally long lifetimes of 10-20+ years (e.g., automotive and aerospace/satellite applications) will require system operators to rely on devices well beyond their expected lifetimes of 5-10 years, which may constitute an unacceptable business risk.
[SP.800-208] はまた、ルート ツリーに単一障害点があることに関する懸念の一部を軽減する手段として、分散マルチツリーと複数のルート公開鍵を組み合わせることを提案しています。ただし、システム オペレーターがすべてを正しく行ったとしても、耐用年数が 10 ～ 20 年以上と非常に長いユースケース (自動車および航空宇宙/衛星アプリケーションなど) では、システム オペレーターは、予想される耐用年数 5 ～ 10 年をはるかに超えたデバイスに依存する必要があり、これは許容できないビジネス リスクとなる可能性があります。
Distributed multi-trees attempt to partition a Stateful HBS signing space amongst multiple cryptographic modules by breaking up the signing space along the boundaries of the subordinate trees generated during the multi-tree key generation process. An alternative approach based on the state reservation concept described in Section 5 of [MCGREW] would be to use only a single tree and partition its signature space along some power-of-2 less than the total number of leaves in the tree (e.g., 2^s for a tree of height h > s), creating N = 2^(h-s) partitions or sectors, which are instantiated as N height-s Merkle trees whose root nodes are considered interior nodes of the overall height-h Merkle tree. Hence, there is no additional OTS required to sign their root nodes; their values are used as-is in the tree ascent mechanism of the underlying Stateful HBS scheme, yielding a common public key (i.e., root node) for all sectors. Care must be taken to ensure that each sector uses the same root tree identifier (i.e., the "I" value for HSS/LMS and "root" value for XMSS/XMSS^MT).
分散マルチツリーは、マルチツリー キーの生成プロセス中に生成された下位ツリーの境界に沿って署名スペースを分割することにより、ステートフル HBS 署名スペースを複数の暗号化モジュール間で分割しようとします。[MCGREW] のセクション 5 で説明されている状態予約の概念に基づく別のアプローチは、単一のツリーのみを使用し、その署名空間をツリー内の葉の総数より少ない 2 のべき乗に沿って分割し (たとえば、高さ h > s のツリーの場合は 2^s)、N = 2^(h-s) のパーティションまたはセクターを作成し、ルート ノードが全体の高さ h の内部ノードとみなされる N 高さ -s のマークル ツリーとしてインスタンス化されます。マークルの木。したがって、ルート ノードに署名するために追加の OTS は必要ありません。それらの値は、基礎となるステートフル HBS スキームのツリー上昇メカニズムでそのまま使用され、すべてのセクターに共通の公開キー (ルート ノードなど) が生成されます。各セクターが同じルート ツリー識別子 (つまり、HSS/LMS の場合は「I」値、XMSS/XMSS^MT の場合は「root」値) を使用するように注意する必要があります。
Each of the N sectors' OTS private key values can be generated pseudorandomly from a unique seed value generated from an appropriate source of randomness. The private keys from different sectors are independent when generated by this process. This requires that the path information for the root node of each sector (i.e., all off-path nodes between the sector root node and the top level node value) be stored with each sector's private key at key generation time since a sector will not know the seed information required to compute any of the other sectors' root nodes during the tree ascent phase of a signature generation operation. During signature generation, the signer appends the stored path information to the path information it computes to ascend from the leaf OTS to the sector's root node (which it can compute given that it knows its own seed value).
N セクターの OTS 秘密キー値はそれぞれ、適切な乱数源から生成された一意のシード値から擬似ランダムに生成できます。このプロセスによって生成されるとき、さまざまなセクターの秘密鍵は独立しています。これには、各セクターのルート ノード (つまり、セクター ルート ノードとトップレベル ノード値の間のすべてのオフパス ノード) のパス情報が、鍵生成時に各セクターの秘密鍵とともに格納される必要があります。これは、セクターは、署名生成操作のツリー上昇フェーズ中に他のセクターのルート ノードのいずれかを計算するために必要なシード情報を知らないためです。署名の生成中、署名者は、リーフ OTS からセクターのルート ノードまで上昇するために計算したパス情報に、保存されたパス情報を追加します (署名者は、自身のシード値を知っている場合に計算できます)。
Hence, sectorized key generation results in a single public key value and 2^(h-s) private key values, each capable of generating 2^s signatures after which the sectorized key is exhausted.
したがって、セクター化されたキーの生成により、単一の公開キー値と 2^(h-s) 個の秘密キー値が生成され、それぞれが 2^s の署名を生成でき、その後セクター化されたキーが使い果たされます。
In addition to avoiding an increased signature size; when unique seeds are utilized, sectorization breaks a given Stateful HBS key/ state into multiple independent fragments that can be managed as independent objects. As a result, system operators may distribute sectors to multiple cryptographic devices, providing scalability through parallelization and improved resiliency/availability. This approach offers isolation between sectors, ensuring that a compromise in one does not extend to others, thereby supporting damage containment. At the same time, it simplifies operational robustness by removing the need for cross-device state coordination since each sector is restricted to its own signature space.
署名サイズの増大を避けることに加えて、固有のシードが利用される場合、セクター化により、特定のステートフル HBS キー/状態が、独立したオブジェクトとして管理できる複数の独立したフラグメントに分割されます。その結果、システム オペレータはセクタを複数の暗号化デバイスに分散し、並列化によるスケーラビリティと回復力/可用性の向上を実現できます。このアプローチはセクター間の隔離を提供し、あるセクターでの侵害が他のセクターに及ばないようにすることで、被害の封じ込めをサポートします。同時に、各セクターが独自の署名スペースに制限されるため、デバイス間の状態調整の必要性がなくなり、運用の堅牢性が簡素化されます。
Stateful HBS key/state transfer between cryptographic modules entails having a means to migrate one instance of a Stateful HBS key/state on a source device to a separate destination device while ensuring that any copy of the key/state is deleted from the source device.
暗号化モジュール間でのステートフル HBS キー/状態の転送には、キー/状態のコピーがソース デバイスから確実に削除されるようにしながら、ソース デバイス上のステートフル HBS キー/状態の 1 つのインスタンスを別の宛先デバイスに移行する手段が必要です。
This capability may help alleviate the aforementioned concern regarding operating devices beyond their expected lifetimes by allowing operators to migrate Stateful HBS key/state to a newer device when the original device begins to approach its end-of-life. However, it still leaves the operator vulnerable to having the source device fail before the key/state can be transferred, effectively causing the loss of the key/state. Hence, it will not be of much help addressing the single point of failure issue identified for root trees, but may be useful for managing subordinate trees.
この機能は、元のデバイスが寿命に近づき始めたときにオペレーターがステートフル HBS キー/状態を新しいデバイスに移行できるようにすることで、予想される寿命を超えてデバイスを操作することに関する前述の懸念を軽減するのに役立つ可能性があります。ただし、キー/状態が転送される前にソース デバイスに障害が発生し、実質的にキー/状態が失われる可能性があるため、オペレータは依然として脆弱なままです。したがって、ルート ツリーで特定された単一障害点の問題の解決にはあまり役に立ちませんが、下位ツリーの管理には役立つ可能性があります。
In addition to complete key/state transfer, a device holding part of the total available OTSs may transfer some unused capacity to another device (partial state transfer). In more advanced deployments, state fragments from two devices may be merged to reconstruct or continue signature operations. These operations carry risk: ensuring no overlap in used indices, ensuring atomicity of transfer/merge operations, managing consistency, possible conflicts, and durability of state across devices. Such approaches require robust synchronization, auditability, and appropriate backup mechanisms to avoid double-signing or loss of capacity.
完全なキー/状態転送に加えて、利用可能な OTS の合計の一部を保持するデバイスは、未使用の容量の一部を別のデバイスに転送する場合があります (部分的な状態転送)。より高度な展開では、2 つのデバイスからの状態フラグメントをマージして、署名操作を再構築または継続することができます。これらの操作にはリスクが伴います。使用されるインデックスの重複がないようにすること、転送/マージ操作のアトミック性を確保すること、一貫性、競合の可能性、およびデバイス間での状態の耐久性を管理することです。このようなアプローチでは、二重署名や容量の損失を回避するために、堅牢な同期、監査可能性、および適切なバックアップ メカニズムが必要です。
A more elaborate variant of key transfer, going beyond what [SP.800-208] allows, is described in Section 6, where key transfer is accomplished using a two-step export and import process with hash-based transfer validation to yield a more robust transfer mechanism.
[SP.800-208] で許可されている範囲を超えた、より精巧な鍵転送の変形についてはセクション 6 で説明されています。そこでは、より堅牢な転送メカニズムを生み出すために、ハッシュベースの転送検証を備えた 2 段階のエクスポートおよびインポートのプロセスを使用して鍵転送が実行されます。
Key rotation, such as that defined in [RFC8649], would generate new Stateful HBS keys on an as-needed basis and provide a means to transition the system on to using this new Stateful HBS key while generating the next key in the chain in preparation of a future rotation/update. However, this just shifts the problem to the PKI and certificate handling.
[RFC8649] で定義されているようなキーのローテーションは、必要に応じて新しいステートフル HBS キーを生成し、将来のローテーション/更新に備えてチェーン内の次のキーを生成しながら、この新しいステートフル HBS キーの使用にシステムを移行する手段を提供します。ただし、これは問題を PKI と証明書の処理に移しているだけです。
In most use cases, key rotation is not foolproof since it will require redundancy to ensure there is at least one Stateful HBS signing key available to attest to newly generated keys. In addition, for many applications, the device keys cannot be updated due to engineering constraints or security reasons.
ほとんどの使用例では、キーのローテーションは、新しく生成されたキーを証明するために使用できるステートフル HBS 署名キーが少なくとも 1 つあることを保証するための冗長性が必要となるため、絶対確実ではありません。さらに、多くのアプリケーションでは、エンジニアリング上の制約やセキュリティ上の理由により、デバイス キーを更新できません。
A variant of the key rotation approach is to have an available signing tree endorse a new subordinate tree when it is about to become exhausted (e.g., use its final OTS to sign the root node of a new subordinate tree, creating an {n+1}-layer multi-tree from an {n}- layer multi-tree). In theory, this process can be repeated as many times as necessary. However, this entails having a multi-tree scheme with a variable number of levels, and hence, variable-length signatures. Such dynamically extensible constructions are research-class and are not currently standardized or deployed.
鍵ローテーションアプローチの変形は、新しい下位ツリーが枯渇しそうになったときに、利用可能な署名ツリーに新しい下位ツリーを承認させることです（たとえば、その最後の OTS を使用して新しい下位ツリーのルートノードに署名し、{n} 層のマルチツリーから {n+1} 層のマルチツリーを作成します）。理論的には、このプロセスは必要なだけ繰り返すことができます。ただし、これには可変数のレベル、つまり可変長の署名を備えたマルチツリー スキームが必要になります。このような動的に拡張可能な構造は研究クラスのものであり、現在は標準化も展開もされていません。
In addition to departing quite significantly from the current Stateful HBS specifications and [SP.800-208], this approach has a number of significant challenges on both the engineering and operational fronts. Firstly, the variable-length nature of the signature can lead to variable-length verification of signatures, which may cause significant issues for use cases with strict time constraints (e.g., secure booting of a semiconductor device). From an operational perspective, the ability of a subordinate tree to sign either messages or new subordinate trees leads to severe security implications as the rigor around authorizing those two types of operations will vary dramatically, leading to either a much more onerous message signing operation or a much riskier subordinate tree signing operation. This approach may put the system operator in an untenable situation where no users are satisfied with the resulting solution, and hence, should not be considered as a viable solution.
現在のステートフル HBS 仕様および [SP.800-208] から大幅に逸脱していることに加えて、このアプローチにはエンジニアリング面と運用面の両方で多くの重大な課題があります。まず、署名の可変長の性質により、署名の検証が可変長になる可能性があり、厳しい時間制約のあるユースケース (半導体デバイスの安全なブートなど) では重大な問題が発生する可能性があります。運用の観点から見ると、下位ツリーがメッセージまたは新しい下位ツリーに署名できるかどうかは、セキュリティに重大な影響を及ぼします。これらの 2 種類の操作の認可に関する厳密さが大幅に異なるため、より面倒なメッセージ署名操作か、よりリスクの高い下位ツリー署名操作のどちらかが発生することになります。このアプローチは、システム オペレータを、結果として得られるソリューションに満足するユーザーがいないという耐え難い状況に陥らせる可能性があるため、実行可能なソリューションとはみなすべきではありません。
In some applications, individual one-time signatures (or states) can be pre-assigned to the to-be-signed objects. This may, for example, be possible if the signed objects are monotonically increasingly numbered. One example of such a use case may be software signing. This solution basically externalizes the state management to the to-be-signed messages.
一部のアプリケーションでは、個々のワンタイム署名 (または状態) を署名対象オブジェクトに事前に割り当てることができます。これは、たとえば、署名されたオブジェクトに単調増加する番号が付けられている場合に可能になる可能性があります。このような使用例の一例としては、ソフトウェア署名が挙げられます。このソリューションは基本的に、状態管理を署名対象メッセージに外部化します。
Expanding on the given example, for software that is released with strictly increasing, simple, single-position version numbers (i.e., versions 1, 2, 3, ...), this can be trivially implemented. As versions have a one-to-one correspondence to a Stateful HBS signing state, operators must ensure that versions can only be minted a single time. This may require skipping version numbers if a release process failed to avoid double-signing.
与えられた例を拡張すると、厳密に増加する単純な 1 桁のバージョン番号 (バージョン 1、2、3、...) でリリースされるソフトウェアの場合、これは簡単に実装できます。バージョンはステートフル HBS 署名状態と 1 対 1 で対応するため、オペレーターはバージョンが 1 回のみ作成できることを確認する必要があります。リリース プロセスで二重署名を回避できなかった場合、バージョン番号をスキップする必要がある場合があります。
This scheme can be adapted to more complicated release schemes. For example, minor update-releases 1.0 to 1.99 can be accommodated by assigning signatures 1-100 for these version numbers, while release 2.0-2.99 would get signatures 101-200. The assignments must be fixed as the scheme is set up, and operators should take into account that they are strictly limiting the number of update releases. In the described solution to state management, one must move up a major release number after 99 minor releases, even if this would break, e.g., semantic versioning conventions.
このスキームは、より複雑なリリース スキームに適用できます。たとえば、マイナー アップデート リリース 1.0 ～ 1.99 は、これらのバージョン番号に署名 1 ～ 100 を割り当てることで対応できますが、リリース 2.0 ～ 2.99 には署名 101 ～ 200 が割り当てられます。割り当てはスキームの設定時に修正する必要があり、運用者は更新リリースの数を厳密に制限していることを考慮する必要があります。説明した状態管理のソリューションでは、たとえセマンティック バージョン管理規則に違反する場合でも、99 回のマイナー リリースの後にメジャー リリース番号を上げなければなりません。
A variant of pre-assigning signatures is doing this on the basis of time, which is described in the next section.
署名の事前割り当ての変形では、これを時間に基づいて実行します。これについては、次のセクションで説明します。
As a variant of pre-assigning one-time signatures based on external counters, it is possible to base the selection of one-time signature indexes on the current date and time in theory. For example, if a given Stateful HBS instance offers 1024 total signatures, they could be broken up into 8 groups of 128 OTS instances each, with the first 128 allowed to be used in the first time window, the second 128 in the second time window, and so on, until the signature space is effectively exhausted after 8 time windows. Note that a time-based approach to state management will "waste" any OTS keys that are unused in past time windows. One must not attempt to use these keys after the time window has gone by.
外部カウンターに基づいてワンタイム署名を事前に割り当てる変形として、理論的には、現在の日付と時刻に基づいてワンタイム署名インデックスの選択を行うことができます。たとえば、特定のステートフル HBS インスタンスが合計 1024 個の署名を提供する場合、それらをそれぞれ 128 個の OTS インスタンスからなる 8 つのグループに分割し、最初の 128 個は最初の時間枠で使用でき、2 番目の 128 個は 2 番目の時間枠で使用できるというように、8 個の時間枠の後に署名スペースが実質的に使い果たされるまで使用できます。状態管理に対する時間ベースのアプローチでは、過去の時間枠で使用されなかった OTS キーが「無駄」になることに注意してください。時間枠が経過した後は、これらのキーを使用しないでください。
Any time-based approach has a very strict reliance on accurate timekeeping and synchronization of clocks. In particular, we identify that at least the following engineering-related challenges need to be considered:
時間ベースのアプローチはどれも、正確な時間管理とクロックの同期に非常に厳密に依存します。特に、少なくとも次のエンジニアリング関連の課題を考慮する必要があると認識しています。
* Signing devices must have accurate timekeeping (which is a very challenging engineering problem [TIMEFALSEHOODS]).
* 署名デバイスには正確な時刻管理が必要です (これは非常に困難なエンジニアリング上の問題 [TIMEFALSEHOODS])。
* Time on signing devices must not be allowed to ever move backwards, as this can cause double-signing.
* 二重署名が発生する可能性があるため、署名デバイスの時間を逆方向に進めてはなりません。
* Within time windows, signers must track the number of signatures produced to ensure it does not exceed the number allowed within the window.
* 署名者は、時間枠内で生成された署名の数を追跡し、時間枠内で許可されている数を超えていないことを確認する必要があります。
* Signing devices must still operate consistently with the requirements of state keeping for Stateful HBS. The signature index within a time window should still appear to be updated atomically and signatures must not be released before state changes have been recorded.
* 署名デバイスは、ステートフル HBS の状態維持の要件に従って一貫して動作する必要があります。時間枠内の署名インデックスは引き続きアトミックに更新されるように見える必要があり、状態の変更が記録される前に署名を解放してはなりません。
* A system should be robust against exhaustion of the number of signatures available in a time window, as in this case, it is required to wait until the next time window starts before new messages can be signed.
* システムは、時間枠内で利用可能な署名の数が枯渇した場合に備えて堅牢である必要があります。この場合、新しいメッセージに署名するには、次の時間枠が開始されるまで待つ必要があります。
* Time on signing devices should not be allowed to be moved forward maliciously or accidentally, which would allow for a simple denial-of-service attack by skipping over portions of the signature space.
* 署名デバイスの時間を悪意または偶発的に繰り上げることは許可されるべきではありません。これにより、署名スペースの一部をスキップすることによる単純なサービス拒否攻撃が可能になります。
* If a signing device needs to be replaced, the replacement device must be set up with its time in sync with or ahead of the device it is to replace. This implies the current time on signing devices should be continuously recorded.
* 署名デバイスを交換する必要がある場合、交換用デバイスの時刻を、交換するデバイスと同期するか、交換するデバイスよりも先に設定する必要があります。これは、署名デバイスの現在時刻を継続的に記録する必要があることを意味します。
* Rate limiting may need to be considered, as exhausting the available signatures in a given time window may otherwise be easy.
* レート制限を考慮する必要がある場合があります。そうしないと、指定された時間枠内で利用可能な署名を使い果たすことが簡単になる可能性があります。
* It may be necessary for signers to keep a separate clock for time-based state management, and one for not necessarily monotonically increasing "wall-time", e.g., if signed artifacts are expected to be time-stamped with real-world time.
* 署名者は、時間ベースの状態管理用と、必ずしも単調に増加するわけではない「ウォールタイム」用のクロックを別個に保持する必要がある場合があります (たとえば、署名されたアーティファクトに実世界の時刻でタイムスタンプが付けられることが期待される場合)。
If these concerns cannot be sufficiently addressed, time-based state management as described in this paragraph should not be used. Note that this list of concerns is not exhaustive, and other, unmentioned, concerns may also be relevant to the security of a time-based solution.
これらの懸念に十分に対処できない場合は、この段落で説明する時間ベースの状態管理を使用すべきではありません。この懸念事項のリストはすべてを網羅しているわけではなく、言及されていない他の懸念事項も時間ベースのソリューションのセキュリティに関連する可能性があることに注意してください。
Time-based systems can be backed up by simply recording the private keys and the configuration of the time windows. In case of loss of a signing device, a time-based state management system can be recovered by using this information to bring online a new device in the next time window. This approach may also be used as a recovery mechanism in the case of (suspected) state consistency problems during a time window. However, the operator must not allow new signatures to be produced before the new time window starts unless they know the exact state at which the previous device became unavailable and are able to set up the new device accordingly. Waiting until the start of the next time window avoids double signing, as the OTS keys assigned to future time windows are guaranteed to have not yet been used. However, this might incur significant downtime of the signing systems. Downtime may be avoided by forcibly moving the signing device to the next time window by incrementing its clock; however, this induced clock drift will then need to be accounted for in the future. If clock drift is to be avoided, this approach should account for availability considerations.
時間ベースのシステムは、秘密鍵と時間枠の構成を記録するだけでバックアップできます。署名デバイスが失われた場合、この情報を使用して時間ベースの状態管理システムを回復し、次の時間枠で新しいデバイスをオンラインにすることができます。このアプローチは、時間ウィンドウ中に状態の一貫性の問題が発生した (疑いがある) 場合の回復メカニズムとしても使用できます。ただし、オペレータは、以前のデバイスが使用できなくなった正確な状態を把握しており、それに応じて新しいデバイスを設定できる場合を除き、新しい時間枠が開始する前に新しい署名の生成を許可してはなりません。将来の時間枠に割り当てられた OTS キーはまだ使用されていないことが保証されるため、次の時間枠の開始まで待機すると二重署名が回避されます。ただし、これにより、署名システムに大幅なダウンタイムが発生する可能性があります。ダウンタイムは、署名デバイスのクロックをインクリメントして強制的に次の時間枠に移動することで回避できます。ただし、この誘発されたクロック ドリフトは将来的に考慮する必要があります。クロックのドリフトを回避する必要がある場合、このアプローチでは可用性を考慮する必要があります。
The State Reservation Strategy described in Section 5 of [MCGREW] provides another means of managing the state by allowing users to reserve intervals of the signing space, marking the interval's associated OTS keys as being used in the overall HBS state, which is then written back to non-volatile memory prior to their usage. The OTS keys within the reservation interval are then consumed as-needed without having to update the state again until they have all been consumed and additional OTS keys are required. Note that the reserved OTS keys are kept in dynamic memory so they will be lost if the signing device loses power or is reset, resulting in a reduction in the number of usable signatures for a given HBS instantiation.
[MCGREW] のセクション 5 で説明されている状態予約戦略は、ユーザーが署名スペースの間隔を予約できるようにすることで状態を管理する別の手段を提供し、その間隔に関連付けられた OTS キーを HBS 状態全体で使用されるものとしてマークし、使用前に不揮発性メモリに書き戻されます。予約間隔内の OTS キーは、すべてが消費されて追加の OTS キーが必要になるまで、状態を再度更新することなく、必要に応じて消費されます。予約された OTS キーは動的メモリに保持されるため、署名デバイスの電源が切れたりリセットされたりすると失われ、その結果、特定の HBS インスタンス化で使用可能な署名の数が減少することに注意してください。
Over provisioning can be used to ensure a sufficient number of signatures can be provided in the presence of unexpected losses due to power loss or resets. Over provisioning will cause a minor increase between 2% and 12% on signature length as the MTS validation paths increase to accommodate the increased Merkle tree height. However, reservation eliminates the need to update the state after each OTS key is used, minimizing the likelihood of state reuse due to state update failures and coherency issues.
オーバー プロビジョニングを使用すると、電力損失やリセットによる予期せぬ損失が発生した場合でも、十分な数の署名を提供できるようにすることができます。マークル ツリーの高さの増加に対応するために MTS 検証パスが増加するため、オーバー プロビジョニングにより署名の長さが 2% ～ 12% わずかに増加します。ただし、予約により、各 OTS キーが使用された後に状態を更新する必要がなくなり、状態更新の失敗や一貫性の問題による状態の再利用の可能性が最小限に抑えられます。
In theory, multiple signing devices can utilize reservation intervals to carve out portions of signing space so that a single Stateful HBS key can be shared amongst multiple devices, leading to potential performance and disaster-recovery benefits. However, great care must be taken to manage the reservations to ensure there is no overlap or repeated reservation of a given interval, either in part or in whole.
理論的には、複数の署名デバイスは予約間隔を利用して署名スペースの一部を切り出すことができるため、単一のステートフル HBS キーを複数のデバイス間で共有でき、潜在的なパフォーマンスと災害復旧の利点につながります。ただし、部分的または全体的に、特定の間隔の予約が重複したり繰り返されたりしないように、予約の管理には細心の注意を払う必要があります。
This section presents in a generic form an alternative backup mechanism for Stateful HBS, which makes the strategy applicable for both multi-tree instances XMSS^MT and HSS. However, following the same arguments as in Section 5.3, with minor modifications, the presented strategy is also applicable for single-tree instances such as XMSS and LMS.
このセクションでは、ステートフル HBS の代替バックアップ メカニズムを一般的な形式で示します。これにより、この戦略はマルチツリー インスタンス XMSS^MT と HSS の両方に適用できます。ただし、セクション 5.3 と同じ議論に従い、若干の変更を加えた上で、提示された戦略は XMSS や LMS などの単一ツリー インスタンスにも適用できます。
The strategy presented in this section builds upon the multi-tree variant approach from [SP.800-208] and aims to mitigate its limitations described in Section 5.2. Thus, it is assumed that a top-level Merkle tree (for signing the root-nodes of sub-trees) and several bottom-level Merkle trees (for signing messages) are already instantiated. These bottom-level trees may be implemented on different hardware modules in order to obtain redundancy and improve availability. Let R be the number of these already initiated bottom-level trees. Let h_0 be the height of the top-level-tree. It is assumed that R + 1 is strictly smaller than 2^(h_0), the number of leaves of the top-level tree.
このセクションで説明する戦略は、[SP.800-208] のマルチツリー バリアント アプローチに基づいて構築されており、セクション 5.2 で説明されているその制限を軽減することを目的としています。したがって、トップレベルのマークル ツリー (サブツリーのルート ノードに署名するため) といくつかのボトムレベルのマークル ツリー (メッセージに署名するため) がすでにインスタンス化されていると想定されます。これらの最下位ツリーは、冗長性を確保して可用性を向上させるために、異なるハードウェア モジュールに実装される場合があります。R をこれらのすでに開始されている最下位ツリーの数とする。h_0 を最上位ツリーの高さとします。R + 1 は、トップレベルのツリーの葉の数である 2^(h_0) よりも厳密に小さいと想定されます。
In this new strategy, after the completed key generation procedure from the multi-tree variant approach from [SP.800-208], further bottom-level trees are generated, one by one, in one of the hardware modules. These new bottom-level trees are each generated from a different seed, which is chosen uniformly at random. The following notations are introduced for the sake of clarity:
この新しい戦略では、[SP.800-208] のマルチツリーバリアントアプローチによる鍵生成手順が完了した後、ハードウェアモジュールの 1 つでさらに下位レベルのツリーが 1 つずつ生成されます。これらの新しい最下位ツリーはそれぞれ、均一にランダムに選択された異なるシードから生成されます。わかりやすくするために、次の表記法が導入されています。
* S denotes the number of these newly generated bottom-level trees. Note that at most 2^(h_0) - R new bottom-level trees can be generated, i.e., S is lower or equal to 2^(h_0) - R. In the following we suppose that S is _strictly smaller_ than 2^(h_0) - R.
* S は、これらの新しく生成された最下位ツリーの数を示します。最大で 2^(h_0) - R の新しい最下位ツリーが生成できることに注意してください。つまり、S は 2^(h_0) - R 以下です。以下では、S が 2^(h_0) - R よりも「厳密に小さい」と仮定します。
* I_new denotes the set of indices that belong to these newly generated bottom-level trees, i.e., I_new = {R, R+1, ..., R+S-1}. Bottom-level trees are indexed starting at 0.
* I_new は、これらの新しく生成された最下位ツリーに属するインデックスのセット、つまり I_new = {R, R+1, ..., R+S-1} を示します。最下位レベルのツリーには 0 から始まるインデックスが付けられます。
For each new bottom-level tree, after it has been generated, the following steps must be performed:
新しい最下位ツリーごとに、生成後に次の手順を実行する必要があります。
* sign the corresponding root node with an unused OTS key from the top-level tree,
* 最上位ツリーの未使用の OTS キーを使用して、対応するルート ノードに署名します。
* securely _key export_ (as described in Section 2.4) the seed, which was used to generate the bottom-level tree,
* 最下位レベルのツリーを生成するために使用されたシードを安全に _key export_ (セクション 2.4 で説明)、
* export the signature of the root node, the corresponding OTS key index, and finally the hash of the seed, using appropriate domain separation (i.e., ensuring there is no domain overlap with the hashes in the Stateful HBS scheme, and that the hash of the seed includes the public key and leaf index to mitigate multi-target attacks), and
* 適切なドメイン分離を使用して、ルート ノードの署名、対応する OTS キー インデックス、そして最後にシードのハッシュをエクスポートします (つまり、ステートフル HBS スキームのハッシュとドメインの重複がないことを確認し、マルチターゲット攻撃を軽減するためにシードのハッシュに公開キーとリーフ インデックスが含まれていることを確認します)。
* irreversibly delete the seed and the bottom-level tree from the hardware module.
* ハードウェア モジュールからシードと最下位レベルのツリーを不可逆的に削除します。
The newly generated bottom-level trees (i.e., those bottom-level trees, whose indices belong to I_new) are only used in order to guarantee availability in the _worst-case scenario_, where, at the same time, both of the following conditions hold:
新しく生成された最下位ツリー (つまり、インデックスが I_new に属する最下位ツリー) は、次の両方の条件が同時に成立する、_最悪のシナリオ_ での可用性を保証するためにのみ使用されます。
* none of the R bottom-level Merkle trees (which were generated according to the multi-tree variant approach from [SP.800-208]) are available for signing messages, and
* R の最下位レベルのマークル ツリー ([SP.800-208] のマルチツリー バリアント アプローチに従って生成されたもの) はメッセージの署名に使用できません。
* the top-level Merkle tree (which is used for signing the root-nodes of sub-trees) is also not available anymore.
* 最上位のマークル ツリー (サブツリーのルートノードの署名に使用される) も利用できなくなりました。
For example, this scenario may happen if all hardware modules are broken at the same time.
たとえば、すべてのハードウェア モジュールが同時に壊れた場合、このシナリオが発生する可能性があります。
As soon as this worst-case scenario occurs, the newly generated bottom-level trees (i.e., those bottom-level trees, whose indices belong to I_new) need to be initiated in order to ensure availability. In order to do this, the following steps must be performed:
この最悪のシナリオが発生するとすぐに、可用性を確保するために、新しく生成された最下位ツリー (つまり、インデックスが I_new に属する最下位ツリー) を開始する必要があります。これを行うには、次の手順を実行する必要があります。
* initiate a new hardware module,
* 新しいハードウェア モジュールを開始し、
* securely _key import_ (as described in Section 2.4) the first unused seed into this hardware module,
* 最初の未使用シードをこのハードウェア モジュールに安全に _key import_ (セクション 2.4 で説明)、
* generate the bottom-level tree corresponding to the seed,
* シードに対応する最下位ツリーを生成し、
* irreversibly delete the seed from the backup medium, and
* シードをバックアップ メディアから不可逆的に削除し、
* perform a correctness check by letting the hardware module output the hash of the seed.
* ハードウェア モジュールにシードのハッシュを出力させることで、正当性チェックを実行します。
Now this bottom-level tree can be used to sign messages. As soon as no more OTSs on the bottom-level tree are available or as soon as the hardware module is broken, the above steps with a new seed from the backup medium can be repeated.
これで、この最下位ツリーをメッセージの署名に使用できるようになります。最下位ツリー上の利用可能な OTS がなくなるとすぐ、またはハードウェア モジュールが壊れるとすぐに、バックアップ メディアからの新しいシードを使用して上記の手順を繰り返すことができます。
Note that the resulting signatures generated from these backed-up seeds do not require any special processing on the verifier side. The signature stored alongside the backed up seed and the signature generated from the bottom-level trees created from the backed up seed can be combined to match the format of a signature over the complete tree.
これらのバックアップされたシードから生成された署名は、検証者側で特別な処理を必要としないことに注意してください。バックアップされたシードと一緒に保存された署名と、バックアップされたシードから作成された最下位レベルのツリーから生成された署名を組み合わせて、ツリー全体の署名の形式と一致させることができます。
Security considerations are given throughout this document. Further security considerations, which are not already covered in this document, are given in [SP.800-208], [MCGREW], [FIPS205], [RFC8391], and [RFC8554].
セキュリティに関する考慮事項は、このドキュメント全体で説明されています。この文書ではまだ説明されていないさらなるセキュリティ上の考慮事項については、[SP.800-208]、[MCGREW]、[FIPS205]、[RFC8391]、および [RFC8554] で説明されています。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
Mohaisen, "XMSS: eXtended Merkle Signature Scheme",
RFC 8391, DOI 10.17487/RFC8391, May 2018,
<https://www.rfc-editor.org/info/rfc8391>.
[RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554,
April 2019, <https://www.rfc-editor.org/info/rfc8554>.
[SP.800-208]
Cooper, D., Apon, D., Dang, Q., Davidson, M., Dworkin, M.,
and C. Miller, "NIST SP 800-208: Recommendation for
Stateful Hash-Based Signature Schemes", NIST, NIST
SP 800-208, DOI 10.6028/NIST.SP.800-208, October 2020,
<https://doi.org/10.6028/NIST.SP.800-208>.
[BH16] Bruinderink, L. and A. Hülsing, "Oops, I did it again --
Security of One-Time Signatures under Two-Message
Attacks.", Cryptology ePrint Archive, Paper 2016/1042,
Selected Areas in Cryptography - SAC 2017, August 16-18,
pp. 299-322, 2016,
<https://eprint.iacr.org/2016/1042.pdf>.
[BSW16] Bellare, M., Stepanovs, I., and B. Waters, "New Negative
Results on Differing-Inputs Obfuscation", Advances in
Cryptology - EUROCRYPT 2016, Lecture Notes in Computer
Science, vol. 9666, pp. 792-821,
DOI 10.1007/978-3-662-49896-5_28, 28 April 2016,
<https://link.springer.com/
chapter/10.1007/978-3-662-49896-5_28>.
[CNSA2.0] NSA, "Commercial National Security Algorithm Suite 2.0
(CNSA 2.0) Cybersecurity Advisory (CSA)", September 2022,
<https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/
CSA_CNSA_2.0_ALGORITHMS.PDF>.
[CRYPTO-IoT]
Moran, B., Rønningstad, O., and A. Tsukamoto,
"Cryptographic Algorithms for Internet of Things (IoT)
Devices", Work in Progress, Internet-Draft, draft-ietf-
suit-mti-23, 22 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-suit-
mti-23>.
[ETSI-TR-103-692]
ETSI, "CYBER; State management for stateful authentication
mechanisms", ETSI TR 103 692, V1.1.1, November 2021,
<https://www.etsi.org/deliver/
etsi_tr/103600_103699/103692/01.01.01_60/
tr_103692v010101p.pdf>.
[FIPS204] NIST, "Module-Lattice-Based Digital Signature Standard",
NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, 13 August 2024,
<https://doi.org/10.6028/NIST.FIPS.204>.
[FIPS205] NIST, "Stateless Hash-Based Digital Signature Standard",
NIST FIPS 205, DOI 10.6028/NIST.FIPS.205, 13 August 2024,
<https://doi.org/10.6028/NIST.FIPS.205>.
[Fluhrer23]
Fluhrer, S., "Oops, I did it again revisited: another look
at reusing one-time signatures", 23 December 2017,
<https://eprint.iacr.org/2023/1905>.
[HBSX509] Bashiri, K., Fluhrer, S., Gazdag, S., Van Geest, D., and
S. Kousidis, "Internet X.509 Public Key Infrastructure:
Algorithm Identifiers for Hash-based Signatures", Work in
Progress, Internet-Draft, draft-gazdag-x509-hash-sigs-03,
15 February 2024, <https://datatracker.ietf.org/doc/html/
draft-gazdag-x509-hash-sigs-03>.
[MCGREW] McGrew, D., Kampanakis, P., Fluhrer, S., Gazdag, S.,
Butin, D., and J. Buchmann, "State Management for Hash-
Based Signatures", Cryptology ePrint Archive, Paper
2016/357, Security Standardization Research 2016, 2
November 2016, <https://eprint.iacr.org/2016/357.pdf>.
[RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the
Cryptographic Algorithm Object Identifier Range",
RFC 8411, DOI 10.17487/RFC8411, August 2018,
<https://www.rfc-editor.org/info/rfc8411>.
[RFC8649] Housley, R., "Hash Of Root Key Certificate Extension",
RFC 8649, DOI 10.17487/RFC8649, August 2019,
<https://www.rfc-editor.org/info/rfc8649>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC9802] Van Geest, D., Bashiri, K., Fluhrer, S., Gazdag, S., and
S. Kousidis, "Use of the HSS and XMSS Hash-Based Signature
Algorithms in Internet X.509 Public Key Infrastructure",
RFC 9802, DOI 10.17487/RFC9802, June 2025,
<https://www.rfc-editor.org/info/rfc9802>.
[TIMEFALSEHOODS]
Visée, T., "Falsehoods programmers believe about time",
<https://gist.github.com/timvisee/
fcda9bbdff88d45cc9061606b4b923ca>.
This document was inspired by discussions at the 2nd Oxford Post-Quantum Cryptography Summit 2023.
この文書は、2023 年の第 2 回オックスフォードポスト量子暗号サミットでの議論に触発されて作成されました。
We gratefully acknowledge Melissa Azouaoui for her input to this document.
この文書に対する Melissa Azouaui の貢献に感謝します。
The abstract and the introduction are based on the introduction in [HBSX509]. Thanks go to the authors of that document. "Copying always makes things easier and less error prone." - [RFC8411]
要約と序文は、[HBSX509] の序文に基づいています。この文書の作成者に感謝します。「コピーすると常に作業が簡単になり、間違いが起こりにくくなります。」- [RFC8411]
Jeff Andersen
Google
Bruno Couillard
Crypto4A Technologies
Stefan-Lukas Gazdag
genua GmbH
Thom Wiggers
PQShield
Netherlands
Email: thom@thomwiggers.nl
Kaveh Bashiri
BSI
Germany
Email: kaveh.bashiri.ietf@gmail.com
Stefan Kölbl
Google
Switzerland
Email: kste@google.com
Jim Goodman
Crypto4A Technologies
Canada
Email: jimg@crypto4a.com
Stavros Kousidis
BSI
Germany
Email: kousidis.ietf@gmail.com