[要約] RFC 9124は、IoTデバイスのファームウェア更新のための情報モデルを定義します。この標準は、安全かつ効率的な更新プロセスを実現することを目的としています。利用場面は、さまざまなIoTデバイスにおけるファームウェアの配布と更新に関わるシナリオです。
Internet Engineering Task Force (IETF) B. Moran
Request for Comments: 9124 H. Tschofenig
Category: Informational Arm Limited
ISSN: 2070-1721 H. Birkholz
Fraunhofer SIT
January 2022
A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices
物事のインターネット（IoT）装置におけるファームウェアアップデートのためのマニフェスト情報モデル
Abstract
概要
Vulnerabilities with Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism that is also suitable for constrained devices. Ensuring that devices function and remain secure over their service lifetime requires such an update mechanism to fix vulnerabilities, update configuration settings, and add new functionality.
物事のインターネット（IoT）デバイスのインターネットによる脆弱性は、制約付きデバイスにも適している信頼性の高い安全なファームウェアアップデートメカニズムの必要性を高めました。デバイスが機能寿命を介して機能を介してセキュリティを維持することで、このような更新メカニズムは、脆弱性を修正し、構成設定を更新し、新しい機能を追加するための更新メカニズムを必要とします。
One component of such a firmware update is a concise and machine-processable metadata document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest.
そのようなファームウェアアップデートの1つのコンポーネントは、簡潔でマシンプロセス可能なメタデータ文書、またはファームウェアイメージを記述し、適切な保護を提供するマニフェストです。この文書では、マニフェストに存在しなければならない情報について説明します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。それは情報提供のために公開されています。
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.
この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc9124.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9124で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
2. Requirements and Terminology
2.1. Requirements Notation
2.2. Terminology
3. Manifest Information Elements
3.1. Version ID of the Manifest Structure
3.2. Monotonic Sequence Number
3.3. Vendor ID
3.4. Class ID
3.4.1. Example 1: Different Classes
3.4.2. Example 2: Upgrading Class ID
3.4.3. Example 3: Shared Functionality
3.4.4. Example 4: Rebranding
3.5. Precursor Image Digest Condition
3.6. Required Image Version List
3.7. Expiration Time
3.8. Payload Format
3.9. Processing Steps
3.10. Storage Location
3.10.1. Example 1: Two Storage Locations
3.10.2. Example 2: Filesystem
3.10.3. Example 3: Flash Memory
3.11. Component Identifier
3.12. Payload Indicator
3.13. Payload Digests
3.14. Size
3.15. Manifest Envelope Element: Signature
3.16. Additional Installation Instructions
3.17. Manifest Text Information
3.18. Aliases
3.19. Dependencies
3.20. Encryption Wrapper
3.21. XIP Address
3.22. Load-Time Metadata
3.23. Runtime Metadata
3.24. Payload
3.25. Manifest Envelope Element: Delegation Chain
4. Security Considerations
4.1. Threat Model
4.2. Threat Descriptions
4.2.1. THREAT.IMG.EXPIRED: Old Firmware
4.2.2. THREAT.IMG.EXPIRED.OFFLINE: Offline Device + Old
Firmware
4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware
4.2.4. THREAT.IMG.FORMAT: The Target Device Misinterprets the
Type of Payload
4.2.5. THREAT.IMG.LOCATION: The Target Device Installs the
Payload to the Wrong Location
4.2.6. THREAT.NET.REDIRECT: Redirection to Inauthentic Payload
Hosting
4.2.7. THREAT.NET.ONPATH: Traffic Interception
4.2.8. THREAT.IMG.REPLACE: Payload Replacement
4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images
4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor Images
4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware
4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering of Firmware
Image for Vulnerability Analysis
4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest
Elements
4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element
Exposure
4.2.15. THREAT.IMG.EXTRA: Extra Data after Image
4.2.16. THREAT.KEY.EXPOSURE: Exposure of Signing Keys
4.2.17. THREAT.MFST.MODIFICATION: Modification of Manifest or
Payload prior to Signing
4.2.18. THREAT.MFST.TOCTOU: Modification of Manifest between
Authentication and Use
4.3. Security Requirements
4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers
4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-Type Identifiers
4.3.3. REQ.SEC.EXP: Expiration Time
4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity
4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type
4.3.6. REQ.SEC.AUTH.IMG_LOC: Authenticated Storage Location
4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload
4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution
4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated Precursor Images
4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and
Class IDs
4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity
4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption
4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control
4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests
4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest
4.3.16. REQ.SEC.REPORTING: Secure Reporting
4.3.17. REQ.SEC.KEY.PROTECTION: Protected Storage of Signing
Keys
4.3.18. REQ.SEC.KEY.ROTATION: Protected Storage of Signing Keys
4.3.19. REQ.SEC.MFST.CHECK: Validate Manifests prior to
Deployment
4.3.20. REQ.SEC.MFST.TRUSTED: Construct Manifests in a Trusted
Environment
4.3.21. REQ.SEC.MFST.CONST: Manifest Kept Immutable between
Check and Use
4.4. User Stories
4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation
Instructions
4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early
4.4.3. USER_STORY.OVERRIDE: Override Non-critical Manifest
Elements
4.4.4. USER_STORY.COMPONENT: Component Update
4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations
4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats
4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential
Information Disclosures
4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from
Unpacking Unknown Formats
4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers
of Target Firmware
4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose between
Images
4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests
4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load
4.4.13. USER_STORY.MFST.IMG: Payload in Manifest
4.4.14. USER_STORY.MFST.PARSE: Simple Parsing
4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in
Manifest
4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation
4.4.17. USER_STORY.MFST.ADMINISTRATION: Administration of
Manifests
4.5. Usability Requirements
4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-installation Checks
4.5.2. REQ.USE.MFST.TEXT: Descriptive Manifest Information
4.5.3. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource
Location
4.5.4. REQ.USE.MFST.COMPONENT: Component Updates
4.5.5. REQ.USE.MFST.MULTI_AUTH: Multiple Authentications
4.5.6. REQ.USE.IMG.FORMAT: Format Usability
4.5.7. REQ.USE.IMG.NESTED: Nested Formats
4.5.8. REQ.USE.IMG.VERSIONS: Target Version Matching
4.5.9. REQ.USE.IMG.SELECT: Select Image by Destination
4.5.10. REQ.USE.EXEC: Executable Manifest
4.5.11. REQ.USE.LOAD: Load-Time Information
4.5.12. REQ.USE.PAYLOAD: Payload in Manifest Envelope
4.5.13. REQ.USE.PARSE: Simple Parsing
4.5.14. REQ.USE.DELEGATION: Delegation of Authority in Manifest
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Authors' Addresses
Vulnerabilities with Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism that is also suitable for constrained devices. Ensuring that devices function and remain secure over their service lifetime requires such an update mechanism to fix vulnerabilities, update configuration settings, and add new functionality.
物事のインターネット（IoT）デバイスのインターネットによる脆弱性は、制約付きデバイスにも適している信頼性の高い安全なファームウェアアップデートメカニズムの必要性を高めました。デバイスが機能寿命を介して機能を介してセキュリティを維持することで、このような更新メカニズムは、脆弱性を修正し、構成設定を更新し、新しい機能を追加するための更新メカニズムを必要とします。
One component of such a firmware update is a concise and machine-processable metadata document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest.
そのようなファームウェアアップデートの1つのコンポーネントは、簡潔でマシンプロセス可能なメタデータ文書、またはファームウェアイメージを記述し、適切な保護を提供するマニフェストです。この文書では、マニフェストに存在しなければならない情報について説明します。
This document describes all the information elements required in a manifest to secure firmware updates of IoT devices. Each information element is motivated by user stories and threats it aims to mitigate. These threats and user stories are not intended to be an exhaustive list of the threats against IoT devices and possible user stories that describe how to conduct a firmware update. Instead, they are intended to describe the threats against firmware updates in isolation and provide sufficient motivation to specify the information elements that cover a wide range of user stories.
このドキュメントでは、IOTデバイスのファームウェアアップデートを保護するためにマニフェストに必要なすべての情報要素について説明します。各情報要素は、軽減することを目的としたユーザーストーリーと脅威によって動機付けられています。これらの脅威とユーザーストーリーは、IOTデバイスに対する徹底的なリストとファームウェアのアップデートの実行方法を説明する可能性のあるユーザーストーリーの徹底的なリストであることを意図していません。代わりに、それらは、隔離のファームウェアアップデートに対する脅威を説明し、広範囲のユーザーストーリーをカバーする情報要素を指定するのに十分な動機を提供することを目的としています。
To distinguish information elements from their encoding and serialization over the wire, this document presents an information model. RFC 3444 [RFC3444] describes the differences between information models and data models.
情報要素をそれらの符号化および直列化から区別するために、この文書は情報モデルを提示する。RFC 3444 [RFC3444]は、情報モデルとデータモデルの違いを説明しています。
Because this document covers a wide range of user stories and a wide range of threats, not all information elements apply to all scenarios. As a result, various information elements are optional to implement and optional to use, depending on which threats exist in a particular domain of application and which user stories are important for deployments.
このドキュメントは幅広いユーザーストーリーと幅広い脅威をカバーしているため、すべての情報要素がすべてのシナリオに適用されるわけではありません。その結果、特定のアプリケーションの特定のドメインに存在し、どのユーザーストーリーが展開にとって重要であるかによって、さまざまな情報要素が実装およびオプションであるためです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Unless otherwise stated, these words apply to the design of the manifest format, not its implementation or application. Hence, whenever an information element is declared as "REQUIRED", this implies that the manifest format document has to include support for it.
特に明記しない限り、これらの単語はその実装またはアプリケーションではなく、マニフェストフォーマットの設計に適用されます。したがって、情報要素が「必須」として宣言されるたびに、これはマニフェストフォーマット文書がそれに対するサポートを含める必要があることを意味します。
This document uses terms defined in [RFC9019]. The term "Operator" refers to either a device operator or a network operator.
この文書は[RFC9019]で定義されている用語を使用しています。「演算子」という用語は、装置演算子またはネットワーク事業者のいずれかを指す。
"Secure time" and "secure clock" refer to a set of requirements on time sources. For local time sources, this primarily means that the clock must be monotonically increasing, including across power cycles, firmware updates, etc. For remote time sources, the provided time must be both authenticated and guaranteed to be correct to within some predetermined bounds, whenever the time source is accessible.
「セキュアタイム」と「セキュアクロック」は、時間源の一連の要件を参照してください。現地のタイムソースの場合、これは主に、電源サイクル、ファームウェアの更新などを含むクロックが単調に増加しなければならないことを意味します。時間源にアクセス可能です。
The term "Envelope" (or "Manifest Envelope") is used to describe an encoding that allows the bundling of a manifest with related information elements that are not directly contained within the manifest.
「エンベロープ」（または「マニフェストエンベロープ」）という用語は、マニフェスト内に直接含まれていない関連情報要素を有するマニフェストのバンドリングを可能にする符号化を説明するために使用される。
The term "payload" is used to describe the data that is delivered to a device during an update. This is distinct from a "firmware image", as described in [RFC9019], because the payload is often in an intermediate state, such as being encrypted, compressed, and/or encoded as a differential update. The payload, taken in isolation, is often not the final firmware image.
「ペイロード」という用語は、更新中にデバイスに配信されるデータを記述するために使用されます。ペイロードは、差分更新として暗号化、圧縮、および/または符号化されているなどの中間状態であることが多いので、[RFC9019]で説明されているように、これは「ファームウェアイメージ」とは異なります。絶縁で撮影されたペイロードは、最終ファームウェアイメージではありません。
Each manifest information element is anchored in a security requirement or a usability requirement. The manifest elements are described below, justified by their requirements.
各マニフェスト情報要素は、セキュリティ要件またはユーザビリティ要件に固定されています。マニフェスト要素は以下に説明され、それらの要件によって正当化されています。
This is an identifier that describes which iteration of the manifest format is contained in the structure. This allows devices to identify the version of the manifest data model that is in use.
これは、マニフェストフォーマットのどの反復が構造体に含まれるかを説明する識別子です。これにより、デバイスは使用中のマニフェストデータモデルのバージョンを識別できます。
This element is REQUIRED.
この要素が必要です。
This element provides a monotonically increasing (unsigned) sequence number to prevent malicious actors from reverting a firmware update against the policies of the relevant authority. This number must not wrap around.
この要素は、悪意のあるアクターが関連当局のポリシーに対してファームウェアアップデートを復帰させるのを防ぐために、単調に増加する（符号なし）シーケンス番号を提供します。この数は折り返してはいけません。
For convenience, the monotonic sequence number may be a UTC timestamp. This allows global synchronization of sequence numbers without any additional management.
便宜上、単調シーケンス番号はUTCタイムスタンプであり得る。これにより、追加の管理なしでシーケンス番号のグローバル同期が可能になります。
This element is REQUIRED.
この要素が必要です。
Implements: REQ.SEC.SEQUENCE (Section 4.3.1)
実装：req.sec.sequence（セクション4.3.1）
The Vendor ID element helps to distinguish between identically named products from different vendors. The Vendor ID is not intended to be a human-readable element. It is intended for binary match/mismatch comparison only.
ベンダーID要素は、異なるベンダーからの任意の名前の製品を区別するのに役立ちます。ベンダーIDは人間が読める要素であることを意図していません。それはバイナリマッチ/ミスマッチ比較のみを目的としています。
Recommended practice is to use version 5 Universally Unique Identifiers (UUIDs) [RFC4122] with the vendor's domain name and the DNS name space ID. Other options include type 1 and type 4 UUIDs.
推奨される慣例は、ベンダーのドメイン名とDNSネームスペースIDを使用して、Version 5 Universally Universive Univery Identifiers（UUID）[RFC4122]を使用することです。その他のオプションには、タイプ1と4つのUUIDがあります。
Fixed-size binary identifiers are preferred because they are simple to match, unambiguous in length, explicitly non-parsable, and require no issuing authority. Guaranteed unique integers are preferred because they are small and simple to match; however, they may not be fixed length, and they may require an issuing authority to ensure uniqueness. Free-form text is avoided because it is variable length, prone to error, and often requires parsing outside the scope of the manifest serialization.
固定サイズのバイナリ識別子は、それらが一致するのが簡単で、長さが明確に、明確に、明確に解析不可、そして発行権限を必要としないため、優先されます。保証されたユニークな整数は、それらが小さくて一致するのが簡単であるため好ましいです。しかしながら、それらは固定されていないかもしれないが、それらは一意性を確保するために発行権限を必要とするかもしれない。フリーフォームテキストは可変長であるため、エラーが発生しやすく、マニフェストシリアル化の範囲外の解析を必要とするため、回避されます。
If human-readable content is required, it SHOULD be contained in a separate manifest information element: Manifest Text Information (Section 3.17).
人間が読めるコンテンツが必要な場合は、個別のマニフェスト情報要素に含まれている必要があります。マニフェストテキスト情報（セクション3.17）。
This element is RECOMMENDED.
この要素をお勧めします。
Implements: REQ.SEC.COMPATIBLE (Section 4.3.2), REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10)
実装：req.sec.compatible（セクション4.3.2）、req.sec.auth.compatibility（セクション4.3.10）
Here is an example for a domain-name-based UUID. Vendor A creates a UUID based on a domain name it controls, such as vendorId = UUID5(DNS, "vendor-a.example").
ドメイン名ベースのUUIDの例は次のとおりです。Vendor Aは、Vendorid = UUID5（DNS、 "Vendor-A.example"）などのドメイン名に基づいてUUIDを作成します。
Because the DNS infrastructure prevents multiple registrations of the same domain name, this UUID is (with very high probability) guaranteed to be unique. Because the domain name is known, this UUID is reproducible. Type 1 and type 4 UUIDs produce similar guarantees of uniqueness, but not reproducibility.
DNSインフラストラクチャは同じドメイン名の複数の登録を妨げるので、このUUIDは（非常に高い確率で）固有であることが保証されています。ドメイン名は既知であるため、このUUIDは再現可能です。タイプ1とタイプ4のUUIDは、同様の一意性の保証を生み出しますが、再現性はありません。
This approach creates a contention when a vendor changes its name or relinquishes control of a domain name. In this scenario, it is possible that another vendor would start using that same domain name. However, this UUID is not proof of identity; a device's trust in a vendor must be anchored in a cryptographic key, not a UUID.
このアプローチは、ベンダーがその名前を変更するか、ドメイン名の制御をリリースするときに競合を作成します。このシナリオでは、別のベンダーがその同じドメイン名を使用し始める可能性があります。しかし、このUUIDはアイデンティティの証明ではありません。ベンダーへのデバイスの信頼は、UUIDではなく暗号鍵に固定されなければなりません。
A device "Class" is a set of different device types that can accept the same firmware update without modification. It thereby allows devices to determine the applicability of the firmware in an unambiguous way. Class IDs must be unique within the scope of a Vendor ID. This is to prevent similarly or identically named devices from colliding in their customer's infrastructure.
デバイス「クラス」は、変更なしで同じファームウェアアップデートを受け入れることができるさまざまなデバイスタイプのセットです。それによってそれによって、デバイスは、ファームウェアの適用性を明確な方法で決定することを可能にする。クラスIDは、ベンダーIDの範囲内で一意である必要があります。これは、デバイスが顧客のインフラストラクチャに衝突しないように、同様にまたは同じように指名されたという名前を防ぐことです。
Recommended practice is to use version 5 UUIDs [RFC4122] with as much information as necessary to define firmware compatibility. Possible information used to derive the Class ID UUID includes:
推奨される慣例は、ファームウェアの互換性を定義するために必要なのと同じくらい多くの情報でバージョン5 UUID [RFC4122]を使用することです。クラスID UUIDを導出するために使用される可能な情報は次のとおりです。
* Model name or number
* モデル名または番号
* Hardware revision
* ハードウェアリビジョン
* Runtime library version
* ランタイムライブラリのバージョン
* Bootloader version
* ブートローダのバージョン
* ROM revision
* ROMリビジョン
* Silicon batch number
* シリコンバッチ番号
The Class ID UUID should use the Vendor ID as the name space identifier. Classes may be more fine-grained than is required to identify firmware compatibility. Classes must not be less granular than is required to identify firmware compatibility. Devices may have multiple Class IDs.
クラスID UUIDは、ベンダーIDを名前空間識別子として使用する必要があります。クラスは、ファームウェアの互換性を識別するために必要な場合よりも微細に粒子を付けます。ファームウェアの互換性を識別するために必要な場合は、クラスは粒状ではない必要がありません。デバイスは複数のクラスIDを持つことができます。
The Class ID is not intended to be a human-readable element. It is intended for binary match/mismatch comparison only. A manifest serialization SHOULD NOT permit free-form text content to be used for the Class ID. A fixed-size binary identifier SHOULD be used.
クラスIDは、人間が読める要素となることを意図していません。それはバイナリマッチ/ミスマッチ比較のみを目的としています。マニフェストシリアル化は、クラスIDにフリーフォームテキストコンテンツを使用することを許可しないでください。固定サイズのバイナリ識別子を使用する必要があります。
Some organizations desire to keep the same product naming across multiple, incompatible hardware revisions for ease of user experience. If this naming is propagated into the firmware, then matching a specific hardware version becomes a challenge. An opaque, non-readable binary identifier has no naming implications and so is more likely to be usable for distinguishing among incompatible device groupings, regardless of naming.
いくつかの組織は、ユーザーエクスペリエンスを容易にするために、同じ製品ネーミングを複数の互換性のないハードウェアリビジョンにわたって同じ製品の名前を維持したいと考えています。この命名がファームウェアに伝播されている場合は、特定のハードウェアバージョンと一致することが課題になります。不透明で不可読なバイナリ識別子は命名されていないため、命名に関係なく、互換性のないデバイスグループ間で区別するために使用できる可能性が高いです。
Fixed-size binary identifiers are preferred because they are simple to match, unambiguous in length, opaque and free from naming implications, and explicitly non-parsable. Free-form text is avoided because it is variable length, prone to error, often requires parsing outside the scope of the manifest serialization, and may be homogenized across incompatible device groupings.
固定サイズのバイナリ識別子は、それらが一致するのが簡単で、明確な長さ、不透明、および命名の影響を解消し、明示的には解析できないため、優れています。自由形式のテキストは可変の長さであるため、エラーが発生しやすいため、マニフェストシリアル化の範囲外の解析を必要とするため、互換性のないデバイスグループ間でホモジナイズすることができます。
If the Class ID is not implemented, then each logical device class must use a unique trust anchor for authorization.
クラスIDが実装されていない場合、各論理デバイスクラスは許可のために一意の信頼アンカーを使用する必要があります。
This element is RECOMMENDED.
この要素をお勧めします。
Implements: REQ.SEC.COMPATIBLE (Section 4.3.2), REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10)
実装：req.sec.compatible（セクション4.3.2）、req.sec.auth.compatibility（セクション4.3.10）
Vendor A creates Product Z and Product Y. The firmware images of Products Z and Y are not interchangeable. Vendor A creates UUIDs as follows:
ベンダーAは製品Zと製品Yを作成します。製品ZとYのファームウェアイメージは交換可能ではありません。ベンダーAは次のようにUUIDを作成します。
* vendorId = UUID5(DNS, "vendor-a.example")
* Vendorid = UUID5（DNS、 "Vendor-A.example"）
* ZclassId = UUID5(vendorId, "Product Z")
* zclassid = UUID5（Vendorid、 "製品Z"）
* YclassId = UUID5(vendorId, "Product Y")
* yclassid = uuid5（Vendorid、 "製品y"）
This ensures that Vendor A's Product Z cannot install firmware for Product Y and Product Y cannot install firmware for Product Z.
これにより、ベンダーAの製品Zが製品Yのファームウェアをインストールできないことが保証され、製品Yは製品Zのファームウェアをインストールできません。
Vendor A creates Product X. Later, Vendor A adds a new feature to Product X, creating Product X v2. Product X requires a firmware update to work with firmware intended for Product X v2.
Vendor Aは製品Xを作成します。後で、ベンダーAは製品Xに新しい機能を追加し、製品X V2を作成します。Product Xには、製品X V2用のファームウェアを操作するためのファームウェアアップデートが必要です。
Vendor A creates UUIDs as follows:
ベンダーAは次のようにUUIDを作成します。
* vendorId = UUID5(DNS, "vendor-a.example")
* Vendorid = UUID5（DNS、 "Vendor-A.example"）
* XclassId = UUID5(vendorId, "Product X")
* Xclassid = UUID5（Vendorid、 "製品X"）
* Xv2classId = UUID5(vendorId, "Product X v2")
* XV2ClassID = UUID5（Vendorid、製品X V2 "）
When Product X receives the firmware update necessary to be compatible with Product X v2, part of the firmware update changes the Class ID to Xv2classId.
製品Xが製品X V2と互換性があるために必要なファームウェアアップデートを受信すると、ファームウェアアップデートの一部はクラスIDをXv2ClassIDに変更します。
Vendor A produces two products: Product X and Product Y. These components share a common core (such as an operating system (OS)) but have different applications. The common core and the applications can be updated independently. To enable X and Y to receive the same common core update, they require the same Class ID. To ensure that only Product X receives Application X and only Product Y receives Application Y, Product X and Product Y must have different Class IDs. The vendor creates Class IDs as follows:
Vendor Aは2つの製品を製造しています。製品Xと製品Y.これらのコンポーネントは共通のコア（オペレーティングシステム（OS）など）を共有していますが、アプリケーションが異なります。共通のコアとアプリケーションは独立して更新できます。XとYを同じ共通コアアップデートを受信できるようにするには、同じクラスIDが必要です。製品XだけがアプリケーションXを受信し、製品YだけがアプリケーションYを受信し、製品Xと製品Yは異なるクラスIDを持つ必要があります。ベンダーは次のようにクラスIDを作成します。
* vendorId = UUID5(DNS, "vendor-a.example")
* Vendorid = UUID5（DNS、 "Vendor-A.example"）
* XclassId = UUID5(vendorId, "Product X")
* Xclassid = UUID5（Vendorid、 "製品X"）
* YclassId = UUID5(vendorId, "Product Y")
* yclassid = uuid5（Vendorid、 "製品y"）
* CommonClassId = UUID5(vendorId, "common core")
* CommonClassid = UUID5（Vendorid、 "Common Core"）
Product X matches against both XclassId and CommonClassId. Product Y matches against both YclassId and CommonClassId.
Product XはXclassidとCommonclassidの両方に対して一致します。製品YはYclassidとCommonclassidの両方に対して一致します。
Vendor A creates a Product A and its firmware. Vendor B sells the product under its own name as Product B with some customized configuration. The vendors create the Class IDs as follows:
ベンダーAは製品Aとそのファームウェアを作成します。ベンダーBは、いくつかのカスタマイズされた構成を備えた製品Bとして、製品Bの下で製品を販売しています。ベンダーは次のようにクラスIDを作成します。
* vendorIdA = UUID5(DNS, "vendor-a.example")
* Vendorida = UUID5（DNS、 "Vendor-A.example"）
* classIdA = UUID5(vendorIdA, "Product A-Unlabeled")
* Classida = UUID5（Vendorida、製品A-標識 "）
* vendorIdB = UUID5(DNS, "vendor-b.example")
* VENDORIDB = UUID5（DNS、 "Vendor-B.example"）
* classIdB = UUID5(vendorIdB, "Product B")
* ClassIDB = UUID5（VendoridB、製品B "）
The product will match against each of these Class IDs. If Vendor A and Vendor B provide different components for the device, the implementor may choose to make ID matching scoped to each component. Then, the vendorIdA, classIdA match the component ID supplied by Vendor A, and the vendorIdB, classIdB match the component ID supplied by Vendor B.
製品はこれらのクラスIDのそれぞれと一致します。ベンダーAとベンダーBがデバイスに異なるコンポーネントを提供する場合、実装者はIDが各コンポーネントにスコープされたIDを作成することを選択できます。その後、ヴェンドリダ、ClassidaがベンダーAによって提供されたコンポーネントIDと一致し、vendoridb、ClassIDBはベンダーBによって提供されたコンポーネントIDと一致します。
This element provides information about the payload that needs to be present on the device for an update to apply. This may, for example, be the case with differential updates.
この要素は、適用されるアップデートのためにデバイス上に存在する必要があるペイロードに関する情報を提供します。これは、例えば、差動更新の場合であり得る。
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9)
実装：req.sec.auth.precursor（セクション4.3.9）
Payloads may only be applied to a specific firmware version or multiple firmware versions. For example, a payload containing a differential update may be applied only to a specific firmware version.
ペイロードは、特定のファームウェアバージョンまたは複数のファームウェアバージョンにのみ適用できます。たとえば、差動更新を含むペイロードは、特定のファームウェアバージョンにのみ適用できます。
When a payload applies to multiple versions of firmware, the required image version list specifies which firmware versions must be present for the update to be applied. This allows the update author to target specific versions of firmware for an update, while excluding those to which it should not or cannot be applied.
ペイロードが複数のバージョンのファームウェアに適用される場合、必要なイメージバージョンリストは、更新を適用するためにどのファームウェアバージョンを存在させる必要があるかを指定します。これにより、アップデート作成者は、適用されていないものを除いて、更新のためのファームウェアの特定のバージョンをターゲットにすることができます。
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.USE.IMG.VERSIONS (Section 4.5.8)
実装：req.use.img.versions（セクション4.5.8）
This element tells a device the time at which the manifest expires and should no longer be used. This element should be used where a secure source of time is provided and firmware is intended to expire predictably. This element may also be displayed (e.g., via an app) for user confirmation, since users typically have a reliable knowledge of the date.
この要素は、マニフェストが有効期限が切れて使用されなくなるまでの時間をデバイスに指示します。この要素は、安全な時間源が提供され、ファームウェアが予測可能に期限切れになることを意図している場合に使用する必要があります。ユーザは通常日付の信頼できる知識を有するので、この要素はユーザ確認のために（例えばアプリを介して）表示されてもよい。
Special consideration is required for end-of-life if firmware will not be updated again -- for example, if a business stops issuing updates to a device. In this case, the last valid firmware should not have an expiration time.
ファームウェアが再び更新されない場合は、寿命の終わりに特別な配慮が必要です。たとえば、ビジネスがデバイスへの更新の発行を停止している場合。この場合、最後の有効なファームウェアは有効期限を持つべきではありません。
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.SEC.EXP (Section 4.3.3)
実装：req.sec.exp（セクション4.3.3）
This element describes the payload format within the signed metadata. It is used to enable devices to decode payloads correctly.
この要素は、署名付きメタデータ内のペイロード形式を記述します。デバイスがペイロードを正しくデコードできるようにするために使用されます。
This element is REQUIRED.
この要素が必要です。
Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT (Section 4.5.6)
実装：req.sec.auth.img_type（セクション4.3.5）、req.use.img.format（セクション4.5.6）
This element provides a representation of the processing steps required to decode a payload -- in particular, those that are compressed, packed, or encrypted. The representation must describe which algorithms are used and must convey any additional parameters required by those algorithms.
この要素は、ペイロードを復号するために必要な処理ステップを、特に圧縮、梱包、または暗号化されているものの表現を提供する。表現はどのアルゴリズムが使用されているかを説明しなければならず、それらのアルゴリズムによって必要とされる追加のパラメータを伝える必要があります。
A processing step may indicate the expected digest of the payload after the processing is complete.
処理ステップは、処理が完了した後にペイロードの予想されるダイジェストを示すことができる。
This element is RECOMMENDED.
この要素をお勧めします。
Implements: REQ.USE.IMG.NESTED (Section 4.5.7)
実装：req.use.img.nested（セクション4.5.7）
This element tells the device where to store a payload within a given component. The device can use this to establish which permissions are necessary and the physical storage location to use.
この要素は、与えられたコンポーネント内にペイロードを保存する場所をデバイスに指示します。このデバイスはこれを使用して、どの権限が必要か、および使用する物理保存場所を確立することができます。
This element is REQUIRED.
この要素が必要です。
Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6)
実装：req.sec.auth.img_loc（セクション4.3.6）
A device supports two components: an OS and an application. These components can be updated independently, expressing dependencies to ensure compatibility between the components. The author chooses two storage identifiers:
デバイスは、OSとアプリケーションの2つのコンポーネントをサポートします。これらのコンポーネントは、コンポーネント間の互換性を保証するために依存関係を表現するように独立して更新できます。著者は2つのストレージ識別子を選択します。
* "OS"
* "OS"
* "APP"
* "アプリ"
A device supports a full-featured filesystem. The author chooses to use the storage identifier as the path at which to install the payload. The payload may be a tarball, in which case it unpacks the tarball into the specified path.
デバイスはフル機能のファイルシステムをサポートしています。作者は、ペイロードをインストールするパスとしてストレージIDを使用することを選択します。ペイロードはtarballでもかまいません。その場合、それは指定されたパスにtarballを解凍します。
A device supports flash memory. The author chooses to make the storage identifier the offset where the image should be written.
デバイスはフラッシュメモリをサポートしています。著者は、記憶識別子をオフセットにすることを選択して、画像が書き込まれるべきである。
In a device with more than one storage subsystem, a storage identifier is insufficient to identify where and how to store a payload. To resolve this, a component identifier indicates to which part of the storage subsystem the payload shall be placed.
複数のストレージサブシステムを持つデバイスでは、レポートの保存方法とどのようにペイロードの保存方法を識別するには、ストレージ識別子が不十分です。これを解決するために、コンポーネント識別子は、保管サブシステムのどの部分をペイロードに配置するかを示します。
A serialization may choose to combine the use of a component identifier and storage location (Section 3.10).
シリアル化は、コンポーネント識別子と保管場所の使用を組み合わせることを選択できます（セクション3.10）。
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.USE.MFST.COMPONENT (Section 4.5.4)
実装：req.use.mfst.component（セクション4.5.4）
This element provides the information required for the device to acquire the payload. This functionality is only needed when the target device does not intrinsically know where to find the payload.
この要素は、デバイスがペイロードを取得するために必要な情報を提供します。この機能は、ターゲットデバイスがペイロードのどこにあるかを本質的に知らない場合にのみ必要です。
This can be encoded in several ways:
これはいくつかの方法でエンコードできます。
* One URI
* one u
* A list of URIs
* URIのリスト
* A prioritized list of URIs
* URIの優先リスト
* A list of signed URIs
* 署名されたURIのリスト
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7)
実装：req.sec.auth.remote_loc（セクション4.3.7）
This element contains one or more digests of one or more payloads. This allows the target device to ensure authenticity of the payload(s) when combined with the Signature (Section 3.15) element. A manifest format must provide a mechanism to select one payload from a list based on system parameters, such as an execute-in-place (XIP) installation address.
この要素には、1つ以上のペイロードの1つ以上のダイジェストが含まれています。これにより、ターゲットデバイスは、シグネチャ（セクション3.15）要素と組み合わせるとペイロードの真正性を確保できます。マニフェストフォーマットは、実行インプレース（XIP）インストールアドレスなど、システムパラメータに基づいて1つのペイロードを選択するメカニズムを提供する必要があります。
This element is REQUIRED. Support for more than one digest is OPTIONAL.
この要素が必要です。複数のダイジェストのサポートはオプションです。
Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT (Section 4.5.9)
実装：req.sec.authentic（セクション4.3.4）、req.use.img.Select（セクション4.5.9）
This element provides the size of the payload in bytes, which informs the target device how big of a payload to expect. Without it, devices are exposed to some classes of denial-of-service attacks.
この要素は、ペイロードのサイズをバイト単位で提供します。これは、ペイロードの大きさの大きさの大きさをターゲットデバイスに通知します。それがなければ、デバイスはいくつかのクラスのサービス拒否攻撃にさらされています。
This element is REQUIRED.
この要素が必要です。
Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8)
実装：req.sec.auth.exec（セクション4.3.8）
The signature element contains all the information necessary to protect the contents of the manifest against modification and to offer authentication of the signer. Because the signature element authenticates the manifest, it cannot be contained within the manifest. Instead, either the manifest is contained within the signature element or the signature element is a member of the Manifest Envelope and bundled with the manifest.
署名要素には、マニフェストの内容を変更から保護し、署名者の認証を提供するために必要なすべての情報が含まれています。署名要素はマニフェストを認証するので、マニフェスト内に含まれていません。代わりに、マニフェストのどちらかが署名要素内に含まれているか、署名要素はマニフェストエンベロープのメンバーであり、マニフェストにバンドルされています。
The signature element represents the foundation of all security properties of the manifest. Manifests, which are included as dependencies by other manifests, should include a signature so that the recipient can distinguish between different actors with different permissions.
署名要素は、マニフェストのすべてのセキュリティプロパティの基盤を表します。他のマニフェストによる依存関係として含まれているマニフェストは、受信者が異なる許可を持つ異なるアクターを区別できるように署名を含めるべきです。
The signature element must support multiple signers and multiple signing algorithms. A manifest format may allow multiple manifests to be covered by a single signature element.
署名要素は、複数の署名者と複数の署名アルゴリズムをサポートしている必要があります。マニフェストフォーマットでは、複数のマニフェストを単一の署名要素でカバーすることができます。
This element is REQUIRED in non-dependency manifests.
この要素は、非依存性マニフェストで必要です。
Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.5)
実装：req.sec.authentic（セクション4.3.4）、req.sec.rights（セクション4.3.11）、req.use.mfst.mutti_auth（セクション4.5.5）
Additional installation instructions are machine-readable commands the device should execute when processing the manifest. This information is distinct from the information necessary to process a payload. Additional installation instructions include information such as update timing (for example, install only on Sunday, at 0200), procedural considerations (for example, shut down the equipment under control before executing the update), and pre- and post-installation steps (for example, run a script). Other installation instructions could include requesting user confirmation before installing.
追加のインストール手順は、マニフェストを処理するときにデバイスが実行する必要があるマシン読み取り可能なコマンドです。この情報はペイロードの処理に必要な情報とは異なります。追加のインストール手順には、更新タイミング（日曜日の日曜日のみ、0200のインストール）、手続き上の考慮事項（更新後の制御中の機器のシャットダウン）、およびインストール前の手順などの情報が含まれます。例で、スクリプトを実行します。インストール前にユーザ確認を要求することを他のインストール手順に含めることができる。
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
実装：req.use.mfst.pre_check（セクション4.5.1）
This is textual information pertaining to the update described by the manifest. This information is for human consumption only. It MUST NOT be the basis of any decision made by the recipient.
これは、マニフェストによって記述された更新に関するテキスト情報です。この情報は人間の消費のみです。それは受取人によって行われた決定の基礎ではありません。
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.USE.MFST.TEXT (Section 4.5.2)
実装：req.use.mfst.text（セクション4.5.2）
Aliases provide a mechanism for a manifest to augment or replace URIs or URI lists defined by one or more of its dependencies.
エイリアスは、1つ以上の依存関係によって定義されたURIまたはURIリストを強化または置き換えるためのマニフェストのメカニズムを提供します。
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.3)
実装：req.use.mfst.override_remote（セクション4.5.3）
This is a list of other manifests that are required by the current manifest. Manifests are identified in an unambiguous way, such as a cryptographic digest.
これは、現在のマニフェストによって必要とされる他のマニフェストのリストです。マニフェストは、暗号ダイジェストなどの明白な方法で識別されます。
This element is REQUIRED to support deployments that include both multiple authorities and multiple payloads.
この要素は、複数の権限と複数のペイロードの両方を含む展開をサポートするために必要です。
Implements: REQ.USE.MFST.COMPONENT (Section 4.5.4)
実装：req.use.mfst.component（セクション4.5.4）
Encrypting firmware images requires symmetric content encryption keys. The encryption wrapper provides the information needed for a device to obtain or locate a key that it uses to decrypt the firmware.
ファームウェアイメージの暗号化には、対称コンテンツ暗号化キーが必要です。暗号化ラッパーは、ファームウェアを復号化するために使用するキーを取得または見つけるためにデバイスが必要とする情報を提供します。
This element is REQUIRED for encrypted payloads.
この要素は暗号化されたペイロードに必要です。
Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)
実装：req.sec.img.confiditiality（セクション4.3.12）
In order to support XIP systems with multiple possible base addresses, it is necessary to specify which address the payload is linked for.
複数の可能なベースアドレスを持つXIPシステムをサポートするためには、ペイロードがリンクされているアドレスを指定する必要があります。
For example, a microcontroller may have a simple bootloader that chooses one of two images to boot. That microcontroller then needs to choose one of two firmware images to install, based on which of its two images is older.
例えば、マイクロコントローラは、起動する2つの画像のうちの1つを選択する単純なブートローダを有することができる。その後、そのマイクロコントローラは、2つの画像が古いものに基づいて、インストールする2つのファームウェアイメージのうちの1つを選択する必要があります。
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.USE.IMG.SELECT (Section 4.5.9)
実装：req.use.img.Select（セクション4.5.9）
Load-time metadata provides the device with information that it needs in order to load one or more images. This metadata may include any of the following:
ロードタイムメタデータは、1つ以上の画像をロードするために必要な情報をデバイスに提供します。このメタデータには、次のいずれかが含まれます。
* The source (e.g., non-volatile storage)
* ソース（例えば、不揮発性貯蔵）
* The destination (e.g., an address in RAM)
* 宛先（例えばRAMのアドレス）
* Cryptographic information
* 暗号情報
* Decompression information
* 解凍情報
* Unpacking information
* 解凍情報
Typically, loading is done by copying an image from its permanent storage location into its active use location. The metadata allows operations such as decryption, decompression, and unpacking to be performed during that copy.
通常、ロードは画像をその永続的な保管場所からそのアクティブな使用場所にコピーすることによって行われます。メタデータは、そのコピー中に復号化、解凍、および解凍などの操作を可能にします。
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.USE.LOAD (Section 4.5.11)
実装：req.use.load（セクション4.5.11）
Runtime metadata provides the device with any extra information needed to boot the device. This may include the entry point of an XIP image or the kernel command line to boot a Linux image.
ランタイムメタデータは、デバイスの起動に必要な追加情報をデバイスに提供します。これには、Linuxイメージを起動するためのXIPイメージのエントリポイントまたはカーネルコマンドラインが含まれます。
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.USE.EXEC (Section 4.5.10)
実装：req.use.exec（セクション4.5.10）
The Payload element is contained within the manifest or Manifest Envelope and enables the manifest and payload to be delivered simultaneously. This is used for delivering small payloads, such as cryptographic keys or configuration data.
ペイロード要素は、マニフェストまたはマニフェストエンベロープ内に含まれており、マニフェストとペイロードを同時に配信できるようにします。これは、暗号化キーや構成データなどの小さなペイロードを配信するために使用されます。
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.USE.PAYLOAD (Section 4.5.12)
実装：req.use.payload（セクション4.5.12）
The delegation chain offers enhanced authorization functionality via authorization tokens, such as Concise Binary Object Representation (CBOR) Web Tokens [RFC8392] with Proof-of-Possession Key Semantics [RFC8747]. Each token itself is protected and does not require another layer of protection. Each authorization token typically includes a public key or a public key fingerprint; however, this is dependent on the tokens used. Each token MAY include additional metadata, such as key usage information. Because the delegation chain is needed to verify the signature, it must be placed in the Manifest Envelope, rather than the manifest.
代表団チェーンでは、Concize Binaryオブジェクト表現（CBOR）Webトークン[RFC8392]などの認可トークンを介して拡張認証機能を提供します[RFC8747]。各トークン自体は保護されており、別の保護層を必要としません。各承認トークンには通常、公開鍵または公開鍵の指紋が含まれています。ただし、これは使用されているトークンに依存します。各トークンは、キー使用状況情報などの追加のメタデータを含み得る。代表団チェーンは署名を検証するために必要なので、マニフェストではなくマニフェストエンベロープに配置する必要があります。
The first token in any delegation chain MUST be authenticated by the recipient's trust anchor. Each subsequent token MUST be authenticated using the previous token. This allows a recipient to discard each antecedent token after it has authenticated the subsequent token. The final token MUST enable authentication of the manifest. More than one delegation chain MAY be used if more than one signature is used. Note that no restriction is placed on the encoding order of these tokens; the order of elements is logical only.
委任チェーンの最初のトークンは、受信者の信託アンカーによって認証されなければなりません。後続の各トークンは、前のトークンを使用して認証されなければなりません。これにより、受信者は、後続のトークンを認証した後に各先行延期トークンを破棄することができます。最後のトークンはマニフェストの認証を可能にしなければなりません。複数の署名が使用されている場合、複数の委任チェーンを使用することができます。これらのトークンの符号化順序に制限がないことに注意してください。要素の順序は論理専用です。
This element is OPTIONAL.
この要素はオプションです。
Implements: REQ.USE.DELEGATION (Section 4.5.14), REQ.SEC.KEY.ROTATION (Section 4.3.18)
実装：req.use.delegation（セクション4.5.14）、req.sec.key.rotation（セクション4.3.18）
The following subsections describe the threat model, user stories, security requirements, and usability requirements. This section also provides the motivations for each of the manifest information elements.
次のサブセクションでは、脅威モデル、ユーザーストーリー、セキュリティ要件、および使いやすさの要件について説明します。このセクションでは、各マニフェスト情報要素の動機も提供します。
Note that it is worthwhile to recall that a firmware update is, by definition, remote code execution. Hence, if a device is configured to trust an entity to provide firmware, it trusts this entity to behave correctly. Many classes of attacks can be mitigated by verifying that a firmware update came from a trusted party and that no rollback is taking place. However, if the trusted entity has been compromised and distributes attacker-provided firmware to devices, then the possibilities for defense are limited.
ファームウェアのアップデートが定義、リモートコードの実行によってリコールされることを思い出す価値があります。したがって、デバイスがファームウェアを提供するためにエンティティを信頼するように構成されている場合は、このエンティティを正しく行動するように信頼します。ファームウェアのアップデートが信頼されたパーティーから来て、ロールバックが行われていないことを確認することで、多くのクラスの攻撃を軽減できます。ただし、信頼できるエンティティが攻撃者に提供されたファームウェアをデバイスに分配している場合、防御の可能性は制限されています。
The following subsections aim to provide information about the threats that were considered, the security requirements that are derived from those threats, and the fields that permit implementation of the security requirements. This model uses the Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege (STRIDE) approach [STRIDE]. Each threat is classified according to the following:
以下のサブセクションでは、考慮された脅威、それらの脅威から派生したセキュリティ要件、およびセキュリティ要件の実装を可能にするフィールドについての情報を提供することを目的としています。このモデルは、なりすまし、改ざん、否認、情報開示、サービス拒否、および特権の標高（ストライド]を使用しています。各脅威は次の点に従って分類されます。
* Spoofing identity
* スプーフィングアイデンティティ
* Tampering with data
* データを改ざんする
* Repudiation
* 否認
* Information disclosure
* 情報開示
* Denial of service
* サービス拒否
* Elevation of privilege
* 特権の上昇
This threat model only covers elements related to the transport of firmware updates. It explicitly does not cover threats outside of the transport of firmware updates. For example, threats to an IoT device due to physical access are out of scope.
この脅威モデルは、ファームウェアアップデートのトランスポートに関連する要素のみを表しています。それは明示的にファームウェアの更新の輸送の外で脅威をカバーしません。たとえば、物理的アクセスによるIoTデバイスへの脅威は範囲外です。
Many of the threats detailed in this section contain a "threat escalation" description. This explains how the described threat might fit together with other threats and produce a high-severity threat. This is important because some of the described threats may seem low severity but could be used with others to construct a high-severity compromise.
このセクションに詳述されている脅威の多くには、「脅威の昇格」の説明が含まれています。これは、記載されている脅威が他の脅威とどのように適合し、重大度の高い脅威を生み出すのかを説明しています。これは、記載されている脅威のいくつかが低い重症度が低く見えるかもしれないので、高重大度の妥協点を構築するために他の人と共に使用することができるので重要です。
Classification: Elevation of Privilege
分類：特権の上昇
An attacker sends an old, but valid, manifest with an old, but valid, firmware image to a device. If there is a known vulnerability in the provided firmware image, this may allow an attacker to exploit the vulnerability and gain control of the device.
攻撃者は、古いが有効なものを、古いが有効なファームウェアイメージをデバイスにマニフェストに送信します。提供されたファームウェアイメージに既知の脆弱性がある場合、これは攻撃者が装置の脆弱性および利得制御を利用することを可能にし得る。
Threat Escalation: If the attacker is able to exploit the known vulnerability, then this threat can be escalated to all types.
脅威のエスカレーション：攻撃者が既知の脆弱性を悪用できる場合、この脅威はすべての型にエスカレートできます。
Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1)
軽減された：req.sec.sequence（セクション4.3.1）
Classification: Elevation of Privilege
分類：特権の上昇
An attacker targets a device that has been offline for a long time and runs an old firmware version. The attacker sends an old, but valid, manifest to a device with an old, but valid, firmware image. The attacker-provided firmware is newer than the installed firmware but older than the most recently available firmware. If there is a known vulnerability in the provided firmware image, then this may allow an attacker to gain control of a device. Because the device has been offline for a long time, it is unaware of any new updates. As such, it will treat the old manifest as the most current.
攻撃者は、長時間オフラインになってきたデバイスをターゲットにし、古いファームウェアバージョンを実行します。攻撃者は古いが有効であるが、古いが有効なファームウェアイメージを持つデバイスにマニフェストを送信します。攻撃者に提供されたファームウェアは、インストールされているファームウェアよりも新しいが、最後に使用可能なファームウェアよりも古い。提供されたファームウェアイメージに既知の脆弱性がある場合、これは攻撃者が装置を制御することを可能にし得る。デバイスは長い間オフラインであるため、新しいアップデートが認められていません。そのように、それは古いマニフェストを最新のものとして扱います。
The exact mitigation for this threat depends on where the threat comes from. This requires careful consideration by the implementor. If the threat is from a network actor, including an on-path attacker, or an intruder into a management system, then a user confirmation can mitigate this attack, simply by displaying an expiration date and requesting confirmation. On the other hand, if the user is the attacker, then an online confirmation system (for example, a trusted timestamp server) can be used as a mitigation system.
この脅威のための正確な緩和は、脅威がどこから来たのかによって異なります。これには実装者による慎重な検討が必要です。脅威がオンパス攻撃者、または管理システムへの侵入者を含むネットワークアクターからのものである場合、有効期限を表示して確認を要求するだけで、ユーザーの確認はこの攻撃を軽減できます。一方、ユーザが攻撃者である場合は、オンライン確認システム（例えば、信頼できるタイムスタンプサーバ）を軽減システムとして使用することができる。
Threat Escalation: If the attacker is able to exploit the known vulnerability, then this threat can be escalated to all types.
脅威のエスカレーション：攻撃者が既知の脆弱性を悪用できる場合、この脅威はすべての型にエスカレートできます。
Mitigated by: REQ.SEC.EXP (Section 4.3.3), REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
繰り返した：req.sec.exp（セクション4.3.3）、req.use.mfst.pre_check（セクション4.5.1）
Classification: Denial of Service
分類：サービス拒否
An attacker sends a valid firmware image, for the wrong type of device, signed by an actor with firmware installation permission on both device types. The firmware is verified by the device positively because it is signed by an actor with the appropriate permission. This could have wide-ranging consequences. For devices that are similar, it could cause minor breakage or expose security vulnerabilities. For devices that are very different, it is likely to render devices inoperable.
攻撃者は、両方のデバイスタイプに対するファームウェアのインストール許可を持つアクターによって署名された間違ったタイプのデバイスのための有効なファームウェアイメージを送信します。ファームウェアは、適切な許可を得て俳優によって署名されているため、デバイスによって正確に検証されます。これは広範囲の結果を持つ可能性があります。類似したデバイスの場合は、軽微な破損またはセキュリティの脆弱性を露出させる可能性があります。非常に異なるデバイスの場合、デバイスが動作不能にする可能性があります。
Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2)
軽減された：req.sec.compatible（セクション4.3.2）
For example, suppose that two vendors -- Vendor A and Vendor B -- adopt the same trade name in different geographic regions, and they both make products with the same names, or product name matching is not used. This causes firmware from Vendor A to match devices from Vendor B.
たとえば、2つのベンダーAとベンダーBが異なる地理的地域で同じ商号を採用しているとします。また、両方とも同じ名前の製品、または製品名の一致は使用されません。これにより、ベンダーAからのファームウェアがベンダーBのデバイスを一致させます。
If the vendors are the firmware authorities, then devices from Vendor A will reject images signed by Vendor B, since they use different credentials. However, if both devices trust the same author, then devices from Vendor A could install firmware intended for devices from Vendor B.
ベンダーがファームウェア当局である場合、Vendor Aのデバイスは、異なる認証情報を使用するため、ベンダーBによって署名された画像を拒否します。ただし、両方のデバイスが同じ作成者を信頼している場合、ベンダーAのデバイスはベンダーBからのデバイスを対象としたファームウェアをインストールできます。
4.2.4. THREAT.IMG.FORMAT: The Target Device Misinterprets the Type of Payload
4.2.4. threat.img.format：ターゲットデバイスがペイロードの種類を誤解します
Classification: Denial of Service
分類：サービス拒否
If a device misinterprets the format of the firmware image, it may cause a device to install a firmware image incorrectly. An incorrectly installed firmware image would likely cause the device to stop functioning.
デバイスがファームウェアイメージのフォーマットを誤動損すると、デバイスがファームウェアイメージを誤ってインストールさせる可能性があります。ファームウェアイメージが誤ってインストールされていると、デバイスは機能を停止させる可能性があります。
Threat Escalation: An attacker that can cause a device to misinterpret the received firmware image may gain elevation of privilege and potentially expand this to all types of threats.
脅威のエスカレーション：デバイスが受信したファームウェアイメージを誤解除することができる攻撃者は特権の上昇を獲得し、これをあらゆる種類の脅威に潜在的に拡大する可能性があります。
Mitigated by: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5)
軽減された：req.sec.auth.img_type（セクション4.3.5）
4.2.5. THREAT.IMG.LOCATION: The Target Device Installs the Payload to the Wrong Location
4.2.5. threat.img.location：ターゲットデバイスはペイロードを間違った場所にインストールします
Classification: Denial of Service
分類：サービス拒否
If a device installs a firmware image to the wrong location on the device, then it is likely to break. For example, a firmware image installed as an application could cause a device and/or application to stop functioning.
デバイスがファームウェアイメージをデバイス上の間違った場所にインストールすると、破損する可能性があります。たとえば、アプリケーションとしてインストールされたファームウェアイメージは、デバイスやアプリケーションが機能を停止させる可能性があります。
Threat Escalation: An attacker that can cause a device to misinterpret the received code may gain elevation of privilege and potentially expand this to all types of threats.
脅威のエスカレーション：デバイスに受信したコードを誤って解釈する可能性がある攻撃者は特権の標高を獲得し、これをあらゆる種類の脅威に潜在的に拡大する可能性があります。
Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6)
軽減された：req.sec.auth.img_loc（セクション4.3.6）
Classification: Denial of Service
分類：サービス拒否
If a device is tricked into fetching a payload for an attacker-controlled site, the attacker may send corrupted payloads to devices.
デバイスが攻撃者管理サイトのペイロードを取得するためにトリックされている場合、攻撃者は破損したペイロードをデバイスに送信することができます。
Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7)
軽減された：req.sec.auth.remote_loc（セクション4.3.7）
Classification: Spoofing Identity, Tampering with Data
分類：スプーフィングアイデンティティ、データを改ざんする
An attacker intercepts all traffic to and from a device. The attacker can monitor or modify any data sent to or received from the device. This can take the form of manifests, payloads, status reports, and capability reports being modified or not delivered to the intended recipient. It can also take the form of analysis of data sent to or from the device, in content, size, or frequency.
攻撃者は、デバイスとの間ですべてのトラフィックを傍受します。攻撃者は、デバイスに送信された、または受信したデータを監視または変更できます。これは、マニフェスト、ペイロード、ステータスレポート、および機能レポートの形式が修正されているか、または意図された受信者に配信されていないという形をとることができます。それはまた、デバイスの間、またはデバイスから送信されたデータの分析の形式、コンテンツ、サイズ、または周波数を取ります。
Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12), REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7), REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14), REQ.SEC.REPORTING (Section 4.3.16)
軽減：req.sec.authentic（セクション4.3.4）、req.sec.img.confiditality（セクション4.3.12）、req.sec.auth.remote_loc（セクション4.3.7）、req.sec.mfst.confiditality（4.3.14節）、req.sec.reporting（セクション4.3.16）
Classification: Elevation of Privilege
分類：特権の上昇
An attacker replaces newly downloaded firmware after a device finishes verifying a manifest. This could cause the device to execute the attacker's code. This attack likely requires physical access to the device. However, it is possible that this attack is carried out in combination with another threat that allows remote execution. This is a typical Time Of Check / Time Of Use (TOCTOU) attack.
攻撃者は、デバイスがマニフェストの検証を終了した後に新しくダウンロードされたファームウェアを置き換えます。これにより、デバイスが攻撃者のコードを実行する可能性があります。この攻撃には、デバイスへの物理的なアクセスが必要です。ただし、この攻撃はリモート実行を可能にする他の脅威と組み合わせて実行される可能性があります。これは典型的なチェック/使用時（恐怖）攻撃です。
Threat Escalation: If the attacker is able to exploit a known vulnerability or if the attacker can supply their own firmware, then this threat can be escalated to all types.
脅威のエスカレーション：攻撃者が既知の脆弱性を悪用できる場合、または攻撃者が自分のファームウェアを提供できる場合は、この脅威をすべての型にエスカレートできます。
Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8)
軽減された：req.sec.auth.exec（セクション4.3.8）
Classification: Elevation of Privilege / all types
分類：特権の標高/すべてのタイプ
If an attacker can install their firmware on a device -- for example, by manipulating either payload or metadata -- then they have complete control of the device.
攻撃者がデバイスにファームウェアをインストールできる場合は、例えばペイロードまたはメタデータを操作することによって - それからそれらはデバイスの完全な制御を持っています。
Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4)
軽減された：req.sec.authentic（セクション4.3.4）
Classification: Denial of Service / all types
分類：サービス拒否/すべてのタイプ
Modifications of payloads and metadata allow an attacker to introduce a number of denial-of-service attacks. Below are some examples.
ペイロードとメタデータの変更により、攻撃者は多くのサービス拒否攻撃を導入することができます。以下の例はいくつかの例です。
An attacker sends a valid, current manifest to a device that has an unexpected precursor image. If a payload format requires a precursor image (for example, delta updates) and that precursor image is not available on the target device, it could cause the update to break.
攻撃者は、予期しない前兆画像を持つデバイスに有効な現在のマニフェイスを送信します。ペイロードフォーマットが前駆体画像（たとえば、デルタ更新）を必要とし、その前駆体画像がターゲットデバイスで利用できない場合は、アップデートが壊れる可能性があります。
An attacker that can cause a device to install a payload against the wrong precursor image could gain elevation of privilege and potentially expand this to all types of threats. However, it is unlikely that a valid differential update applied to an incorrect precursor would result in functional, but vulnerable, firmware.
デバイスが間違った前流演算画像に対してペイロードをインストールさせる可能性がある攻撃者は特権の標高を獲得し、これをあらゆる種類の脅威に拡大する可能性があります。ただし、誤った前駆体に適用される有効な差動更新プログラムが機能的になるが、脆弱なファームウェアになることはほとんどありません。
Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9)
軽減された：req.sec.auth.precursor（セクション4.3.9）
Classification: Denial of Service, Elevation of Privilege
分類：サービス拒否、特権の標高
This threat can appear in several ways; however, it is ultimately about ensuring that devices retain the behavior required by their owner or Operator. The owner or Operator of a device typically requires that the device maintain certain features, functions, capabilities, behaviors, or interoperability constraints (more generally, behavior). If these requirements are broken, then a device will not fulfill its purpose. Therefore, if any party other than the device's owner or the owner's contracted device operator has the ability to modify device behavior without approval, then this constitutes an elevation of privilege.
この脅威はいくつかの方法で現れることができます。ただし、最終的には、デバイスが所有者またはオペレーターに必要な動作を保持することを確実にすることについてです。装置の所有者または演算子は通常、装置が特定の機能、機能、機能、動作、または相互運用性の制約を維持することを必要とする（より一般的には動作）。これらの要件が壊れている場合、デバイスはその目的を満たしません。したがって、デバイスの所有者または所有者の契約デバイスオペレーター以外の当事者が承認なしにデバイスの動作を変更する機能を持っている場合、これは特権の標高を構成します。
Similarly, a network operator may require that devices behave in a particular way in order to maintain the integrity of the network. If device behavior on a network can be modified without the approval of the network operator, then this constitutes an elevation of privilege with respect to the network.
同様に、ネットワークオペレータは、ネットワークの完全性を維持するために、装置が特定の方法で動作することを要求し得る。ネットワーク上のデバイスの動作をネットワーク事業者の承認なしに変更できる場合、これはネットワークに対する特権の標高を構成します。
For example, if the owner of a device has purchased that device because of Features A, B, and C, and a firmware update that removes Feature A is issued by the manufacturer, then the device may not fulfill the owner's requirements any more. In certain circumstances, this can cause significantly greater threats. Suppose that Feature A is used to implement a safety-critical system, whether the manufacturer intended this behavior or not. When unapproved firmware is installed, the system may become unsafe.
たとえば、デバイスの所有者が機能A、B、Cのためにそのデバイスを購入した場合、および機能Aを削除するファームウェアアップデートが製造元によって発行された場合、その装置はこれ以上所有者の要件を満たさない可能性があります。特定の状況では、これは大幅に大きな脅威を引き起こす可能性があります。メーカーがこの動作を意図したかどうかにかかわらず、機能Aが安全性が重要なシステムを実装するために使用されるとします。未承認のファームウェアがインストールされている場合、システムは危険にさらされる可能性があります。
In a second example, the owner or Operator of a system of two or more interoperating devices needs to approve firmware for their system in order to ensure interoperability with other devices in the system. If the firmware is not qualified, the system as a whole may not work. Therefore, if a device installs firmware without the approval of the device owner or Operator, this is a threat to devices or the system as a whole.
第2の例では、システム内の他の装置との相互運用性を確保するために、2つ以上の相互運用装置のシステムの所有者または演算子がシステムのためのファームウェアを承認する必要がある。ファームウェアが修飾されていない場合、システム全体としてのシステムは機能しない可能性があります。したがって、デバイスの所有者またはオペレータの承認なしにデバイスがファームウェアをインストールした場合、これはデバイスまたはシステム全体に対する脅威です。
Similarly, the Operator of a network may need to approve firmware for devices attached to the network in order to ensure favorable operating conditions within the network. If the firmware is not qualified, it may degrade the performance of the network. Therefore, if a device installs firmware without the approval of the network operator, this is a threat to the network itself.
同様に、ネットワークのオペレータは、ネットワーク内で良好な動作条件を確実にするために、ネットワークに接続されている装置のファームウェアを承認する必要があるかもしれない。ファームウェアが修飾されていない場合は、ネットワークのパフォーマンスが低下する可能性があります。したがって、ネットワーク事業者の承認なしにデバイスがファームウェアをインストールした場合、これはネットワーク自体に対する脅威です。
Threat Escalation: If the network operator expects configuration that is present in devices deployed in Network A, but not in devices deployed in Network B, then the device may experience degraded security, leading to threats of all types.
脅威のエスカレーション：ネットワーク事業者がネットワークAに展開されているがネットワークBに展開されていないデバイスに存在する構成を期待している場合、デバイスはセキュリティが低下する可能性があり、すべてのタイプの脅威につながります。
Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL (Section 4.3.13)
軽減された：req.sec.rights（セクション4.3.11）、req.sec.access_control（セクション4.3.13）
4.2.11.1. Example 1: Multiple Network Operators with a Single Device Operator
4.2.11.1. 例1：単一のデバイスオペレータを持つ複数のネットワーク事業者
In this example, assume that device operators expect the rights to create firmware but that network operators expect the rights to qualify firmware as "fit for purpose" on their networks. Additionally, assume that device operators manage devices that can be deployed on any network, including Network A and Network B in our example.
この例では、デバイスオペレータがファームウェアを作成する権限を期待していると仮定しますが、ネットワーク事業者は、ネットワーク上で「目的のための適合」としてファームウェアを修飾する権利を期待しています。さらに、デバイスオペレータが、この例では、ネットワークAとネットワークBを含む任意のネットワークにデプロイできるデバイスを管理するとします。
An attacker may obtain a manifest for a device on Network A. Then, this attacker sends that manifest to a device on Network B. Because Network A and Network B are under the control of different Operators, and the firmware for a device on Network A has not been qualified to be deployed on Network B, the target device on Network B is now in violation of Operator B's policy and may be disabled by this unqualified, but signed, firmware.
攻撃者は、ネットワークA上のデバイスのマニフェストを取得することができます。その後、この攻撃者はネットワークB上のデバイスにマニフェストを送信します。ネットワークAとネットワークBはさまざまな演算子の制御下にあり、ネットワーク上のデバイスのファームウェアネットワークB上のターゲットデバイスは、ネットワークBに展開される資格がありません.BネットワークB上のターゲットデバイスは、現在はオペレータBのポリシーに違反しており、この未修正では無効になることがありますが、署名されたファームウェア。
This is a denial of service because it can render devices inoperable. This is an elevation of privilege because it allows the attacker to make installation decisions that should be made by the Operator.
デバイスが動作不能にすることができるため、これはサービス拒否です。これは、攻撃者がオペレータによって行われるべきインストールの決定を下すことができるので特権の標高です。
4.2.11.2. Example 2: Single Network Operator with Multiple Device Operators
4.2.11.2. 例2：複数の装置演算子を持つ単一のネットワーク事業者
Multiple devices that interoperate are used on the same network and communicate with each other. Some devices are manufactured and managed by Device Operator A and other devices by Device Operator B. New firmware is released by Device Operator A that breaks compatibility with devices from Device Operator B. An attacker sends the new firmware to the devices managed by Device Operator A without the approval of the network operator. This breaks the behavior of the larger system, causing denial of service and, possibly, other threats. Where the network is a distributed Supervisory Control and Data Acquisition (SCADA) system, this could cause misbehavior of the process that is under control.
相互運用が同じネットワーク上で使用され、互いに通信する複数のデバイス。デバイスオペレータBによってデバイスオペレータAおよび他のデバイスによって製造され管理されるデバイスが製造されて管理されている。新しいファームウェアは、デバイス演算子Bからのデバイスとの互換性を分解するデバイスオペレータAによって解放される。攻撃者は、新しいファームウェアをデバイス演算子によって管理されているデバイスに送信する。ネットワーク事業者の承認なしに。これはより大きなシステムの動作を破り、サービス拒否および他の脅威を引き起こす。ネットワークが分散監視制御とデータ取得（SCADA）システムである場合、これは制御中のプロセスの不正行為を引き起こす可能性があります。
4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering of Firmware Image for Vulnerability Analysis
4.2.12. threat.img.disclosure：脆弱性分析のためのファームウェアイメージのリバースエンジニアリング
Classification: all types
分類：すべてのタイプ
An attacker wants to mount an attack on an IoT device. To prepare the attack, the provided firmware image is reverse engineered and analyzed for vulnerabilities.
攻撃者はIOTデバイスに攻撃をマウントしたいと考えています。攻撃を準備するために、提供されたファームウェアイメージは脆弱性のためにリバース設計され分析されます。
Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)
軽減された：req.sec.img.confiditiality（セクション4.3.12）
Classification: Elevation of Privilege
分類：特権の上昇
An authorized actor, but not the author, uses an override mechanism (USER_STORY.OVERRIDE (Section 4.4.3)) to change an information element in a manifest signed by the author. For example, if the authorized actor overrides the digest and URI of the payload, the actor can replace the entire payload with a payload of their choice.
執筆者ではなく、執筆者ではなく、オーバーライドメカニズム（USER_STORY.OVERRIDE（セクション4.4.3））を使用して、作成者によって署名されたマニフェストの情報要素を変更します。たとえば、許可されたアクターがペイロードのダイジェストとURIをオーバーライドすると、俳優はペイロード全体を選択のペイロードに置き換えることができます。
Threat Escalation: By overriding elements such as payload installation instructions or a firmware digest, this threat can be escalated to all types.
脅威のエスカレーション：ペイロードのインストール手順やファームウェアダイジェストなどの要素を上書きすることで、この脅威をすべての型にエスカレートできます。
Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13)
軽減された：req.sec.access_control（セクション4.3.13）
Classification: Information Disclosure
分類：情報開示
A third party may be able to extract sensitive information from the manifest.
第三者は、マニフェストから機密情報を抽出することができるかもしれません。
Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14)
軽減された：req.sec.mfst.confiditiality（セクション4.3.14）
Classification: all types
分類：すべてのタイプ
If a third party modifies the image so that it contains extra code after a valid, authentic image, that third party can then use their own code in order to make better use of an existing vulnerability.
第三者が画像を変更した場合、有効な本格的な画像の後に追加のコードが含まれている場合、その後、既存の脆弱性をよりよく使用するために自分のコードを使用できます。
Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15)
軽減された：req.sec.img.complete_digest（セクション4.3.15）
Classification: all types
分類：すべてのタイプ
If a third party obtains a key or even indirect access to a key -- for example, in a hardware security module (HSM) -- then they can perform the same actions as the legitimate owner of the key. If the key is trusted for firmware updates, then the third party can perform firmware updates as though they were the legitimate owner of the key.
例えば、ハードウェアセキュリティモジュール（HSM）では、第三者がキーへのキーまたは間接的なアクセスを取得する場合は、キーの正当な所有者と同じアクションを実行できます。キーがファームウェアアップデートに信頼されている場合、第三者は鍵の正当な所有者であるかのようにファームウェアの更新を実行できます。
For example, if manifest signing is performed on a server connected to the internet, an attacker may compromise the server and then be able to sign manifests, even if the keys for manifest signing are held in an HSM that is accessed by the server.
たとえば、インターネットに接続されているサーバー上でマニフェスト署名が実行されている場合、攻撃者はサーバーからアクセスされたHSMで保持されていても、攻撃者がサーバーを侵害してからマニフェストに署名することができます。
Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17), REQ.SEC.KEY.ROTATION (Section 4.3.18)
繰り返した：req.sec.key.protection（セクション4.3.17）、req.sec.key.rotation（セクション4.3.18）
4.2.17. THREAT.MFST.MODIFICATION: Modification of Manifest or Payload prior to Signing
4.2.17. 脅威mfst.mipification：署名前のマニフェストまたはペイロードの修正
Classification: all types
分類：すべてのタイプ
If an attacker can alter a manifest or payload before it is signed, they can perform all the same actions as the manifest author. This allows the attacker to deploy firmware updates to any devices that trust the manifest author. If an attacker can modify the code of a payload before the corresponding manifest is created, they can insert their own code. If an attacker can modify the manifest before it is signed, they can redirect the manifest to their own payload.
攻撃者が署名される前にマニフェストまたはペイロードを変更できる場合は、マニフェスト作成者と同じアクションをすべて実行できます。これにより、攻撃者は、マニフェスト作成者を信頼するデバイスにファームウェアアップデートをデプロイすることができます。対応するマニフェストが作成される前に攻撃者がペイロードのコードを変更できる場合は、自分のコードを挿入できます。攻撃者が署名される前にマニフェストを変更できる場合、それらはマニフェストを自分のペイロードにリダイレクトすることができます。
For example, the attacker deploys malware to the developer's computer or signing service that watches manifest creation activities and inserts code into any binary that is referenced by a manifest.
たとえば、攻撃者はマルウェアを開発者のコンピュータまたは署名サービスを展開し、マニフェスト登録活動を監視し、マニフェストによって参照されている任意のバイナリにコードを挿入します。
For example, the attacker deploys malware to the developer's computer or signing service that replaces the referenced binary (digest) and URI with the attacker's binary (digest) and URI.
たとえば、攻撃者は、参照されているバイナリ（ダイジェスト）とURIを攻撃者のバイナリ（ダイジェスト）とURIに置き換える開発者のコンピュータまたは署名サービスにマルウェアを展開します。
Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.19), REQ.SEC.MFST.TRUSTED (Section 4.3.20)
req.sec.mfst.check（セクション4.3.19）、req.sec.mfst.trusted（セクション4.3.20）
4.2.18. THREAT.MFST.TOCTOU: Modification of Manifest between Authentication and Use
4.2.18. Threat.mfst.toctou：認証と使用の間のマニフェストの変更
Classification: all types
分類：すべてのタイプ
If an attacker can modify a manifest after it is authenticated (time of check) but before it is used (time of use), then the attacker can place any content whatsoever in the manifest.
攻撃者が認証後（チェック時）ではなく、使用前にマニフェストを変更できる場合（使用時（使用時）、攻撃者はどのコンテンツをマニフェストに置くことができます。
Mitigated by: REQ.SEC.MFST.CONST (Section 4.3.21)
軽減された：req.sec.mfst.const（セクション4.3.21）
The security requirements here are a set of policies that mitigate the threats described in Section 4.1.
ここでのセキュリティ要件は、セクション4.1で説明されている脅威を軽減する一連のポリシーです。
Only an actor with firmware installation authority is permitted to decide when device firmware can be installed. To enforce this rule, manifests MUST contain monotonically increasing sequence numbers. Manifests may use UTC epoch timestamps to coordinate monotonically increasing sequence numbers across many actors in many locations. If UTC epoch timestamps are used, they must not be treated as times; they must be treated only as sequence numbers. Devices must reject manifests with sequence numbers smaller than any onboard sequence number, i.e., there is no sequence number rollover.
ファームウェアのインストール権限を持つアクターのみが、デバイスファームウェアをインストールできるときに決定できます。この規則を強制するためには、マニフェストに単調に増加するシーケンス番号を含める必要があります。マニフェストは、多くの場所で多くの俳優にわたって単調に増加するシーケンス番号を調整するためにUTCのエポックタイムスタンプを使用することができます。UTCエポックタイムスタンプが使用されている場合、それらは時刻として扱われてはいけません。それらはシーケンス番号としてのみ扱われなければなりません。デバイスは、どのオンボードシーケンス番号よりも小さいシーケンス番号でマニフェストを拒否しなければなりません。すなわち、シーケンス番号のロールオーバーはありません。
Note: This is not a firmware version field. It is a manifest sequence number. A firmware version may be rolled back by creating a new manifest for the old firmware version with a later sequence number.
注：これはファームウェアのバージョンフィールドではありません。これはマニフェストのシーケンス番号です。後でシーケンス番号を持つ古いファームウェアバージョンの新しいマニフェストを作成することで、ファームウェアのバージョンをロールバックすることができます。
Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1)
itigatigates：threat.img.expired（セクション4.2.1）
Implemented by: Monotonic Sequence Number (Section 3.2)
Monotonicシーケンス番号（セクション3.2）
Devices MUST only apply firmware that is intended for them. Devices must know that a given update applies to their vendor, model, hardware revision, and software revision. Human-readable identifiers are often prone to error in this regard, so unique identifiers should be used instead.
デバイスは、それらを対象としたファームウェアのみを適用する必要があります。デバイスは、特定のアップデートがベンダー、モデル、ハードウェアのリビジョン、およびソフトウェアのリビジョンに適用されることを知っておく必要があります。この点に関して人間が読める識別子はしばしばエラーが発生しやすくなるので、一意の識別子を代わりに使用する必要があります。
Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3)
itigatigates：threat.img.inCompatible（セクション4.2.3）
Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition (Section 3.4)
実装された：ベンダーID条件（セクション3.3）、クラスID条件（セクション3.4）
A firmware manifest MAY expire after a given time, and devices may have a secure clock (local or remote). If a secure clock is provided and the firmware manifest has an expiration timestamp, the device must reject the manifest if the current time is later than the expiration time.
ファームウェアマニフェストは与えられた時間の後に期限切れになる可能性があり、デバイスは安全なクロック（ローカルまたはリモート）を持つことがあります。セキュアクロックが提供され、ファームウェアマニフェストに有効期限タイムスタンプがある場合、デバイスは現在の時間が有効期限より遅い場合はマニフェストを拒否しなければなりません。
Special consideration is required for end-of-life in cases where a device will not be updated again -- for example, if a business stops issuing updates for a device. The last valid firmware should not have an expiration time.
デバイスがデバイスの更新を発行するのを停止した場合、デバイスが再び更新されない場合には、寿命の終わりに特別な配慮が必要です。最後の有効なファームウェアは有効期限を持つべきではありません。
If a device has a flawed time source (either local or remote), an old update can be deployed as new.
デバイスに欠陥のある時間源（ローカルまたはリモート）がある場合は、古い更新プログラムを新規としてデプロイできます。
Mitigates: THREAT.IMG.EXPIRED.OFFLINE (Section 4.2.2)
itigatigates：threat.img.expired.offline（セクション4.2.2）
Implemented by: Expiration Time (Section 3.7)
実行された：有効期限（セクション3.7）
The authenticity of an update MUST be demonstrable. Typically, this means that updates must be digitally signed. Because the manifest contains information about how to install the update, the manifest's authenticity must also be demonstrable. To reduce the overhead required for validation, the manifest contains the cryptographic digest of the firmware image, rather than a second digital signature. The authenticity of the manifest can be verified with a digital signature or Message Authentication Code. The authenticity of the firmware image is tied to the manifest by the use of a cryptographic digest of the firmware image.
更新の信憑性は証明可能である必要があります。通常、これは更新がデジタル署名されなければならないことを意味します。マニフェストにはアップデートのインストール方法に関する情報が含まれているため、マニフェストの信頼性も証明できます。検証に必要なオーバーヘッドを減らすために、マニフェストは、2番目のデジタル署名ではなく、ファームウェアイメージの暗号ダイジェストを含みます。マニフェストの信憑性は、デジタル署名またはメッセージ認証コードで検証できます。ファームウェアイメージの信頼性は、ファームウェアイメージの暗号ダイジェストを使用することによってマニフェストに関連付けられています。
Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.ONPATH (Section 4.2.7)
mitigates：threat.img.non_auth（セクション4.2.9）、threat.net.onpath（セクション4.2.7）
Implemented by: Signature (Section 3.15), Payload Digests (Section 3.13)
実装：シグネチャ（セクション3.15）、ペイロードダイジェスト（セクション3.13）
The type of payload MUST be authenticated. For example, the target must know whether the payload is XIP firmware, a loadable module, or configuration data.
ペイロードの種類は認証されなければなりません。たとえば、ターゲットは、ペイロードがXIPファームウェア、ロード可能モジュール、または構成データであるかどうかを知っている必要があります。
Mitigates: THREAT.IMG.FORMAT (Section 4.2.4)
脅威：threat.img.format（セクション4.2.4）
Implemented by: Payload Format (Section 3.8), Signature (Section 3.15)
Payload Format（セクション3.8）、署名（セクション3.15）
The location on the target where the payload is to be stored MUST be authenticated.
ペイロードを保存するターゲット上の場所は認証されなければなりません。
Mitigates: THREAT.IMG.LOCATION (Section 4.2.5)
itigatigates：threat.img.location（セクション4.2.5）
Implemented by: Storage Location (Section 3.10)
実装：保管場所（セクション3.10）
The location where a target should find a payload MUST be authenticated. Remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs. The security considerations of Uniform Resource Identifiers (URIs) are applicable [RFC3986].
ターゲットがペイロードを見つけるべき場所は認証されなければなりません。リモートリソースは、リモートのURIを参照すると、マニフェスト自体として等量の暗号保護を受信する必要があります。統一リソース識別子（URI）のセキュリティ上の考慮事項は適用可能です[RFC3986]。
Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.ONPATH (Section 4.2.7)
軽減：threat.net.redirect（セクション4.2.6）、threat.net.onpath（セクション4.2.7）
Implemented by: Payload Indicator (Section 3.12)
Payload Indicator：Payload Indicator（セクション3.12）
The target SHOULD verify firmware at the time of boot. This requires authenticated payload size and firmware digest.
ターゲットは起動時にファームウェアを確認する必要があります。これには、認証されたペイロードサイズとファームウェアダイジェストが必要です。
Mitigates: THREAT.IMG.REPLACE (Section 4.2.8)
itigatigates：threat.img.replace（セクション4.2.8）
Implemented by: Payload Digests (Section 3.13), Size (Section 3.14)
実装：ペイロードダイジェスト（セクション3.13）、サイズ（セクション3.14）
If an update uses a differential compression method, it MUST specify the digest of the precursor image, and that digest MUST be authenticated.
更新プログラムが差動圧縮方法を使用する場合は、前駆体画像のダイジェストを指定する必要があり、そのダイジェストは認証されなければなりません。
Mitigates: THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10)
軽減：threat.upd.wrong_precursor（セクション4.2.10）
Implemented by: Precursor Image Digest (Section 3.5)
実行された：前駆体画像ダイジェスト（セクション3.5）
The identifiers that specify firmware compatibility MUST be authenticated to ensure that only compatible firmware is installed on a target device.
ファームウェアの互換性を指定する識別子は、互換性のあるファームウェアのみがターゲットデバイスにインストールされていることを確認するために認証されなければなりません。
Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3)
itigatigates：threat.img.inCompatible（セクション4.2.3）
Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition (Section 3.4)
実装された：ベンダーID条件（セクション3.3）、クラスID条件（セクション3.4）
If a device grants different rights to different actors, exercising those rights MUST be accompanied by proof of those rights, in the form of proof of authenticity. Authenticity mechanisms, such as those required in REQ.SEC.AUTHENTIC (Section 4.3.4), can be used to prove authenticity.
デバイスがさまざまなアクターに異なる権利を付与した場合、それらの権利を実行する必要があり、信憑性の証明の形で、それらの権利の証明を伴わなければなりません。信頼性を証明するために、REQ.Sec.Authentic（セクション4.3.4）などの信頼性メカニズムを使用することができます。
For example, if a device has a policy that requires that firmware have both an Authorship right and a Qualification right and if that device grants Authorship and Qualification rights to different parties, such as a device operator and a network operator, respectively, then the firmware cannot be installed without proof of rights from both the device operator and the network operator.
たとえば、ファームウェアが作成者権利と資格権の両方を持つことを要求している場合、そのデバイスがデバイスオペレータやネットワーク事業者などの異なる当事者に対する認定権を付与することを要求している場合は、それぞれファームウェアを提供するポリシーがある場合デバイスオペレータとネットワークオペレータの両方から権限の証明なしにはインストールできません。
Mitigates: THREAT.UPD.UNAPPROVED (Section 4.2.11)
軽減：threat.upd.Unappred（セクション4.2.11）
Implemented by: Signature (Section 3.15)
実装：署名（セクション3.15）
The manifest information model MUST enable encrypted payloads. Encryption helps to prevent third parties, including attackers, from reading the content of the firmware image. This can protect against confidential information disclosures and discovery of vulnerabilities through reverse engineering. Therefore, the manifest must convey the information required to allow an intended recipient to decrypt an encrypted payload.
マニフェスト情報モデルは、暗号化されたペイロードを有効にする必要があります。暗号化は、攻撃者を含む第三者がファームウェアイメージの内容を読むのを防ぐのに役立ちます。これは、リバースエンジニアリングによる機密情報の開示と脆弱性の発見から保護することができます。したがって、マニフェストは、意図された受信者が暗号化されたペイロードを復号化できるようにするために必要な情報を伝える必要があります。
Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.ONPATH (Section 4.2.7)
mitigates：threat.img.disclosure（セクション4.2.12）、threat.net.onpath（セクション4.2.7）
Implemented by: Encryption Wrapper (Section 3.20)
実行された：暗号化ラッパー（セクション3.20）
If a device grants different rights to different actors, then an exercise of those rights MUST be validated against a list of rights for the actor. This typically takes the form of an Access Control List (ACL). ACLs are applied to two scenarios:
デバイスがさまざまなアクターに対して異なる権利を付与した場合、その権限の行使は俳優の権利のリストに対して検証されなければなりません。これは通常、アクセス制御リスト（ACL）の形式を取ります。ACLは2つのシナリオに適用されます。
1. An ACL decides which elements of the manifest may be overridden and by which actors.
1. ACLは、マニフェストのどの要素をオーバーライドさせるか、どのアクターによってどの要素を決定します。
2. An ACL decides which component identifier / storage identifier pairs can be written by which actors.
2. ACLは、どのコンポーネント識別子/ストレージ識別子ペアをどのアクターによって書き込むことができるかを決定します。
Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13), THREAT.UPD.UNAPPROVED (Section 4.2.11)
itigatigates：threat.mfst.override（セクション4.2.13）、threat.upd.Unappred（セクション4.2.11）
Implemented by: Client-side code, not specified in manifest
実行されている：マニフェストで指定されていないクライアントサイドコード
A manifest format MUST allow encryption of selected parts of the manifest or encryption of the entire manifest to prevent sensitive content of the firmware metadata from being leaked.
マニフェストフォーマットは、マニフェスト全体のマニフェストまたは暗号化の選択された部分の暗号化を許可し、ファームウェアメタデータの繊細されたコンテンツが漏洩するのを防ぐ必要があります。
Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.ONPATH (Section 4.2.7)
脅威：threat.mfst.exposure（セクション4.2.14）、threat.net.onpath（セクション4.2.7）
Implemented by: Manifest Encryption Wrapper / Transport Security
実装されている：マニフェスト暗号化ラッパー/トランスポートセキュリティ
The digest SHOULD cover all available space in a fixed-size storage location. Variable-size storage locations MUST be restricted to exactly the size of deployed payload. This prevents any data from being distributed without being covered by the digest. For example, XIP microcontrollers typically have fixed-size storage. These devices should deploy a digest that covers the deployed firmware image, concatenated with the default erased value of any remaining space.
ダイジェストは、固定サイズの保管場所のすべての使用可能スペースをカバーする必要があります。可変サイズのストレージ位置は、展開されたペイロードのサイズを正確に制限する必要があります。これにより、ダイジェストによってカバーされずにデータが配布されるのを防ぎます。たとえば、XIPマイクロコントローラは通常、固定サイズの保存を持ちます。これらのデバイスは、デプロイされたファームウェアイメージをカバーするダイジェストを展開する必要があります。デフォルトの残りのスペースのデフォルトの消去された値と連結されます。
Mitigates: THREAT.IMG.EXTRA (Section 4.2.15)
itigatigates：threat.img.extra（セクション4.2.15）
Implemented by: Payload Digests (Section 3.13)
Payload Digests（セクション3.13）
Status reports from the device to any remote system MUST be performed over an authenticated, confidential channel in order to prevent modification or spoofing of the reports.
レポートの変更やスプーフィングを防ぐために、デバイスから任意のリモートシステムへのステータスレポートを認証した機密チャネルを介して実行する必要があります。
Mitigates: THREAT.NET.ONPATH (Section 4.2.7)
脅威：threat.net.onpath（セクション4.2.7）
Implemented by: Transport Security / Manifest format triggering generation of reports
実装：トランスポートセキュリティ/マニフェストフォーマットレポートの生成
Cryptographic keys for signing/authenticating manifests SHOULD be stored in a manner that is inaccessible to networked devices -- for example, in an HSM or an air-gapped computer. This protects against an attacker obtaining the keys.
署名/認証用の暗号化キーは、ネットワークデバイスにアクセスできない方法（たとえば、HSMまたはエアゲープコンピュータ）にアクセスできます。これは、キーを取得する攻撃者から保護します。
Keys SHOULD be stored in a way that limits the risk of a legitimate, but compromised, entity (such as a server or developer computer) issuing signing requests.
鍵は、正当なもののリスクを制限するような方法で保存されるべきですが、エンティティ（サーバーや開発者コンピュータなど）の署名要求を発行します。
Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16)
脅威：Threat.Key.Exposure（セクション4.2.16）
Implemented by: Hardware-assisted isolation technologies, which are outside the scope of the manifest format
実装された：マニフェストフォーマットの範囲外のハードウェア支援分離技術
Cryptographic keys for signing/authenticating manifests SHOULD be replaced from time to time. Because it is difficult and risky to replace a trust anchor, keys used for signing updates SHOULD be delegates of that trust anchor.
署名/認証のための暗号化キーは、時々置き換えられるべきです。信頼アンカーを交換することは困難で危険なので、アップデートの署名に使用される鍵はその信頼のアンカーの代表者になるべきです。
If key expiration is performed based on time, then a secure clock is needed. If the time source used by a recipient to check for expiration is flawed, an old signing key can be used as current, which compounds THREAT.KEY.EXPOSURE (Section 4.2.16).
時間通過が時間に基づいて実行された場合、安全なクロックが必要です。有効期限をチェックするために受信者が使用するタイムソースが欠陥のある場合、古い署名キーを現在のものとして使用することができます。これは、Threat.Key.Exposure（セクション4.2.16）。
Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16)
脅威：Threat.Key.Exposure（セクション4.2.16）
Implemented by: Secure storage technology, which is a system design/ implementation aspect outside the scope of the manifest format
実装された：Secure Storage Technology、これはマニフェスト形式の範囲外のシステム設計/実装面である。
Manifests SHOULD be verified prior to deployment. This reduces problems that may arise with devices installing firmware images that damage devices unintentionally.
展開前にマニフェストを検証する必要があります。これは、デバイスを意図せずに損傷するファームウェアイメージを取り付けるデバイスで発生する可能性がある問題を軽減します。
Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17)
軽減：threat.mfst.mification（セクション4.2.17）
Implemented by: Testing infrastructure. While outside the scope of the manifest format, proper testing of low-level software is essential for avoiding unnecessary downtime or worse situations.
インフラストラクチャのテストによって実装されています。マニフェストフォーマットの範囲外では、低レベルソフトウェアの適切なテストは、不要なダウンタイムや悪化した状況を回避するために不可欠です。
4.3.20. REQ.SEC.MFST.TRUSTED: Construct Manifests in a Trusted Environment
4.3.20. REQ.SEC.MFST.TRUSTED：信頼できる環境での構文がマニフェストです
For high-risk deployments, such as large numbers of devices or devices that provide critical functions, manifests SHOULD be constructed in an environment that is protected from interference, such as an air-gapped computer. Note that a networked computer connected to an HSM does not fulfill this requirement (see THREAT.MFST.MODIFICATION (Section 4.2.17)).
重要な機能を提供する多数のデバイスやデバイスなど、高リスクの展開のために、空気のガッピングコンピュータなどの干渉から保護されている環境でマニフェストを構築する必要があります。HSMに接続されているネットワークコンピュータはこの要件を満たしていないことに注意してください（Threat.MFST.Modification（セクション4.2.17）を参照）。
Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17)
軽減：threat.mfst.mification（セクション4.2.17）
Implemented by: Physical and network security for protecting the environment where firmware updates are prepared to avoid unauthorized access to this infrastructure
このインフラストラクチャへの不正アクセスを回避するためにファームウェアアップデートが準備されている環境を保護するための物理的およびネットワークのセキュリティ
4.3.21. REQ.SEC.MFST.CONST: Manifest Kept Immutable between Check and Use
4.3.21. REQ.SEC.MFST.CONST：MANIFESTは小切手と使用の間で不変に保たれます
Both the manifest and any data extracted from it MUST be held immutable between its authenticity verification (time of check) and its use (time of use). To make this guarantee, the manifest MUST fit within internal memory or secure memory, such as encrypted memory. The recipient SHOULD defend the manifest from tampering by code or hardware resident in the recipient -- for example, other processes or debuggers.
マニフェストとそれから抽出されたデータの両方は、その真正性検証（チェック時）とその使用（使用時）の間で不変に保持されなければなりません。この保証を行うには、マニフェストは、暗号化メモリなどの内部メモリまたはセキュアメモリ内に収まる必要があります。受信者は、受信者に常駐するコードやハードウェアごとの改ざんからのマニフェストを守る必要があります。たとえば、他のプロセスやデバッガなどです。
If an application requires that the manifest be verified before storing it, then this means the manifest MUST fit in RAM.
アプリケーションがそれを保存する前にマニフェストを検証する必要がある場合は、これはマニフェストがRAMに収まる必要があります。
Mitigates: THREAT.MFST.TOCTOU (Section 4.2.18)
軽減：threat.mfst.toctou（セクション4.2.18）
Implemented by: Proper system design with sufficient resources and implementation avoiding TOCTOU attacks
実施による実施：十分なリソースと実装を伴う適切なシステム設計
User stories provide expected use cases. These are used to feed into usability requirements.
ユーザーストーリーは予想されるユースケースを提供します。これらは使いやすさの要件に供給するために使用されます。
As a device operator, I want to provide my devices with additional installation instructions so that I can keep process details out of my payload data.
デバイスオペレータとして、私は私のペイロードデータからプロセスの詳細を維持できるように、私のデバイスを追加のインストール手順で提供したいです。
Some installation instructions might be as follows:
一部のインストール手順は次のとおりです。
* Use a table of hashes to ensure that each block of the payload is validated before writing.
* ペイロードの各ブロックが書き込み前に検証されていることを確認するためにハッシュテーブルを使用してください。
* Do not report progress.
* 進捗状況を報告しないでください。
* Pre-cache the update, but do not install.
* アップデートを事前にキャッシュしますが、インストールしないでください。
* Install the pre-cached update matching this manifest.
* このマニフェストに一致するプレキャッシュアップデートをインストールしてください。
* Install this update immediately, overriding any long-running tasks.
* この更新プログラムをすぐにインストールし、長期実行中のタスクをオーバーライドします。
Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
満足している：req.use.mfst.pre_check（セクション4.5.1）
As a designer of a resource-constrained IoT device, I want bad updates to fail as early as possible to preserve battery life and limit consumed bandwidth.
リソース制約付きIOTデバイスの設計者として、バッテリの寿命を維持し、消費される帯域幅を制限するために、できるだけ早く失敗することができます。
Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
満足している：req.use.mfst.pre_check（セクション4.5.1）
As a device operator, I would like to be able to override the non-critical information in the manifest so that I can control my devices more precisely. The authority to override this information is provided via the installation of a limited trust anchor by another authority.
デバイスオペレータとして、私は私のデバイスをより正確にコントロールできるように、マニフェストの非重要でない情報を上書きすることができたいです。この情報をオーバーライドする権限は、他の権限による制限された信頼アンカーのインストールによって提供されます。
Some examples of potentially overridable information:
潜在的に過剰な情報のいくつかの例：
URIs (Section 3.12): This allows the device operator to direct devices to their own infrastructure in order to reduce network load.
URIS（セクション3.12）：これにより、デバイスオペレータはネットワーク負荷を軽減するためにデバイスを自分のインフラストラクチャに直接転送できます。
Conditions: This allows the device operator to impose additional constraints on the installation of the manifest.
条件：これにより、デバイスオペレータはマニフェストのインストールに追加の制約を課すことができます。
Directives (Section 3.16): This allows the device operator to add more instructions, such as time of installation.
ディレクティブ（セクション3.16）：これにより、デバイスオペレータはインストール時などの手順を追加できます。
Processing Steps (Section 3.9): If an intermediary performs an action on behalf of a device, it may need to override the processing steps. It is still possible for a device to verify the final content and the result of any processing step that specifies a digest. Some processing steps should be non-overridable.
処理手順（セクション3.9）：仲介者が装置に代わってアクションを実行する場合、処理手順を上書きする必要があるかもしれません。デバイスが最終的な内容とダイジェストを指定する処理ステップの結果を検証することはまだ可能です。いくつかの処理ステップは、非オーバーライド可能であるべきです。
Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.4)
req.use.mfst.component（セクション4.5.4）
As a device operator, I want to divide my firmware into components, so that I can reduce the size of updates, make different parties responsible for different components, and divide my firmware into frequently updated and infrequently updated components.
デバイスオペレータとして、私は私のファームウェアをコンポーネントに分割したいので、更新のサイズを減らすことができ、さまざまなコンポーネントを責任を負い、そして私のファームウェアを頻繁に更新されていないコンポーネントに分割します。
Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.4)
req.use.mfst.component（セクション4.5.4）
As a device operator, I want to ensure the quality of a firmware update before installing it, so that I can ensure interoperability of all devices in my product family. I want to restrict the ability to make changes to my devices to require my express approval.
デバイスオペレータとして、インストールする前にファームウェアアップデートの品質を確保したいので、私の製品ファミリのすべてのデバイスの相互運用性を確保できます。私のエクスプレスの承認を要求するために私のデバイスに変更を加える能力を制限したいです。
Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.5), REQ.SEC.ACCESS_CONTROL (Section 4.3.13)
req.use.mfst.muthi_auth（セクション4.5.5）、req.sec.access_control（セクション4.3.13）
As a device operator, I want to be able to send multiple payload formats to suit the needs of my update, so that I can optimize the bandwidth used by my devices.
デバイスオペレータとして、私の更新のニーズに合わせて複数のペイロードフォーマットを送信することができますので、私のデバイスによって使用される帯域幅を最適化することができます。
Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.6)
req.use.img.format（セクション4.5.6）
4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information Disclosures
4.4.7. user_story.img.confiditiality：機密情報の開示を防ぐ
As a firmware author, I want to prevent confidential information in the manifest from being disclosed when distributing manifests and firmware images. Confidential information may include information about the device these updates are being applied to as well as information in the firmware image itself.
ファームウェア作成者として、マニフェストとファームウェアイメージを配布するときにマニフェスト内の機密情報が開示されないようにしたい。機密情報は、これらの更新が適用されているデバイスに関する情報、ならびにファームウェアイメージ自体の情報を含み得る。
Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)
満足している：req.sec.img.confiditiality（セクション4.3.12）
4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking Unknown Formats
4.4.8. user_story.img.unknown_Format：デバイスが不明な形式の解凍を防ぐこと
As a device operator, I want devices to determine whether they can process a payload prior to downloading it.
デバイスオペレータとして、デバイスがダウンロードする前にペイロードを処理できるかどうかを判断したいです。
In some cases, it may be desirable for a third party to perform some processing on behalf of a target. For this to occur, the third party MUST indicate what processing occurred and how to verify it against the Trust Provisioning Authority's intent.
場合によっては、第三者がターゲットの代わりに何らかの処理を実行することが望ましい場合がある。これが発生するためには、サードパーティはどの処理が行われたか、および信頼プロビジョニング局の意図に対して検証する方法を示す必要があります。
This amounts to overriding Processing Steps (Section 3.9) and Payload Indicator (Section 3.12).
これにより、処理手順（セクション3.9）およびペイロードインジケータ（セクション3.12）
Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.6), REQ.USE.IMG.NESTED (Section 4.5.7), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.3)
req.use.img.format（セクション4.5.6）、req.use.img.nested（セクション4.5.7）、req.use.mfst.override_remote（セクション4.5.3）
4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of Target Firmware
4.4.9. user_story.img.current_version：ターゲット・ファームウェアのバージョン番号を指定します
As a device operator, I want to be able to target devices for updates based on their current firmware version, so that I can control which versions are replaced with a single manifest.
デバイスオペレータとして、私は現在のファームウェアバージョンに基づいてアップデートのためのデバイスをターゲットにすることができます。そのため、どのバージョンを単一のマニフェストに置き換えるかを制御できます。
Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.8)
満足している：req.use.img.versions（セクション4.5.8）
As a developer, I want to be able to sign two or more versions of my firmware in a single manifest so that I can use a very simple bootloader that chooses between two or more images that are executed in place.
開発者として、私は1つ以上のマニフェストで私のファームウェアの2つ以上のバージョンに署名することができ、1つ以上の画像の間で実行される2つ以上の画像の間で選択される非常に単純なブートローダを使用することができます。
Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.9)
req.use.img.Select（セクション4.5.9）
As a signer for both secure execution/boot and firmware deployment, I would like to use the same signed document for both tasks so that my data size is smaller, I can share common code, and I can reduce signature verifications.
セキュア実行/起動およびファームウェアの展開の両方の署名者として、私のデータサイズが小さいように、両方のタスクに同じ署名文書を使用したいと思います。
Satisfied by: REQ.USE.EXEC (Section 4.5.10)
満足：req.use.exec（セクション4.5.10）
As a developer of firmware for a run-from-RAM device, I would like to use compressed images and to indicate to the bootloader that I am using a compressed image in the manifest so that it can be used with secure execution/boot.
RAMからのファームウェアの開発者として、圧縮画像を使用して、マニフェスト内の圧縮画像を使用しているブートローダには、安全な実行/起動で使用できるようにすることができます。
Satisfied by: REQ.USE.LOAD (Section 4.5.11)
req.use.load（セクション4.5.11）
As an Operator of devices on a constrained network, I would like the manifest to be able to include a small payload in the same packet so that I can reduce network traffic.
制約されたネットワーク上の装置のオペレータとして、私はネットワークトラフィックを減らすことができるように、マニフェストが同じパケットに小さなペイロードを含めることができるようにしたいと思います。
Small payloads may include, for example, wrapped content encryption keys, configuration information, public keys, authorization tokens, or X.509 certificates.
小さいペイロードは、例えば、包まれたコンテンツ暗号化キー、構成情報、公開鍵、承認トークン、またはX.509証明書を含み得る。
Satisfied by: REQ.USE.PAYLOAD (Section 4.5.12)
req.use.payload（セクション4.5.12）
As a developer for constrained devices, I want a low-complexity library for processing updates so that I can fit more application code on my device.
制約付きデバイスの開発者として、私は私のデバイス上でより多くのアプリケーションコードに適合することができるように、更新を処理するための低複雑さのライブラリが必要です。
Satisfied by: REQ.USE.PARSE (Section 4.5.13)
満足：req.use.parse（セクション4.5.13）
As a device operator that rotates delegated authority more often than delivering firmware updates, I would like to delegate a new authority when I deliver a firmware update so that I can accomplish both tasks in a single transmission.
ファームウェアアップデートを配信するよりも委任権限をより頻繁に回転させるデバイスオペレータとして、私はファームウェアアップデートを提供するときに新しい権限を委任し、私は単一の送信で両方のタスクを達成することができます。
Satisfied by: REQ.USE.DELEGATION (Section 4.5.14)
満足：req.use.Delegation（セクション4.5.14）
As an Operator of a constrained network, I would like devices on my network to be able to evaluate the suitability of an update prior to initiating any large download so that I can prevent unnecessary consumption of bandwidth.
制約付きネットワークのオペレータとして、私のネットワーク上のデバイスは、不要な帯域幅の消費を防ぐことができるように、大きなダウンロードを開始する前に更新の適合性を評価できるようにすることができます。
Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
満足している：req.use.mfst.pre_check（セクション4.5.1）
As a device operator, I want to understand what an update will do and to which devices it applies so that I can make informed choices about which updates to apply, when to apply them, and which devices should be updated.
デバイスオペレータとして、アップデートがどのようなものかどうかを理解し、どのデバイスが適用されるのか、どの更新プログラムを適用するか、それらを適用し、どのデバイスを更新する必要があるかについて理解したいです。
Satisfied by: REQ.USE.MFST.TEXT (Section 4.5.2)
満足：req.use.mfst.text（セクション4.5.2）
The following usability requirements satisfy the user stories listed above.
以下のユーザビリティ要件は、上記のユーザストーリーを満たしています。
A manifest format MUST be able to carry all information required to process an update.
マニフェストフォーマットは、更新を処理するために必要なすべての情報を運ぶことができなければなりません。
For example, information about which precursor image is required for a differential update must be placed in the manifest.
例えば、差動更新にどの前駆体画像が必要かについての情報をマニフェストに配置する必要がある。
Satisfies: USER_STORY.MFST.PRE_CHECK (Section 4.4.16), USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1)
満足：user_story.mfst.pre_check（セクション4.4.16）、user_stoly.install.instructions（セクション4.4.1）
Implemented by: Additional Installation Instructions (Section 3.16)
実装されている：追加のインストール手順（セクション3.16）
It MUST be possible for a device operator to determine what a manifest will do and which devices will accept it prior to distribution.
デバイスオペレータがマニフェストが何をするのか、そしてどのデバイスが配布前にそれを受け入れるかを決定することが可能である必要があります。
Satisfies: USER_STORY.MFST.ADMINISTRATION (Section 4.4.17)
満足：user_story.mfst.administration（セクション4.4.17）
Implemented by: Manifest Text Information (Section 3.17)
実装：マニフェストテキスト情報（セクション3.17）
A manifest format MUST be able to redirect payload fetches. This applies where two manifests are used in conjunction. For example, a device operator creates a manifest specifying a payload and signs it, and provides a URI for that payload. A network operator creates a second manifest, with a dependency on the first. They use this second manifest to override the URIs provided by the device operator, directing them into their own infrastructure instead. Some devices may provide this capability, while others may only look at canonical sources of firmware. For this to be possible, the device must fetch the payload, whereas a device that accepts payload pushes will ignore this feature.
マニフェストフォーマットは、ペイロードフェッチをリダイレクトすることができなければなりません。これは、2つのマニフェストが併用されている場所が適用されます。たとえば、デバイスオペレータはペイロードを指定してそれに署名するマニフェストを作成し、そのペイロードのURIを提供します。ネットワークオペレータが2番目のマニフェストを作成し、最初は依存します。これらは、この2番目のマニフェストを使用して、デバイスオペレータが提供するURIをオーバーライドし、代わりにそれらを独自のインフラストラクチャに向けます。いくつかのデバイスはこの機能を提供するかもしれませんが、他の人はファームウェアの標準的な原因だけを見ることができます。これが可能になるために、デバイスはペイロードを取得する必要がありますが、ペイロードプッシュを受け入れるデバイスはこの機能を無視します。
Satisfies: USER_STORY.OVERRIDE (Section 4.4.3)
満足：user_story.override（セクション4.4.3）
Implemented by: Aliases (Section 3.18)
実行された：エイリアス（セクション3.18）
A manifest format MUST be able to express the requirement to install one or more payloads from one or more authorities so that a multi-payload update can be described. This allows multiple parties with different permissions to collaborate in creating a single update for the IoT device, across multiple components.
マニフェストフォーマットは、マルチペイロードアップデートを記述することができるように、1つまたは複数の権限から1つ以上のペイロードをインストールするための要件を表現できる必要があります。これにより、複数のコンポーネント、複数のコンポーネントにわたるIOTデバイスの単一の更新プログラムを作成する際に、異なる権限を持つ複数のパーティーが可能です。
This requirement implies that it must be possible to construct a tree of manifests on a multi-image target.
この要件は、マルチイメージターゲット上に現れますが、マニフェストのツリーを構築することが可能でなければならないことを意味します。
In order to enable devices with a heterogeneous storage architecture, the manifest must enable specification of both a storage system and the storage location within that storage system.
異種ストレージアーキテクチャを有するデバイスを有効にするために、マニフェストはそのストレージシステム内のストレージシステムと保存場所の両方の仕様を有効にする必要があります。
Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT (Section 4.4.4)
満足：user_story.override（セクション4.4.3）、user_story.component（セクション4.4.4）
Implemented by: Dependencies, StorageIdentifier, ComponentIdentifier
依存関係、StorageIdentifier、ComponentIdentifier
An IoT device with multiple microcontrollers in the same physical device will likely require multiple payloads with different component identifiers.
同じ物理デバイスに複数のマイクロコントローラを持つIoTデバイスは、異なるコンポーネント識別子を持つ複数のペイロードを必要とする可能性があります。
A firmware image can be divided into two payloads: code and configuration. These payloads may require authorizations from different actors in order to install (see REQ.SEC.RIGHTS (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This structure means that multiple manifests may be required, with a dependency structure between them.
ファームウェアイメージは、コードと構成の2つのペイロードに分類できます。これらのペイロードは、インストールするためにさまざまなアクターからの承認を必要とする場合があります（REQ.SEC.RIGHTS（セクション4.3.11）、req.sec.access_control（セクション4.3.13）を参照）。この構造は、それらの間の依存構造を持つ、複数のマニフェストが必要とされるかもしれないことを意味します。
A firmware image can be divided into multiple functional blocks for separate testing and distribution. This means that code would need to be distributed in multiple payloads. For example, this might be desirable in order to ensure that common code between devices is identical in order to reduce distribution bandwidth.
ファームウェアイメージは、別々のテストおよび配布のために複数の機能ブロックに分割することができる。これは、コードを複数のペイロードで配布する必要があることを意味します。例えば、これは、配電帯域幅を縮小するために装置間の共通コードが同一であることを確実にするために望ましいかもしれない。
A manifest format MUST be able to carry multiple signatures so that authorizations from multiple parties with different permissions can be required in order to authorize installation of a manifest.
マニフェストフォーマットは、マニフェストのインストールを承認するために、異なる権限を持つ複数のパーティーからの権限が要求されるように、複数の署名を持つ必要があります。
Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5)
満足：user_story.multi_auth（セクション4.4.5）
Implemented by: Signature (Section 3.15)
実装：署名（セクション3.15）
The manifest format MUST accommodate any payload format that an Operator wishes to use. This enables the recipient to detect which format the Operator has chosen. Some examples of payload format are as follows:
マニフェストフォーマットは、オペレータが使用したいペイロードフォーマットに対応する必要があります。これにより、受信者はオペレータが選択されたフォーマットを検出できます。ペイロード形式のいくつかの例は次のとおりです。
* Binary
* バイナリ
* Executable and Linkable Format (ELF)
* 実行可能ファイルとリンク可能な形式（ELF）
* Differential
* different差
* Compressed
* 圧縮された
* Packed configuration
* パックされた構成
* Intel HEX
* Intel hex
* Motorola S-Record
* Motorola S-Record.
Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8)
満足：user_story.img.format（セクション4.4.6）user story.Image.Unknownフォーマット（セクション4.4.8）
Implemented by: Payload Format (Section 3.8)
Payload Format（セクション3.8）
The manifest format MUST accommodate nested formats, announcing to the target device all the nesting steps and any parameters used by those steps.
マニフェストフォーマットはネストされたフォーマットに対応し、ターゲットデバイスに、すべてのネスティングステップとそれらのステップによって使用されるパラメータをアナウンスしなければなりません。
Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7)
満足：user_story.img.confiditiality（セクション4.4.7）
Implemented by: Processing Steps (Section 3.9)
実行手順：処理手順（セクション3.9）
The manifest format MUST provide a method to specify multiple version numbers of firmware to which the manifest applies, either with a list or with range matching.
マニフェストフォーマットは、マニフェストが適用されるファームウェアの複数のバージョン番号を、リストまたは範囲マッチングで指定する方法を提供する必要があります。
Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9)
満足：user_story.img.current_version（セクション4.4.9）
Implemented by: Required Image Version List (Section 3.6)
実装されている：必要な画像バージョンリスト（セクション3.6）
The manifest format MUST provide a mechanism to list multiple equivalent payloads by execute-in-place (XIP) installation address, including the payload digest and, optionally, payload URIs.
マニフェストフォーマットは、ペイロードダイジェストとオプションでペイロードURIを含む、execute-in-place（XIP）インストールアドレスで複数の同等のペイロードをリストするメカニズムを提供する必要があります。
Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10)
満足：user_story.img.Select（セクション4.4.10）
Implemented by: XIP Address (Section 3.21)
XIPアドレス（セクション3.21）
The manifest format MUST allow the description of an executable system with a manifest on both XIP microcontrollers and complex operating systems. In addition, the manifest format MUST be able to express metadata, such as a kernel command line, used by any loader or bootloader.
マニフェストフォーマットは、XIPマイクロコントローラと複雑なオペレーティングシステムの両方でマニフェストを持つ実行可能システムの説明を許可する必要があります。さらに、マニフェストフォーマットは、任意のローダーまたはブートローダーによって使用されるカーネルコマンドラインなど、メタデータを表現できる必要があります。
Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11)
満足：user_story.exec.mfst（セクション4.4.11）
Implemented by: Runtime Metadata (Section 3.23)
実装：実行時メタデータ（セクション3.23）
The manifest format MUST enable carrying additional metadata for load-time processing of a payload, such as cryptographic information, load address, and compression algorithm. Note that load comes before execution/boot.
マニフェストフォーマットは、暗号化情報、ロードアドレス、および圧縮アルゴリズムなど、ペイロードのロード時処理のために追加のメタデータを搬送することを可能にしなければならない。ロードは実行/起動前に付属しています。
Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12)
満足：user_story.exec.decompress（セクション4.4.12）
Implemented by: Load-Time Metadata (Section 3.22)
実装：ロードタイムメタデータ（セクション3.22）
The manifest format MUST allow placing a payload in the same structure as the manifest. This may place the payload in the same packet as the manifest.
マニフェスト形式は、マニフェストと同じ構造でペイロードを配置することを許可する必要があります。これにより、ペイロードをマニフェストと同じパケットに配置できます。
Integrated payloads may include, for example, binaries as well as configuration information, and keying material.
統合ペイロードは、例えば、バイナリ、および構成情報、およびキーイング材料を含み得る。
When an integrated payload is provided, this increases the size of the manifest. Manifest size can cause several processing and storage concerns that require careful consideration. The payload can prevent the whole manifest from being contained in a single network packet, which can cause fragmentation and the loss of portions of the manifest in lossy networks. This causes the need for reassembly and retransmission logic. The manifest MUST be held immutable between verification and processing (see REQ.SEC.MFST.CONST (Section 4.3.21)), so a larger manifest will consume more memory with immutability guarantees -- for example, internal RAM or NVRAM, or external secure memory. If the manifest exceeds the available immutable memory, then it MUST be processed modularly, evaluating each of the following: delegation chains; the security container; and the actual manifest, which includes verifying the integrated payload. If the security model calls for downloading the manifest and validating it before storing to NVRAM in order to prevent wear to NVRAM and energy expenditure in NVRAM, then either increasing memory allocated to manifest storage or modular processing of the received manifest may be required. While the manifest has been organized to enable this type of processing, it creates additional complexity in the parser. If the manifest is stored in NVRAM prior to processing, the integrated payload may cause the manifest to exceed the available storage. Because the manifest is received prior to validation of applicability, authority, or correctness, integrated payloads cause the recipient to expend network bandwidth and energy that may not be required if the manifest is discarded, and these costs vary with the size of the integrated payload.
統合ペイロードが提供されると、これはマニフェストのサイズを増加させます。マニフェストサイズは、慎重な検討を必要とするいくつかの処理と保管の懸念を引き起こす可能性があります。ペイロードは、マニフェスト全体が単一のネットワークパケットに含まれているのを防ぐことができ、これは断片化および非可逆ネットワークにおけるマニフェストの部分の損失を引き起こす可能性がある。これにより、再組み立ておよび再送ロジックの必要性が生じる。マニフェストは検証と処理の間で不変に保持されなければなりません（req.sec.mfst.const（セクション4.3.21）を参照）、より大きなマニフェストは不変性の保証でより多くのメモリを消費します - 例えば、内部RAMまたはNVRAM、または外部安全なメモリ。マニフェストが利用可能な不変メモリを超える場合は、次の各々を評価して、モジュール的に処理する必要があります。セキュリティコンテナ。統合ペイロードの検証を含む実際のマニフェスト。 NVRAMのNVRAMおよびエネルギー消費を防止するために、セキュリティモデルがNVRAMおよびNVRAMへの磨耗を防止する前にそれを検証する場合、NVRAMおよびNVRAMにおけるエネルギー消費を防止するために、受信したマニフェストのマニフェストストレージまたはモジュール式処理に割り当てられているメモリを増やすことができる。このタイプの処理を有効にするためにマニフェストが整理されている間、それはパーサーに追加の複雑さを生み出します。マニフェストが処理の前にNVRAMに格納されている場合、統合ペイロードはマニフェストが利用可能なストレージを超える可能性があります。適用性、権限、正当性の検証の前にマニフェストが受信されるため、統合ペイロードは受信者にネットワーク帯域幅とエネルギーを消費し、マニフェストが破棄された場合に必要とされない可能性があるエネルギーが統合されたペイロードのサイズによって異なります。
See also: REQ.SEC.MFST.CONST (Section 4.3.21)
関連項目：req.sec.mfst.const（セクション4.3.21）
Satisfies: USER_STORY.MFST.IMG (Section 4.4.13)
満足：user_story.mfst.img（セクション4.4.13）
Implemented by: Payload (Section 3.24)
Payload（セクション3.24）
The structure of the manifest MUST be simple to parse to reduce the attack vectors against manifest parsers.
マニフェストの構造は、マニフェストパーサーに対する攻撃ベクトルを減らすために解析が簡単でなければなりません。
Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14)
満足：user_story.mfst.parse（セクション4.4.14）
Implemented by: N/A
実施された：N / A.
A manifest format MUST enable the delivery of delegation information. This information delivers a new key with which the recipient can verify the manifest.
マニフェストフォーマットは、委任情報の配信を可能にしなければなりません。この情報は、受信者がマニフェストを検証できる新しいキーを提供します。
Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15)
満足：user_story.mfst.delegation（セクション4.4.15）
Implemented by: Delegation Chain (Section 3.25)
実装：代表団チェーン（セクション3.25）
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.
[RFC4122]リーチ、P.、Mealling、M.、R. Salz、「普遍的にユニークな識別子（UUID）URN名前空間」、RFC 4122、DOI 10.17487 / RFC4122、2005年7月、<https：///www.rfc-editor.org/info/rfc4122>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8392] Jones、M.、Wahlstroem、E.、Erdtman、S.、およびH.Tschofenig、「CBOR Webトークン（CWT）」、RFC 8392、DOI 10.17487 / RFC8392、<https：// www。rfc-editor.org/info/rfc8392>。
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2020, <https://www.rfc-editor.org/info/rfc8747>.
[RFC8747]ジョーンズ、M.、Seitz、L.、Selander、G.、Erdtman、S.、およびH.Tschofenig、「保有事業者Webトークン（CWT）」、RFC 8747、DOI 10.17487/ RFC8747、2020年3月、<https://www.rfc-editor.org/info/rfc8747>。
[RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A Firmware Update Architecture for Internet of Things", RFC 9019, DOI 10.17487/RFC9019, April 2021, <https://www.rfc-editor.org/info/rfc9019>.
[RFC9019] Moran、B.、Tschofenig、H.、Brown、D.、およびM.Meriac、「インターネットのインターネットのファームウェアアップデートアーキテクチャ」、RFC 9019、DOI 10.17487 / RFC9019、2021年4月、<https：//www.rfc-editor.org/info/rfc9019>。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.
[RFC3444] PRAS、A.およびJ.Schoenwaelder、「情報モデルとデータモデルの違い」、RFC 3444、DOI 10.17487 / RFC3444、2003年1月、<https：//www.rfc-editor.org/info/RFC3444>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、 "Uniform Resource Identifier（URI）：汎用構文"、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[STRIDE] Microsoft, "The STRIDE Threat Model", November 2009, <https://docs.microsoft.com/en-us/previous-versions/ commerce-server/ee823878(v=cs.20)>.
[ストライド] Microsoft、「Stride Threat Model」、2009年11月、<https：//docs.microsoft.com/en-us/previous-versions/commerce-server / ee823878（v = cs.20）>。
Acknowledgements
謝辞
We would like to thank our working group chairs -- Dave Thaler, Russ Housley, and David Waltermire -- for their review comments and their support.
私たちの作業グループの椅子 - Dave Thaler、Russ House、そしてDavid Waltermire - レビューのコメントとそのサポートのためにあります。
We would like to thank the participants of the 2018 Berlin Software Updates for Internet of Things (SUIT) Hackathon and the June 2018 virtual design team meetings for their discussion input.
私たちは、インターネットのインターネット（スーツ）ハッカソンと2018年6月の仮想デザインチーム会議のための2018 Berlin Softwareアップデートの参加者に感謝します。
In particular, we would like to thank Koen Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus Gueller, Frank Audun Kvamtrø, Øyvind Rønningstad, Michael Richardson, Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias Wählisch, Max Gröning, Daniel Petry, Gaëtan Harter, Ralph Hamm, Steve Patrick, Fabio Utzig, Paul Lambert, Saïd Gharout, and Milen Stoychev.
特に、Koen Zandberg、Emmanuel Baccelli、Carsten Bormann、David Brown、Markus Gueller、Frank AudunKvamtrø、ØyvindRønningstad、Michael Richardson、Jan-Frederik Rieckers、Anton Gerasimov、Maxgröning、Daniel Petry、GałtanHarter、Ralph Hamm、Steve Patrick、Fabio Utzig、Paul Lambert、Saïdgharout、およびMilen Stoychev。
We would like to thank those who contributed to the development of this information model. In particular, we would like to thank Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Phillips, and Gary Thomson.
この情報モデルの開発に貢献した人に感謝します。特に、Milosch Meriac、Jean-Luc Giroaud、Dan Ros、Amyas Phillips、Gary Thomsonに感謝します。
Finally, we would like to thank the following IESG members for their review feedback: Erik Kline, Murray Kucherawy, Barry Leiba, Alissa Cooper, Stephen Farrell, and Benjamin Kaduk.
最後に、彼らのレビューのフィードバックのために次のIESGメンバーに感謝します：Erik Kline、Murray Kucherawy、Barry Leiba、Alissa Cooper、Stephen Farrell、およびBenjamin Kaduk。
Authors' Addresses
著者の住所
Brendan Moran Arm Limited
Brendan Moran Arm Limited
Email: Brendan.Moran@arm.com
Hannes Tschofenig Arm Limited
Hannes Tschofenig Arm Limited
Email: hannes.tschofenig@gmx.net
Henk Birkholz Fraunhofer SIT
HENK Birkholz Fraunhofer Sit.
Email: henk.birkholz@sit.fraunhofer.de