[要約] 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"、"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を使用して、バージョン5のUniversally Unique 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の例は次のとおりです。ベンダーAは、Vendor ID = 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.
ベンダーAは製品Xを作成します。その後、ベンダーAは製品Xに新機能を追加し、製品X v2を生成します。製品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:
ベンダー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, "Product X")
* YclassId = UUID5(vendorId, "Product Y")
* YclassId = UUID5(vendorId, "Product 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.
製品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として、自社名で販売しています。ベンダーは次のようにクラスIDを作成します。
* vendorIdA = UUID5(DNS, "vendor-a.example")
* vendorIdA = UUID5(DNS, "vendor-a.example")
* classIdA = UUID5(vendorIdA, "Product A-Unlabeled")
* classIdA = UUID5(vendorIdA, "Product A-Unlabeled")
* vendorIdB = UUID5(DNS, "vendor-b.example")
* vendorIdB = UUID5(DNS, "vendor-b.example")
* classIdB = UUID5(vendorIdB, "Product B")
* classIdB = UUID5(vendorIdB, "Product 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の一致を各コンポーネントにスコープすることを選択できます。その場合、vendorIdAおよび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
* 1つのURI
* 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.MULTI_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.CONFIDENTIALITY（セクション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つのファームウェアイメージのうち、どちらが古いかに基づいて、インストールするイメージを選択する必要があります。
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.
委任チェーンは、Proof-of-Possession Key Semantics [RFC8747] を持つ Concise Binary Object Representation (CBOR) Web Tokens [RFC8392] のような認可トークンを介して、拡張された認証機能を提供します。各トークン自体は保護されており、別の保護層を必要としません。各認可トークンには通常、公開鍵または公開鍵のフィンガープリントが含まれていますが、これは使用されるトークンに依存します。各トークンには、キー使用状況情報などの追加メタデータを含めることができます。委任チェーンは署名を検証するために必要であるため、マニフェストではなくマニフェストエンベロープに配置する必要があります。
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:
以下のサブセクションでは、考慮された脅威、それらの脅威から派生したセキュリティ要件、およびセキュリティ要件の実装を可能にするフィールドについての情報を提供することを目的としています。このモデルは、なりすまし、改ざん、否認、情報開示、サービス拒否、および特権昇格 (STRIDE) アプローチ [STRIDE] を使用しています。各脅威は次の点に従って分類されます：
* 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.
ベンダーがファームウェア当局である場合、ベンダー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.
攻撃者は、デバイスがマニフェストの検証を終了した後に新しくダウンロードされたファームウェアを置き換えます。これにより、デバイスが攻撃者のコードを実行する可能性があります。この攻撃には、デバイスへの物理的なアクセスが必要です。ただし、この攻撃はリモート実行を可能にする別の脅威と組み合わせて実行される可能性もあります。これは典型的なTime Of Check / Time Of Use (TOCTOU) 攻撃の典型例です。
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は異なるオペレーターの管理下にあるため、ネットワークA上のデバイス向けファームウェアはネットワーク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.
相互運用する複数のデバイスが同じネットワーク上で使用され、互いに通信します。一部のデバイスはデバイスオペレーターAによって製造および管理され、他のデバイスはデバイスオペレーター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.CONFIDENTIALITY（セクション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.CONFIDENTIALITY（セクション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）
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）
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)
THREAT.IMG.EXPIRED（セクション4.2.1）を軽減します。
Implemented by: Monotonic Sequence Number (Section 3.2)
単調シーケンス番号（セクション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)
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)
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)
ペイロードフォーマット（セクション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)
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)
ペイロードインジケーター（セクション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)
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)
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.UNAPPROVED（セクション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)
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)
THREAT.MFST.OVERRIDE（セクション4.2.13）、THREAT.UPD.UNAPPROVED（セクション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)
THREAT.IMG.EXTRA（セクション4.2.15）を軽減します。
Implemented by: Payload Digests (Section 3.13)
ペイロードダイジェスト（セクション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
セキュアストレージ技術（マニフェストフォーマットの範囲外のシステム設計/実装側面）によって実装されます。
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.MODIFICATION（セクション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.MODIFICATION（セクション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
十分なリソースとTOCTOU攻撃を回避する実装を伴う適切なシステム設計によって実装されます。
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_STORY.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
依存関係、ストレージ識別子、コンポーネント識別子によって実装されます。
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.IMG.UNKNOWN_FORMAT（セクション4.4.8）を満たします。
Implemented by: Payload Format (Section 3.8)
ペイロードフォーマット（セクション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.CONFIDENTIALITY（セクション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に保存すると、統合ペイロードによってマニフェストが利用可能なストレージ容量を超える可能性があります。マニフェストは適用性、権限、または正確性の検証前に受信されるため、統合ペイロードは、マニフェストを破棄した場合には不要なネットワーク帯域幅と電力を受信者に消費させます。これらのコストは、統合ペイロードのサイズによって異なります。
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)
ペイロード（セクション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