< draft-ietf-suit-information-model-09.txt   draft-ietf-suit-information-model-10.txt >
SUIT B. Moran SUIT B. Moran
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Intended status: Informational Arm Limited Intended status: Informational Arm Limited
Expires: August 26, 2021 H. Birkholz Expires: September 20, 2021 H. Birkholz
Fraunhofer SIT Fraunhofer SIT
February 22, 2021 March 19, 2021
A Manifest Information Model for Firmware Updates in IoT Devices A Manifest Information Model for Firmware Updates in IoT Devices
draft-ietf-suit-information-model-09 draft-ietf-suit-information-model-10
Abstract Abstract
Vulnerabilities with Internet of Things (IoT) devices have raised the Vulnerabilities with Internet of Things (IoT) devices have raised the
need for a reliable and secure firmware update mechanism that is also need for a reliable and secure firmware update mechanism that is also
suitable for constrained devices. Ensuring that devices function and suitable for constrained devices. Ensuring that devices function and
remain secure over their service life requires such an update remain secure over their service life requires such an update
mechanism to fix vulnerabilities, to update configuration settings, mechanism to fix vulnerabilities, to update configuration settings,
as well as adding new functionality. as well as adding new functionality.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2021. This Internet-Draft will expire on September 20, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 2. Requirements and Terminology . . . . . . . . . . . . . . . . 6
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Manifest Information Elements . . . . . . . . . . . . . . . . 6 3. Manifest Information Elements . . . . . . . . . . . . . . . . 6
3.1. Version ID of the manifest structure . . . . . . . . . . 7 3.1. Version ID of the Manifest Structure . . . . . . . . . . 7
3.2. Monotonic Sequence Number . . . . . . . . . . . . . . . . 7 3.2. Monotonic Sequence Number . . . . . . . . . . . . . . . . 7
3.3. Vendor ID . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Vendor ID . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 7
3.4. Class ID . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Class ID . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. Example 1: Different Classes . . . . . . . . . . . . 9 3.4.1. Example 1: Different Classes . . . . . . . . . . . . 9
3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 9 3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 9
3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9 3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9
3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 10 3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 10
3.5. Precursor Image Digest Condition . . . . . . . . . . . . 10 3.5. Precursor Image Digest Condition . . . . . . . . . . . . 10
3.6. Required Image Version List . . . . . . . . . . . . . . . 11 3.6. Required Image Version List . . . . . . . . . . . . . . . 10
3.7. Expiration Time . . . . . . . . . . . . . . . . . . . . . 11 3.7. Expiration Time . . . . . . . . . . . . . . . . . . . . . 11
3.8. Payload Format . . . . . . . . . . . . . . . . . . . . . 11 3.8. Payload Format . . . . . . . . . . . . . . . . . . . . . 11
3.9. Processing Steps . . . . . . . . . . . . . . . . . . . . 12 3.9. Processing Steps . . . . . . . . . . . . . . . . . . . . 11
3.10. Storage Location . . . . . . . . . . . . . . . . . . . . 12 3.10. Storage Location . . . . . . . . . . . . . . . . . . . . 12
3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 12 3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 12
3.10.2. Example 2: File System . . . . . . . . . . . . . . . 12 3.10.2. Example 2: File System . . . . . . . . . . . . . . . 12
3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 13 3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 12
3.11. Component Identifier . . . . . . . . . . . . . . . . . . 13 3.11. Component Identifier . . . . . . . . . . . . . . . . . . 12
3.12. Payload Indicator . . . . . . . . . . . . . . . . . . . . 13 3.12. Payload Indicator . . . . . . . . . . . . . . . . . . . . 13
3.13. Payload Digests . . . . . . . . . . . . . . . . . . . . . 13 3.13. Payload Digests . . . . . . . . . . . . . . . . . . . . . 13
3.14. Size . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.14. Size . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.15. Manifest Envelope Element: Signature . . . . . . . . . . 14 3.15. Manifest Envelope Element: Signature . . . . . . . . . . 14
3.16. Additional installation instructions . . . . . . . . . . 15 3.16. Additional Installation Instructions . . . . . . . . . . 14
3.17. Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.17. Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.18. Dependencies . . . . . . . . . . . . . . . . . . . . . . 15 3.18. Dependencies . . . . . . . . . . . . . . . . . . . . . . 15
3.19. Encryption Wrapper . . . . . . . . . . . . . . . . . . . 15 3.19. Encryption Wrapper . . . . . . . . . . . . . . . . . . . 15
3.20. XIP Address . . . . . . . . . . . . . . . . . . . . . . . 16 3.20. XIP Address . . . . . . . . . . . . . . . . . . . . . . . 15
3.21. Load-time metadata . . . . . . . . . . . . . . . . . . . 16 3.21. Load-time Metadata . . . . . . . . . . . . . . . . . . . 15
3.22. Run-time metadata . . . . . . . . . . . . . . . . . . . . 16 3.22. Run-time metadata . . . . . . . . . . . . . . . . . . . . 16
3.23. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.23. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.24. Manifest Envelope Element: Delegation Chain . . . . . . . 17 3.24. Manifest Envelope Element: Delegation Chain . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 18 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 17
4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 18 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 17
4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old 4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old
Firmware . . . . . . . . . . . . . . . . . . . . . . 18 Firmware . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 19 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 18
4.2.4. THREAT.IMG.FORMAT: The target device misinterprets 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets
the type of payload . . . . . . . . . . . . . . . . . 19 the type of payload . . . . . . . . . . . . . . . . . 19
4.2.5. THREAT.IMG.LOCATION: The target device installs the 4.2.5. THREAT.IMG.LOCATION: The target device installs the
payload to the wrong location . . . . . . . . . . . . 20 payload to the wrong location . . . . . . . . . . . . 19
4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic
payload hosting . . . . . . . . . . . . . . . . . . . 20 payload hosting . . . . . . . . . . . . . . . . . . . 19
4.2.7. THREAT.NET.ONPATH: Traffic interception . . . . . . . 20 4.2.7. THREAT.NET.ONPATH: Traffic interception . . . . . . . 20
4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 21 4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 20
4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 21 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 20
4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor
images . . . . . . . . . . . . . . . . . . . . . . . 21 images . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 22 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 21
4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of
Firmware Image for Vulnerability Analysis . . . . . . 23 Firmware Image for Vulnerability Analysis . . . . . . 23
4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest
Elements . . . . . . . . . . . . . . . . . . . . . . 24 Elements . . . . . . . . . . . . . . . . . . . . . . 23
4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element
Exposure . . . . . . . . . . . . . . . . . . . . . . 24 Exposure . . . . . . . . . . . . . . . . . . . . . . 23
4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 24 4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 24
4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 24 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 24
4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or
payload prior to signing . . . . . . . . . . . . . . 25 payload prior to signing . . . . . . . . . . . . . . 24
4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between
authentication and use . . . . . . . . . . . . . . . 25 authentication and use . . . . . . . . . . . . . . . 25
4.3. Security Requirements . . . . . . . . . . . . . . . . . . 26 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 25
4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 26 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 25
4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 26 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 26
4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 26 4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 26
4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 27 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 26
4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 27 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 27
4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC:
Authenticated Storage Location . . . . . . . . . . . 27 Authenticated Storage Location . . . . . . . . . . . 27
4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload 28 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload 27
4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 28 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 27
4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor
images . . . . . . . . . . . . . . . . . . . . . . . 28 images . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and
Class IDs . . . . . . . . . . . . . . . . . . . . . . 28 Class IDs . . . . . . . . . . . . . . . . . . . . . . 28
4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 28 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 28
4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 29 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 28
4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 29 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 29
4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 30 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 29
4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 30 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 29
4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 30 4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 30
4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing
keys . . . . . . . . . . . . . . . . . . . . . . . . 30 keys . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to
deployment . . . . . . . . . . . . . . . . . . . . . 31 deployment . . . . . . . . . . . . . . . . . . . . . 30
4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a
trusted environment . . . . . . . . . . . . . . . . . 31 trusted environment . . . . . . . . . . . . . . . . . 30
4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between 4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between
check and use . . . . . . . . . . . . . . . . . . . . 31 check and use . . . . . . . . . . . . . . . . . . . . 30
4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 31 4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 31
4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation
Instructions . . . . . . . . . . . . . . . . . . . . 31 Instructions . . . . . . . . . . . . . . . . . . . . 31
4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 32 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 31
4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest
Elements . . . . . . . . . . . . . . . . . . . . . . 32 Elements . . . . . . . . . . . . . . . . . . . . . . 32
4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 33 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 32
4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations . . . 33 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations . . . 32
4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 33 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 33
4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential
Information Disclosures . . . . . . . . . . . . . . . 33 Information Disclosures . . . . . . . . . . . . . . . 33
4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from
Unpacking Unknown Formats . . . . . . . . . . . . . . 33 Unpacking Unknown Formats . . . . . . . . . . . . . . 33
4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version
Numbers of Target Firmware . . . . . . . . . . . . . 34 Numbers of Target Firmware . . . . . . . . . . . . . 33
4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose
Between Images . . . . . . . . . . . . . . . . . . . 34 Between Images . . . . . . . . . . . . . . . . . . . 34
4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using
Manifests . . . . . . . . . . . . . . . . . . . . . . 34 Manifests . . . . . . . . . . . . . . . . . . . . . . 34
4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 34 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 34
4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 35 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 34
4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 35 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 34
4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in
Manifest . . . . . . . . . . . . . . . . . . . . . . 35 Manifest . . . . . . . . . . . . . . . . . . . . . . 35
4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 35 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 35
4.5. Usability Requirements . . . . . . . . . . . . . . . . . 35 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 35
4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 35 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 35
4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote
Resource Location . . . . . . . . . . . . . . . . . . 36 Resource Location . . . . . . . . . . . . . . . . . . 35
4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 36 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 36
4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 37 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 37
4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 37 4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 37
4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 38 4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 37
4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 38 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 38
4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 38 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 38
4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 38 4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 38
4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 39 4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 38
4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope . . . . 39 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope . . . . 38
4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 40 4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 39
4.5.13. REQ.USE.DELEGATION: Delegation of Authority in 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in
Manifest . . . . . . . . . . . . . . . . . . . . . . 40 Manifest . . . . . . . . . . . . . . . . . . . . . . 40
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. Normative References . . . . . . . . . . . . . . . . . . 41 7.1. Normative References . . . . . . . . . . . . . . . . . . 40
7.2. Informative References . . . . . . . . . . . . . . . . . 41 7.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
Vulnerabilities with Internet of Things (IoT) devices have raised the Vulnerabilities with Internet of Things (IoT) devices have raised the
need for a reliable and secure firmware update mechanism that is also need for a reliable and secure firmware update mechanism that is also
suitable for constrained devices. Ensuring that devices function and suitable for constrained devices. Ensuring that devices function and
remain secure over their service life requires such an update remain secure over their service life requires such an update
mechanism to fix vulnerabilities, to update configuration settings, mechanism to fix vulnerabilities, to update configuration settings,
as well as adding new functionality. as well as adding new functionality.
skipping to change at page 5, line 41 skipping to change at page 5, line 41
element is motiviated by user stories and threats it aims to element is motiviated by user stories and threats it aims to
mitigate. These threats and user stories are not intended to be an mitigate. These threats and user stories are not intended to be an
exhaustive list of the threats against IoT devices, nor of the exhaustive list of the threats against IoT devices, nor of the
possible user stories that describe how to conduct a firmware update. possible user stories that describe how to conduct a firmware update.
Instead they are intended to describe the threats against firmware Instead they are intended to describe the threats against firmware
updates in isolation and provide sufficient motivation to specify the updates in isolation and provide sufficient motivation to specify the
information elements that cover a wide range of user stories. information elements that cover a wide range of user stories.
To distinguish information elements from their encoding and To distinguish information elements from their encoding and
serialization over the wire this document presents an information serialization over the wire this document presents an information
model. model. RFC 3444 [RFC3444] describes the differences between
information and data models.
Because this document covers a wide range of user stories and a wide Because this document covers a wide range of user stories and a wide
range of threats, not all information elements apply to all range of threats, not all information elements apply to all
scenarios. As a result, various information elements are optional to scenarios. As a result, various information elements are optional to
implement and optional to use, depending on which threats exist in a implement and optional to use, depending on which threats exist in a
particular domain of application and which user stories are important particular domain of application and which user stories are important
for deployments. for deployments.
Elements marked as REQUIRED provide baseline security and usability 2. Requirements and Terminology
properties that are expected to be required to be implemented for
most applications. Elements marked as RECOMMENDED provide important
security or usability properties that are needed on most devices.
Elements marked as OPTIONAL enable security or usability properties
that are useful in some applications.
2. Conventions and Terminology 2.1. Requirements Notation
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.
Unless otherwise stated these words apply to the design of the
manifest format, not its implementation or application. Hence,
whenever an information is declared as "REQUIRED" this implies that
the manifest format document has to include support for it.
2.2. Terminology
This document uses terms defined in [I-D.ietf-suit-architecture]. This document uses terms defined in [I-D.ietf-suit-architecture].
The term 'Operator' refers to both Device and Network Operator. The term 'Operator' refers to both Device and Network Operator.
Secure time and secure clock refer to a set of requirements on time Secure time and secure clock refer to a set of requirements on time
sources. For local time sources, this primarily means that the clock sources. For local time sources, this primarily means that the clock
must be monotonically increasing, including across power cycles, must be monotonically increasing, including across power cycles,
firmware updates, etc. For remote time sources, the provided time firmware updates, etc. For remote time sources, the provided time
must be guaranteed to be correct to within some predetermined bounds, must be guaranteed to be correct to within some predetermined bounds,
whenever the time source is accessible. whenever the time source is accessible.
skipping to change at page 6, line 32 skipping to change at page 6, line 43
bundling of a manifest with related information elements that are not bundling of a manifest with related information elements that are not
directly contained within the manifest. directly contained within the manifest.
The term Payload is used to describe the data that is delivered to a 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", device during an update. This is distinct from a "firmware image",
as described in [I-D.ietf-suit-architecture], because the payload is as described in [I-D.ietf-suit-architecture], because the payload is
often in an intermediate state, such as being encrypted, compressed often in an intermediate state, such as being encrypted, compressed
and/or encoded as a differential update. The payload, taken in and/or encoded as a differential update. The payload, taken in
isolation, is often not the final firmware image. isolation, is often not the final firmware image.
2.1. Requirements Notation
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.
Unless otherwise stated these words apply to the design of the
manifest format, not its implementation or application.
3. Manifest Information Elements 3. Manifest Information Elements
Each manifest information element is anchored in a security Each manifest information element is anchored in a security
requirement or a usability requirement. The manifest elements are requirement or a usability requirement. The manifest elements are
described below, justified by their requirements. described below, justified by their requirements.
3.1. Version ID of the manifest structure 3.1. Version ID of the Manifest Structure
An identifier that describes which iteration of the manifest format An identifier that describes which iteration of the manifest format
is contained in the structure. 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 to be implemented to allow devices to This element is REQUIRED.
identify the version of the manifest data model that is in use.
3.2. Monotonic Sequence Number 3.2. Monotonic Sequence Number
A monotonically increasing sequence number. For convenience, the A monotonically increasing sequence number to prevent malicious
monotonic sequence number MAY be a UTC timestamp. This allows global actors from reverting a firmware update against the policies of the
synchronisation of sequence numbers without any additional relevant authority.
management. This number MUST be possible to extract with a simple,
minimal parser so that code choosing one out of several manifests can
choose which is the latest without fully parsing a complex structure.
This element is REQUIRED to be implemented and is necessary to For convenience, the monotonic sequence number may be a UTC
prevent malicious actors from reverting a firmware update against the timestamp. This allows global synchronisation of sequence numbers
policies of the relevant authority. without any additional management.
This element is REQUIRED.
Implements: REQ.SEC.SEQUENCE (Section 4.3.1) Implements: REQ.SEC.SEQUENCE (Section 4.3.1)
3.3. Vendor ID 3.3. Vendor ID
Vendor IDs must be unique. This is to prevent similarly, or The Vendor ID element helps to distinguish between identically named
identically named entities from different geographic regions from products from different vendors. Vendor ID is not intended to be a
colliding in their customer's infrastructure. Recommended practice human-readable element. It is intended for binary match/mismatch
is to use [RFC4122] version 5 UUIDs with the vendor's domain name and comparison only.
the DNS name space ID. Other options include type 1 and type 4
UUIDs.
Vendor ID is not intended to be a human-readable element. It is Recommended practice is to use [RFC4122] version 5 UUIDs with the
intended for binary match/mismatch comparison only. vendor's domain name and the DNS name space ID. Other options
include type 1 and type 4 UUIDs.
The use of a Vendor ID is RECOMMENDED. It helps to distinguish This element is RECOMMENDED.
between identically named products from different vendors.
Implements: REQ.SEC.COMPATIBLE (Section 4.3.2), Implements: REQ.SEC.COMPATIBLE (Section 4.3.2),
REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10).
3.3.1. Example: Domain Name-based UUIDs 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 =
Vendor A creates a UUID based on a domain name it controls, such as UUID5(DNS, "vendor-a.example")
vendorId = UUID5(DNS, "vendor-a.example")
Because the DNS infrastructure prevents multiple registrations of the Because the DNS infrastructure prevents multiple registrations of the
same domain name, this UUID is (with very high probability) same domain name, this UUID is (with very high probability)
guaranteed to be unique. Because the domain name is known, this UUID guaranteed to be unique. Because the domain name is known, this UUID
is reproducible. Type 1 and type 4 UUIDs produce similar guarantees is reproducible. Type 1 and type 4 UUIDs produce similar guarantees
of uniqueness, but not reproducibility. of uniqueness, but not reproducibility.
This approach creates a contention when a vendor changes its name or This approach creates a contention when a vendor changes its name or
relinquishes control of a domain name. In this scenario, it is relinquishes control of a domain name. In this scenario, it is
possible that another vendor would start using that same domain name. 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 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. vendor must be anchored in a cryptographic key, not a UUID.
3.4. Class ID 3.4. Class ID
A device "Class" is a set of different device types that can accept A device "Class" is a set of different device types that can accept
the same firmware update without modification. Class IDs MUST be the same firmware update without modification. It thereby allows
unique within the scope of a Vendor ID. This is to prevent devices to determine applicability of a firmware in an unambiguous
similarly, or identically named devices colliding in their customer's way. Class IDs must be unique within the scope of a Vendor ID. This
infrastructure. is to prevent similarly, or identically named devices colliding in
their customer's infrastructure.
Recommended practice is to use [RFC4122] version 5 UUIDs with as much Recommended practice is to use [RFC4122] version 5 UUIDs with as much
information as necessary to define firmware compatibility. Possible information as necessary to define firmware compatibility. Possible
information used to derive the class UUID includes: information used to derive the class UUID includes:
o model name or number o model name or number
o hardware revision o hardware revision
o runtime library version o runtime library version
o bootloader version o bootloader version
o ROM revision o ROM revision
o silicon batch number o silicon batch number
The Class Identifier UUID SHOULD use the Vendor ID as the name space The Class ID UUID should use the Vendor ID as the name space
ID. Other options include version 1 and 4 UUIDs. Classes MAY be identifier. Other options include version 1 and 4 UUIDs. Classes
more fine-grained granular than is required to identify firmware may be more fine-grained granular than is required to identify
compatibility. Classes MUST NOT be less granular than is required to firmware compatibility. Classes must not be less granular than is
identify firmware compatibility. Devices MAY have multiple Class required to identify firmware compatibility. Devices may have
IDs. multiple Class IDs.
Class ID is not intended to be a human-readable element. It is Class ID is not intended to be a human-readable element. It is
intended for binary match/mismatch comparison only. intended for binary match/mismatch comparison only.
The use of Class ID is RECOMMENDED. It allows devices to determine If Class ID is not implemented, then each logical device class must
applicability of a firmware in an unambiguous way.
If Class ID is not implemented, then each logical device class MUST
use a unique trust anchor for authorization. use a unique trust anchor for authorization.
This element is RECOMMENDED.
Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2), Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2),
REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10).
3.4.1. Example 1: Different Classes 3.4.1. Example 1: Different Classes
Vendor A creates product Z and product Y. The firmware images of Vendor A creates product Z and product Y. The firmware images of
products Z and Y are not interchangeable. Vendor A creates UUIDs as products Z and Y are not interchangeable. Vendor A creates UUIDs as
follows: follows:
o vendorId = UUID5(DNS, "vendor-a.com") o vendorId = UUID5(DNS, "vendor-a.com")
skipping to change at page 10, line 34 skipping to change at page 10, line 27
o vendorIdA = UUID5(DNS, "vendor-a.com") o vendorIdA = UUID5(DNS, "vendor-a.com")
o classIdA = UUID5(vendorIdA, "Product A-Unlabelled") o classIdA = UUID5(vendorIdA, "Product A-Unlabelled")
o vendorIdB = UUID5(DNS, "vendor-b.com") o vendorIdB = UUID5(DNS, "vendor-b.com")
o classIdB = UUID5(vendorIdB, "Product B") o classIdB = UUID5(vendorIdB, "Product B")
The product will match against each of these class IDs. If Vendor A The product will match against each of these class IDs. If Vendor A
and Vendor B provide different components for the device, the and Vendor B provide different components for the device, the
implementor MAY choose to make ID matching scoped to each component. implementor may choose to make ID matching scoped to each component.
Then, the vendorIdA, classIdA match the component ID supplied by Then, the vendorIdA, classIdA match the component ID supplied by
Vendor A, and the vendorIdB, classIdB match the component ID supplied Vendor A, and the vendorIdB, classIdB match the component ID supplied
by Vendor B. by Vendor B.
3.5. Precursor Image Digest Condition 3.5. Precursor Image Digest Condition
When a precursor image is required by the payload format (for This element provides information about the payload that needs to be
example, differential updates), a precursor image digest condition present on the device for an update to apply. This may, for example,
MUST be present. The precursor image MAY be installed or stored as a be the case with differential updates.
candidate.
This element is OPTIONAL to implement. This element is OPTIONAL.
Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9)
3.6. Required Image Version List 3.6. Required Image Version List
Payloads may only be applied to a specific firmware version or Payloads may only be applied to a specific firmware version or
firmware versions. For example, a payload containing a differential firmware versions. For example, a payload containing a differential
update may be applied only to a specific firmware version. update may be applied only to a specific firmware version.
When a payload applies to multiple versions of a firmware, the When a payload applies to multiple versions of a firmware, the
required image version list specifies which firmware versions must be required image version list specifies which firmware versions must be
present for the update to be applied. This allows the update author present for the update to be applied. This allows the update author
to target specific versions of firmware for an update, while to target specific versions of firmware for an update, while
excluding those to which it should not or cannot be applied. excluding those to which it should not or cannot be applied.
This element is OPTIONAL to implement. This element is OPTIONAL.
Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7) Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7)
3.7. Expiration Time 3.7. Expiration Time
This element tells a device the time at which the manifest expires 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 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 secure source of time is provided and firmware is intended to expire
predictably. This element may also be displayed (e.g. via an app) predictably. This element may also be displayed (e.g. via an app)
for user confirmation since users typically have a reliable knowledge for user confirmation since users typically have a reliable knowledge
of the date. of the date.
Special consideration is required for end-of-life if a firmware will Special consideration is required for end-of-life if a firmware will
not be updated again, for example if a business stops issuing updates 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 to a device. In this case the last valid firmware should not have an
expiration time. expiration time.
This element is OPTIONAL to implement. This element is OPTIONAL.
Implements: REQ.SEC.EXP (Section 4.3.3) Implements: REQ.SEC.EXP (Section 4.3.3)
3.8. Payload Format 3.8. Payload Format
The format of the payload MUST be indicated to devices in an This element describes the payload format within the signed metadata.
unambiguous way. This element provides a mechanism to describe the It is used to enable devices to decode payloads correctly.
payload format, within the signed metadata.
This element is REQUIRED to be implemented and MUST be used to enable This element is REQUIRED.
devices to decode payloads correctly.
Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT Implements: REQ.SEC.AUTH.IMG_TYPE (Section 4.3.5), REQ.USE.IMG.FORMAT
(Section 4.5.5) (Section 4.5.5)
3.9. Processing Steps 3.9. Processing Steps
A representation of the Processing Steps required to decode a A representation of the Processing Steps required to decode a
payload, in particular those that are compressed, packed, or payload, in particular those that are compressed, packed, or
encrypted. The representation MUST describe which algorithm(s) is encrypted. The representation must describe which algorithms are
used and any additional parameters required by the algorithm(s). The used and must convey any additional parameters required by those
representation MAY group Processing Steps together in predefined algorithms.
combinations.
A Processing Step MAY indicate the expected digest of the payload A Processing Step may indicate the expected digest of the payload
after the processing is complete. after the processing is complete.
Processing steps are RECOMMENDED to implement. This element is RECOMMENDED.
Implements: REQ.USE.IMG.NESTED (Section 4.5.6) Implements: REQ.USE.IMG.NESTED (Section 4.5.6)
3.10. Storage Location 3.10. Storage Location
This element tells the device where to store a payload within a given This element tells the device where to store a payload within a given
component. The device can use this to establish which permissions component. The device can use this to establish which permissions
are necessary and the physical storage location to use. are necessary and the physical storage location to use.
This element is REQUIRED to be implemented and MUST be present to This element is REQUIRED.
enable devices to store payloads to the correct location.
Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6)
3.10.1. Example 1: Two Storage Locations 3.10.1. Example 1: Two Storage Locations
A device supports two components: an OS and an application. These A device supports two components: an OS and an application. These
components can be updated independently, expressing dependencies to components can be updated independently, expressing dependencies to
ensure compatibility between the components. The Author chooses two ensure compatibility between the components. The Author chooses two
storage identifiers: storage identifiers:
skipping to change at page 13, line 14 skipping to change at page 12, line 44
3.10.3. Example 3: Flash Memory 3.10.3. Example 3: Flash Memory
A device supports flash memory. The Author chooses to make the A device supports flash memory. The Author chooses to make the
storage identifier the offset where the image should be written. storage identifier the offset where the image should be written.
3.11. Component Identifier 3.11. Component Identifier
In a device with more than one storage subsystem, a storage In a device with more than one storage subsystem, a storage
identifier is insufficient to identify where and how to store a identifier is insufficient to identify where and how to store a
payload. To resolve this, a component identifier indicates which payload. To resolve this, a component identifier indicates to which
part of the storage architecture is targeted by the payload. part of the storage subsystem the payload shall be placed.
This element is OPTIONAL to implement and only necessary in devices A serialization may choose to combine Component Identifier and
with multiple storage subsystems. Storage Location (Section 3.10).
N.B. A serialization MAY choose to combine Component Identifier and This element is OPTIONAL.
Storage Location (Section 3.10)
Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3)
3.12. Payload Indicator 3.12. Payload Indicator
This element provides the information required for the device to This element provides the information required for the device to
acquire the payload. This can be encoded in several ways: 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:
o One URI o One URI
o A list of URIs o A list of URIs
o A prioritised list of URIs o A prioritised list of URIs
o A list of signed URIs o A list of signed URIs
This element is OPTIONAL to implement and only needed when the target This element is OPTIONAL.
device does not intrinsically know where to find the payload.
N.B. Devices will typically require URIs.
Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) Implements: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7)
3.13. Payload Digests 3.13. Payload Digests
This element contains one or more digests of one or more payloads. This element contains one or more digests of one or more payloads.
This allows the target device to ensure authenticity of the This allows the target device to ensure authenticity of the
payload(s). A manifest format MUST provide a mechanism to select one payload(s) when combined with the Signature (Section 3.15) element.
payload from a list based on system parameters, such as Execute-In- A manifest format must provide a mechanism to select one payload from
Place Installation Address. a list based on system parameters, such as Execute-In-Place
Installation Address.
This element is REQUIRED to be implemented and necessary to ensure This element is REQUIRED. Support for more than one digest is
the authenticity and integrity of the payload. Support for more than OPTIONAL.
one digest is OPTIONAL to implement in a recipient device.
Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.USE.IMG.SELECT
(Section 4.5.8) (Section 4.5.8)
3.14. Size 3.14. Size
The size of the payload in bytes. 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
Variable-size storage locations MUST be set to exactly the size classes of denial of service attack.
listed in this element.
This element is REQUIRED to be implemented and informs the target This element is REQUIRED.
device how big of a payload to expect. Without it, devices are
exposed to some classes of denial of service attack.
Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8) Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8)
3.15. Manifest Envelope Element: Signature 3.15. Manifest Envelope Element: Signature
The Signature element MUST contain all the information necessary to The Signature element contains all the information necessary to
cryptographically verify the contents of the manifest against a root protect the contents of the manifest against modification and to
of trust. Because the Signature element authenticates the manifest, offer authentication of the signer. Because the Signature element
it cannot be contained within the manifest. Instead, the manifest is authenticates the manifest, it cannot be contained within the
either contained within the signature element, or the signature manifest. Instead, the manifest is either contained within the
element is a member of the Manifest Envelope and bundled with the signature element, or the signature element is a member of the
manifest. Manifest Envelope and bundled with the manifest.
The Signature element MUST support multiple signers and multiple The Signature element represents the foundation of all security
signing algorithms. It is OPTIONAL for a serialization to properties of the manifest. Manifests, which are included as
authenticate multiple manifests with a single Signature element. dependencies by another manifests, should include a signature so that
the recipient can distinguish between different actors with different
permissions.
This element is REQUIRED to be implemented in non-dependency The Signature element must support multiple signers and multiple
manifests and represents the foundation of all security properties of signing algorithms. A manifest format may allow multiple manifests
the manifest. Manifests, which are included as dependencies by to be covered by a single Signature element.
another manifests, SHOULD include a signature so that the recipient
can distinguish between different actors with different permissions.
The design of the manifest security framework MUST NOT rely on This element is REQUIRED in non-dependency manifests.
channel security. Where public key operations require too many
resources, the use of message authentication codes is RECOMMENDED
with a per-device symmetric key.
Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS Implements: REQ.SEC.AUTHENTIC (Section 4.3.4), REQ.SEC.RIGHTS
(Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4) (Section 4.3.11), REQ.USE.MFST.MULTI_AUTH (Section 4.5.4)
3.16. Additional installation instructions 3.16. Additional Installation Instructions
Machine-readable instructions that the device should execute when Additional installation instructions are machine-readable commands
processing the manifest. This information is distinct from the the device should execute when processing the manifest. This
information necessary to process a payload. Additional installation information is distinct from the information necessary to process a
instructions include information such as update timing (for example, payload. Additional installation instructions include information
install only on Sunday, at 0200), procedural considerations (for such as update timing (for example, install only on Sunday, at 0200),
example, shut down the equipment under control before executing the procedural considerations (for example, shut down the equipment under
update), pre- and post-installation steps (for example, run a control before executing the update), pre- and post-installation
script). Other installation instructions could include requesting steps (for example, run a script). Other installation instructions
user confirmation before installing. could include requesting user confirmation before installing.
This element is OPTIONAL to implement. This element is OPTIONAL.
Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
3.17. Aliases 3.17. Aliases
A mechanism for a manifest to augment or replace URIs or URI lists A mechanism for a manifest to augment or replace URIs or URI lists
defined by one or more of its dependencies. defined by one or more of its dependencies.
This element is OPTIONAL to implement and enables some user stories. This element is OPTIONAL.
Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2)
3.18. Dependencies 3.18. Dependencies
A list of other manifests that are required by the current manifest. A list of other manifests that are required by the current manifest.
Manifests are identified an unambiguous way, such as a cryptographic Manifests are identified an unambiguous way, such as a cryptographic
digest. digest.
This element is REQUIRED to use in deployments that include both This element is REQUIRED to support deployments that include both
multiple authorities and multiple payloads. multiple authorities and multiple payloads.
Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3)
3.19. Encryption Wrapper 3.19. Encryption Wrapper
Encrypting firmware images requires symmetric content encryption Encrypting firmware images requires symmetric content encryption
keys. The encryption wrapper provides the information needed for a keys. The encryption wrapper provides the information needed for a
device to obtain or locate a key that it uses to decrypt the device to obtain or locate a key that it uses to decrypt the
firmware. This MAY be included in a decryption step contained in firmware.
Processing Steps (Section 3.9).
This element is REQUIRED to use for encrypted payloads, This element is REQUIRED for encrypted payloads.
Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)
3.20. XIP Address 3.20. XIP Address
In order to support execute in place (XIP) systems with multiple In order to support execute in place (XIP) systems with multiple
possible base addresses, it is necessary to specify which address the possible base addresses, it is necessary to specify which address the
payload is linked for. payload is linked for.
For example a microcontroller may have a simple bootloader that For example a microcontroller may have a simple bootloader that
chooses one of two images to boot. That microcontroller then needs chooses one of two images to boot. That microcontroller then needs
to choose one of two firmware images to install, based on which of to choose one of two firmware images to install, based on which of
its two images is older. its two images is older.
This element is OPTIONAL to implement. This element is OPTIONAL.
Implements: REQ.USE.IMG.SELECT (Section 4.5.8) Implements: REQ.USE.IMG.SELECT (Section 4.5.8)
3.21. Load-time metadata 3.21. Load-time Metadata
Load-time metadata provides the device with information that it needs Load-time metadata provides the device with information that it needs
in order to load one or more images. This metadata MAY include any in order to load one or more images. This metadata may include any
of: of:
o the source o the source
o the destination o the destination
o cryptographic information o cryptographic information
o decompression information o decompression information
o unpacking information o unpacking information
Typically, loading is done by copying an image from its permanent Typically, loading is done by copying an image from its permanent
storage location into its active use location. The metadata allows storage location into its active use location. The metadata allows
operations such as decryption, decompression, and unpacking to be operations such as decryption, decompression, and unpacking to be
performed during that copy. performed during that copy.
This element is OPTIONAL to implement. This element is OPTIONAL.
Implements: REQ.USE.LOAD (Section 4.5.10) Implements: REQ.USE.LOAD (Section 4.5.10)
3.22. Run-time metadata 3.22. Run-time metadata
Run-time metadata provides the device with any extra information Run-time metadata provides the device with any extra information
needed to boot the device. This may include information such as the needed to boot the device. This may include the entry-point of an
entry-point of an XIP image or the kernel command-line of a Linux XIP image or the kernel command-line to boot a Linux image.
image.
This element is OPTIONAL to implement. This element is OPTIONAL.
Implements: REQ.USE.EXEC (Section 4.5.9) Implements: REQ.USE.EXEC (Section 4.5.9)
3.23. Payload 3.23. Payload
The Payload element is contained within the manifest or manifest The Payload element is contained within the manifest or manifest
envelope. This enables the manifest and payload to be delivered envelope and enables the manifest and payload to be delivered
simultaneously. Typically this is used for delivering small payloads simultaneously. This is used for delivering small payloads, such as
such as cryptographic keys, or configuration data. cryptographic keys or configuration data.
This element is OPTIONAL to implement. This element is OPTIONAL.
Implements: REQ.USE.PAYLOAD (Section 4.5.11) Implements: REQ.USE.PAYLOAD (Section 4.5.11)
3.24. Manifest Envelope Element: Delegation Chain 3.24. Manifest Envelope Element: Delegation Chain
It is OPTIONAL for the Signature (Section 3.15) to cover the The delegation chain offers enhanced authorization functionality via
delegation chain. The delegation chain offers enhanced authorization authorization tokens. Each token itself is protected and does not
functionality via authorization tokens. Each token itself is require another layer of protection. Because the delegation chain is
protected and does not require another layer of protection. Because needed to verify the signature, it must be placed in the Manifest
the delegation chain is needed to verify the signature, it must be Envelope, rather than the Manifest.
placed in the Manifest Envelope, rather than the Manifest.
This element is OPTIONAL to implement. This element is OPTIONAL.
Implements: REQ.USE.DELEGATION (Section 4.5.13) Implements: REQ.USE.DELEGATION (Section 4.5.13)
4. Security Considerations 4. Security Considerations
The following sub-sections describe the threat model, user stories, The following sub-sections describe the threat model, user stories,
security requirements, and usability requirements. This section also security requirements, and usability requirements. This section also
provides the motivations for each of the manifest information provides the motivations for each of the manifest information
elements. elements.
skipping to change at page 19, line 26 skipping to change at page 18, line 49
device, signed by an actor with firmware installation permission on device, signed by an actor with firmware installation permission on
both types of device. The firmware is verified by the device both types of device. The firmware is verified by the device
positively because it is signed by an actor with the appropriate positively because it is signed by an actor with the appropriate
permission. This could have wide-ranging consequences. For devices permission. This could have wide-ranging consequences. For devices
that are similar, it could cause minor breakage, or expose security that are similar, it could cause minor breakage, or expose security
vulnerabilities. For devices that are very different, it is likely vulnerabilities. For devices that are very different, it is likely
to render devices inoperable. to render devices inoperable.
Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2) Mitigated by: REQ.SEC.COMPATIBLE (Section 4.3.2)
4.2.3.1. Example: For example, suppose that two vendors, Vendor A and Vendor B, adopt
the same trade name in different geographic regions, and they both
Suppose that two vendors, Vendor A and Vendor B, adopt the same trade make products with the same names, or product name matching is not
name in different geographic regions, and they both make products used. This causes firmware from Vendor A to match devices from
with the same names, or product name matching is not used. This Vendor B.
causes firmware from Vendor A to match devices from Vendor B.
If the vendors are the firmware authorities, then devices from Vendor If the vendors are the firmware authorities, then devices from Vendor
A will reject images signed by Vendor B since they use different A will reject images signed by Vendor B since they use different
credentials. However, if both devices trust the same Author, then, credentials. However, if both devices trust the same Author, then,
devices from Vendor A could install firmware intended for devices devices from Vendor A could install firmware intended for devices
from Vendor B. from Vendor B.
4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of
payload payload
skipping to change at page 20, line 27 skipping to change at page 19, line 49
Threat Escalation: An attacker that can cause a device to Threat Escalation: An attacker that can cause a device to
misinterpret the received code may gain elevation of privilege and misinterpret the received code may gain elevation of privilege and
potentially expand this to all types of threat. potentially expand this to all types of threat.
Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) Mitigated by: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6)
4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting
Classification: Denial of Service Classification: Denial of Service
If a device does not know where to obtain the payload for an update, If a device is tricked into fetching a payload for an attacker
it may be redirected to an attacker's server. This would allow an controlled site, the attacker may send corrupted payloads to devices.
attacker to provide broken payloads to devices.
Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7)
4.2.7. THREAT.NET.ONPATH: Traffic interception 4.2.7. THREAT.NET.ONPATH: Traffic interception
Classification: Spoofing Identity, Tampering with Data Classification: Spoofing Identity, Tampering with Data
An attacker intercepts all traffic to and from a device. The An attacker intercepts all traffic to and from a device. The
attacker can monitor or modify any data sent to or received from the attacker can monitor or modify any data sent to or received from the
device. This can take the form of: manifests, payloads, status device. This can take the form of: manifests, payloads, status
skipping to change at page 21, line 14 skipping to change at page 20, line 33
4.2.8. THREAT.IMG.REPLACE: Payload Replacement 4.2.8. THREAT.IMG.REPLACE: Payload Replacement
Classification: Elevation of Privilege Classification: Elevation of Privilege
An attacker replaces a newly downloaded firmware after a device An attacker replaces a newly downloaded firmware after a device
finishes verifying a manifest. This could cause the device to finishes verifying a manifest. This could cause the device to
execute the attacker's code. This attack likely requires physical execute the attacker's code. This attack likely requires physical
access to the device. However, it is possible that this attack is access to the device. However, it is possible that this attack is
carried out in combination with another threat that allows remote carried out in combination with another threat that allows remote
execution. This is a typical Time Of Check/Time Of Use threat. execution. This is a typical Time Of Check/Time Of Use (TICTOC)
attack.
Threat Escalation: If the attacker is able to exploit a known Threat Escalation: If the attacker is able to exploit a known
vulnerability, or if the attacker can supply their own firmware, then vulnerability, or if the attacker can supply their own firmware, then
this threat can be escalated to ALL TYPES. this threat can be escalated to ALL TYPES.
Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8) Mitigated by: REQ.SEC.AUTH.EXEC (Section 4.3.8)
4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images
Classification: Elevation of Privilege / All Types Classification: Elevation of Privilege / All Types
skipping to change at page 21, line 36 skipping to change at page 21, line 9
If an attacker can install their firmware on a device, for example by If an attacker can install their firmware on a device, for example by
manipulating either payload or metadata, then they have complete manipulating either payload or metadata, then they have complete
control of the device. control of the device.
Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4) Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4)
4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor images
Classification: Denial of Service / All Types 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 An attacker sends a valid, current manifest to a device that has an
unexpected precursor image. If a payload format requires a precursor unexpected precursor image. If a payload format requires a precursor
image (for example, delta updates) and that precursor image is not image (for example, delta updates) and that precursor image is not
available on the target device, it could cause the update to break. 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 An attacker that can cause a device to install a payload against the
wrong precursor image could gain elevation of privilege and wrong precursor image could gain elevation of privilege and
potentially expand this to all types of threat. However, it is potentially expand this to all types of threat. However, it is
unlikely that a valid differential update applied to an incorrect unlikely that a valid differential update applied to an incorrect
precursor would result in a functional, but vulnerable firmware. precursor would result in a functional, but vulnerable firmware.
skipping to change at page 22, line 27 skipping to change at page 21, line 47
the ability to modify device behaviour without approval, then this the ability to modify device behaviour without approval, then this
constitutes an elevation of privilege. constitutes an elevation of privilege.
Similarly, a Network Operator may require that devices behave in a Similarly, a Network Operator may require that devices behave in a
particular way in order to maintain the integrity of the network. If particular way in order to maintain the integrity of the network. If
devices behaviour on a network can be modified without the approval devices behaviour on a network can be modified without the approval
of the Network Operator, then this constitutes an elevation of of the Network Operator, then this constitutes an elevation of
privilege with respect to the network. privilege with respect to the network.
For example, if the owner of a device has purchased that device For example, if the owner of a device has purchased that device
because of Features A, B, and C, and a firmware update is issued by because of features A, B, and C, and a firmware update is issued by
the manufacturer, which removes Feature A, then the device may not the manufacturer, which removes feature A, then the device may not
fulfill the owner's requirements any more. In certain circumstances, fulfill the owner's requirements any more. In certain circumstances,
this can cause significantly greater threats. Suppose that Feature A this can cause significantly greater threats. Suppose that feature A
is used to implement a safety-critical system, whether the is used to implement a safety-critical system, whether the
manufacturer intended this behaviour or not. When unapproved manufacturer intended this behaviour or not. When unapproved
firmware is installed, the system may become unsafe. firmware is installed, the system may become unsafe.
In a second example, the owner or operator of a system of two or more 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 interoperating devices needs to approve firmware for their system in
order to ensure interoperability with other devices in the system. order to ensure interoperability with other devices in the system.
If the firmware is not qualified, the system as a whole may not work. 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 Therefore, if a device installs firmware without the approval of the
device owner or operator, this is a threat to devices or the system device owner or operator, this is a threat to devices or the system
skipping to change at page 24, line 49 skipping to change at page 24, line 22
after a valid, authentic image, that third party can then use their after a valid, authentic image, that third party can then use their
own code in order to make better use of an existing vulnerability. own code in order to make better use of an existing vulnerability.
Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15) Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15)
4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys
Classification: All Types Classification: All Types
If a third party obtains a key or even indirect access to a key, for If a third party obtains a key or even indirect access to a key, for
example in an HSM, then they can perform the same actions as the example in an hardware security module (HSM), then they can perform
legitimate owner of the key. If the key is trusted for firmware the same actions as the legitimate owner of the key. If the key is
update, then the third party can perform firmware updates as though trusted for firmware update, then the third party can perform
they were the legitimate owner of the key. firmware updates as though they were the legitimate owner of the key.
For example, if manifest signing is performed on a server connected For example, if manifest signing is performed on a server connected
to the internet, an attacker may compromise the server and then be to the internet, an attacker may compromise the server and then be
able to sign manifests, even if the keys for manifest signing are able to sign manifests, even if the keys for manifest signing are
held in an HSM that is accessed by the server. held in an HSM that is accessed by the server.
Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17) Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17)
4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or payload 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or payload
prior to signing prior to signing
skipping to change at page 26, line 15 skipping to change at page 25, line 33
4.3. Security Requirements 4.3. Security Requirements
The security requirements here are a set of policies that mitigate The security requirements here are a set of policies that mitigate
the threats described in Section 4.1. the threats described in Section 4.1.
4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers
Only an actor with firmware installation authority is permitted to Only an actor with firmware installation authority is permitted to
decide when device firmware can be installed. To enforce this rule, decide when device firmware can be installed. To enforce this rule,
manifests MUST contain monotonically increasing sequence numbers. manifests MUST contain monotonically increasing sequence numbers.
Manifests MAY use UTC epoch timestamps to coordinate monotonically Manifests may use UTC epoch timestamps to coordinate monotonically
increasing sequence numbers across many actors in many locations. If increasing sequence numbers across many actors in many locations. If
UTC epoch timestamps are used, they MUST NOT be treated as times, UTC epoch timestamps are used, they must not be treated as times,
they MUST be treated only as sequence numbers. Devices MUST reject they must be treated only as sequence numbers. Devices must reject
manifests with sequence numbers smaller than any onboard sequence manifests with sequence numbers smaller than any onboard sequence
number. number, i.e. there is no sequence number roll over.
Note: This is not a firmware version. It is a manifest sequence Note: This is not a firmware version field. It is a manifest
number. A firmware version may be rolled back by creating a new sequence number. A firmware version may be rolled back by creating a
manifest for the old firmware version with a later sequence number. new manifest for the old firmware version with a later sequence
number.
Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1) Mitigates: THREAT.IMG.EXPIRED (Section 4.2.1)
Implemented by: Monotonic Sequence Number (Section 3.2) Implemented by: Monotonic Sequence Number (Section 3.2)
4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers
Devices MUST only apply firmware that is intended for them. Devices Devices MUST only apply firmware that is intended for them. Devices
must know that a given update applies to their vendor, model, must know that a given update applies to their vendor, model,
hardware revision, and software revision. Human-readable identifiers hardware revision, and software revision. Human-readable identifiers
are often error-prone in this regard, so unique identifiers SHOULD be are often error-prone in this regard, so unique identifiers should be
used instead. used instead.
Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3)
Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition Implemented by: Vendor ID Condition (Section 3.3), Class ID Condition
(Section 3.4) (Section 3.4)
4.3.3. REQ.SEC.EXP: Expiration Time 4.3.3. REQ.SEC.EXP: Expiration Time
A firmware manifest MAY expire after a given time. Devices MAY A firmware manifest MAY expire after a given time and devices may
provide a secure clock (local or remote). If a secure clock is have a secure clock (local or remote). If a secure clock is provided
provided and the Firmware manifest has an expiration timestamp, the and the Firmware manifest has an expiration timestamp, the device
device MUST reject the manifest if current time is later than the must reject the manifest if current time is later than the expiration
expiration time. time.
Special consideration is required for end-of-life: if a firmware will Special consideration is required for end-of-life in case device will
not be updated again, for example if a business stops issuing updates not be updated again, for example if a business stops issuing updates
to a device. The last valid firmware should not have an expiration for a device. The last valid firmware should not have an expiration
time. time.
Mitigates: THREAT.IMG.EXPIRED.OFFLINE (Section 4.2.2) Mitigates: THREAT.IMG.EXPIRED.OFFLINE (Section 4.2.2)
Implemented by: Expiration Time (Section 3.7) Implemented by: Expiration Time (Section 3.7)
4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity
The authenticity of an update MUST be demonstrable. Typically, this The authenticity of an update MUST be demonstrable. Typically, this
means that updates must be digitally signed. Because the manifest means that updates must be digitally signed. Because the manifest
contains information about how to install the update, the manifest's contains information about how to install the update, the manifest's
authenticity MUST also be demonstrable. To reduce the overhead authenticity must also be demonstrable. To reduce the overhead
required for validation, the manifest contains the cryptographic required for validation, the manifest contains the cryptographic
digest of the firmware image, rather than a second digital signature. digest of the firmware image, rather than a second digital signature.
The authenticity of the manifest can be verified with a digital The authenticity of the manifest can be verified with a digital
signature or Message Authentication Code. The authenticity of the signature or Message Authentication Code. The authenticity of the
firmware image is tied to the manifest by the use of a cryptographic firmware image is tied to the manifest by the use of a cryptographic
digest of the firmware image. digest of the firmware image.
Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.ONPATH Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.ONPATH
(Section 4.2.7) (Section 4.2.7)
Implemented by: Signature (Section 3.15), Payload Digest Implemented by: Signature (Section 3.15), Payload Digest
(Section 3.13) (Section 3.13)
4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type
The type of payload (which may be independent of format) MUST be The type of payload MUST be authenticated. For example, the target
authenticated. For example, the target must know whether the payload must know whether the payload is XIP firmware, a loadable module, or
is XIP firmware, a loadable module, or configuration data. configuration data.
Mitigates: THREAT.IMG.FORMAT (Section 4.2.4) Mitigates: THREAT.IMG.FORMAT (Section 4.2.4)
Implemented by: Payload Format (Section 3.8), Signature Implemented by: Payload Format (Section 3.8), Signature
(Section 3.15) (Section 3.15)
4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: Authenticated Storage
Location Location
The location on the target where the payload is to be stored MUST be The location on the target where the payload is to be stored MUST be
skipping to change at page 28, line 31 skipping to change at page 28, line 4
Implemented by: Payload Digest (Section 3.13), Size (Section 3.14) Implemented by: Payload Digest (Section 3.13), Size (Section 3.14)
4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor images
If an update uses a differential compression method, it MUST specify If an update uses a differential compression method, it MUST specify
the digest of the precursor image and that digest MUST be the digest of the precursor image and that digest MUST be
authenticated. authenticated.
Mitigates: THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10) Mitigates: THREAT.UPD.WRONG_PRECURSOR (Section 4.2.10)
Implemented by: Precursor Image Digest (Section 3.5) Implemented by: Precursor Image Digest (Section 3.5)
4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and Class IDs
The identifiers that specify firmware compatibility MUST be The identifiers that specify firmware compatibility MUST be
authenticated to ensure that only compatible firmware is installed on authenticated to ensure that only compatible firmware is installed on
a target device. a target device.
Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3)
Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition
(Section 3.4) (Section 3.4)
4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity
If a device grants different rights to different actors, exercising If a device grants different rights to different actors, exercising
those rights MUST be accompanied by proof of those rights, in the those rights MUST be accompanied by proof of those rights, in the
form of proof of authenticity. Authenticity mechanisms such as those form of proof of authenticity. Authenticity mechanisms, such as
required in REQ.SEC.AUTHENTIC (Section 4.3.4) can be used to prove those required in REQ.SEC.AUTHENTIC (Section 4.3.4), can be used to
authenticity. prove authenticity.
For example, if a device has a policy that requires that firmware For example, if a device has a policy that requires that firmware
have both an Authorship right and a Qualification right and if that have both an Authorship right and a Qualification right and if that
device grants Authorship and Qualification rights to different device grants Authorship and Qualification rights to different
parties, such as a Device Operator and a Network Operator, parties, such as a Device Operator and a Network Operator,
respectively, then the firmware cannot be installed without proof of respectively, then the firmware cannot be installed without proof of
rights from both the Device Operator and the Network Operator. rights from both the Device Operator and the Network Operator.
Mitigates: THREAT.UPD.UNAPPROVED (Section 4.2.11) Mitigates: THREAT.UPD.UNAPPROVED (Section 4.2.11)
skipping to change at page 30, line 7 skipping to change at page 29, line 25
2. An ACL decides which component identifier/storage identifier 2. An ACL decides which component identifier/storage identifier
pairs can be written by which actors. pairs can be written by which actors.
Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13), Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13),
THREAT.UPD.UNAPPROVED (Section 4.2.11) THREAT.UPD.UNAPPROVED (Section 4.2.11)
Implemented by: Client-side code, not specified in manifest. Implemented by: Client-side code, not specified in manifest.
4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests
It MUST be possible to encrypt part or all of the manifest. This may A manifest format MUST allow encryption of selected parts of the
be accomplished with either transport encryption or with at-rest manifest or encryption of the entire manifest to prevent sensitive
encryption. content of the firmware metadata to be leaked.
Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.ONPATH Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.ONPATH
(Section 4.2.7) (Section 4.2.7)
Implemented by: External Encryption Wrapper / Transport Security Implemented by: Manifest Encryption Wrapper / Transport Security
4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest
The digest SHOULD cover all available space in a fixed-size storage The digest SHOULD cover all available space in a fixed-size storage
location. Variable-size storage locations MUST be restricted to location. Variable-size storage locations MUST be restricted to
exactly the size of deployed payload. This prevents any data from exactly the size of deployed payload. This prevents any data from
being distributed without being covered by the digest. For example, being distributed without being covered by the digest. For example,
XIP microcontrollers typically have fixed-size storage. These XIP microcontrollers typically have fixed-size storage. These
devices should deploy a digest that covers the deployed firmware devices should deploy a digest that covers the deployed firmware
image, concatenated with the default erased value of any remaining image, concatenated with the default erased value of any remaining
skipping to change at page 31, line 7 skipping to change at page 30, line 28
an attacker obtaining the keys. an attacker obtaining the keys.
Keys SHOULD be stored in a way that limits the risk of a legitimate, Keys SHOULD be stored in a way that limits the risk of a legitimate,
but compromised, entity (such as a server or developer computer) but compromised, entity (such as a server or developer computer)
issuing signing requests. issuing signing requests.
Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16) Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16)
4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment 4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment
Manifests SHOULD be parsed and examined prior to deployment to Manifests SHOULD be verified prior to deployment. This reduces
validate that their contents have not been modified during creation problems that may arise with devices installing firmware images that
and signing. damage devices unintentionally.
Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17)
4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a trusted 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a trusted
environment environment
For high risk deployments, such as large numbers of devices or For high risk deployments, such as large numbers of devices or
critical function devices, manifests SHOULD be constructed in an critical function devices, manifests SHOULD be constructed in an
environment that is protected from interference, such as an air- environment that is protected from interference, such as an air-
gapped computer. Note that a networked computer connected to an HSM gapped computer. Note that a networked computer connected to an HSM
skipping to change at page 35, line 11 skipping to change at page 34, line 38
secure execution/boot. secure execution/boot.
Satisfied by: REQ.USE.LOAD (Section 4.5.10) Satisfied by: REQ.USE.LOAD (Section 4.5.10)
4.4.13. USER_STORY.MFST.IMG: Payload in Manifest 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest
As an operator of devices on a constrained network, I would like the 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 manifest to be able to include a small payload in the same packet so
that I can reduce network traffic. that I can reduce network traffic.
Small payloads may include, for example, wrapped encryption keys, Small payloads may include, for example, wrapped content encryption
configuration information, public keys, authorization tokens, or keys, configuration information, public keys, authorization tokens,
X.509 certificates. or X.509 certificates.
Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11) Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11)
4.4.14. USER_STORY.MFST.PARSE: Simple Parsing 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing
As a developer for constrained devices, I want a low complexity As a developer for constrained devices, I want a low complexity
library for processing updates so that I can fit more application library for processing updates so that I can fit more application
code on my device. code on my device.
Satisfied by: REQ.USE.PARSE (Section 4.5.12) Satisfied by: REQ.USE.PARSE (Section 4.5.12)
skipping to change at page 35, line 50 skipping to change at page 35, line 30
Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
4.5. Usability Requirements 4.5. Usability Requirements
The following usability requirements satisfy the user stories listed The following usability requirements satisfy the user stories listed
above. above.
4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks
It MUST be possible for a manifest author to place ALL information A manifest format MUST be able to carry all information required to
required to process an update in the manifest. process an update.
For example: Information about which precursor image is required for For example: Information about which precursor image is required for
a differential update MUST be placed in the manifest, not in the a differential update must be placed in the manifest.
differential compression header.
For example: Information about an installation-time confirmation
system that must be used to allow the installation to proceed.
Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check), Satisfies: [USER_STORY.MFST.PRE_CHECK(#user-story-mfst-pre-check),
USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1) USER_STORY.INSTALL.INSTRUCTIONS (Section 4.4.1)
Implemented by: Additional installation instructions (Section 3.16) Implemented by: Additional installation instructions (Section 3.16)
4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location
It MUST be possible to redirect payload fetches. This applies where A manifest format MUST be able to redirect payload fetches. This
two manifests are used in conjunction. For example, a Device applies where two manifests are used in conjunction. For example, a
Operator creates a manifest specifying a payload and signs it, and Device Operator creates a manifest specifying a payload and signs it,
provides a URI for that payload. A Network Operator creates a second and provides a URI for that payload. A Network Operator creates a
manifest, with a dependency on the first. They use this second second manifest, with a dependency on the first. They use this
manifest to override the URIs provided by the Device Operator, second manifest to override the URIs provided by the Device Operator,
directing them into their own infrastructure instead. Some devices directing them into their own infrastructure instead. Some devices
may provide this capability, while others may only look at canonical may provide this capability, while others may only look at canonical
sources of firmware. For this to be possible, the device must fetch sources of firmware. For this to be possible, the device must fetch
the payload, whereas a device that accepts payload pushes will ignore the payload, whereas a device that accepts payload pushes will ignore
this feature. this feature.
Satisfies: USER_STORY.OVERRIDE (Section 4.4.3) Satisfies: USER_STORY.OVERRIDE (Section 4.4.3)
Implemented by: Aliases (Section 3.17) Implemented by: Aliases (Section 3.17)
4.5.3. REQ.USE.MFST.COMPONENT: Component Updates 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates
It MUST be possible to express the requirement to install one or more A manifest format MUST be able to express the requirement to install
payloads from one or more authorities so that a multi-payload update one or more payloads from one or more authorities so that a multi-
can be described. This allows multiple parties with different payload update can be described. This allows multiple parties with
permissions to collaborate in creating a single update for the IoT different permissions to collaborate in creating a single update for
device, across multiple components. the IoT device, across multiple components.
This requirement effectively means that it must be possible to This requirement implies that it must be possible to construct a tree
construct a tree of manifests on a multi-image target. of manifests on a multi-image target.
In order to enable devices with a heterogeneous storage architecture, In order to enable devices with a heterogeneous storage architecture,
the manifest must enable specification of both storage system and the the manifest must enable specification of both storage system and the
storage location within that storage system. storage location within that storage system.
Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT Satisfies: USER_STORY.OVERRIDE (Section 4.4.3), USER_STORY.COMPONENT
(Section 4.4.4) (Section 4.4.4)
Implemented by: Dependencies, StorageIdentifier, ComponentIdentifier Implemented by: Dependencies, StorageIdentifier, ComponentIdentifier
4.5.3.1. Example 1: Multiple Microcontrollers 4.5.3.1. Example 1: Multiple Microcontrollers
An IoT device with multiple microcontrollers in the same physical An IoT device with multiple microcontrollers in the same physical
device will likely require multiple payloads with different component device will likely require multiple payloads with different component
identifiers. identifiers.
4.5.3.2. Example 2: Code and Configuration 4.5.3.2. Example 2: Code and Configuration
skipping to change at page 37, line 31 skipping to change at page 37, line 9
4.5.3.3. Example 3: Multiple Software Modules 4.5.3.3. Example 3: Multiple Software Modules
A firmware image can be divided into multiple functional blocks for A firmware image can be divided into multiple functional blocks for
separate testing and distribution. This means that code would need separate testing and distribution. This means that code would need
to be distributed in multiple payloads. For example, this might be to be distributed in multiple payloads. For example, this might be
desirable in order to ensure that common code between devices is desirable in order to ensure that common code between devices is
identical in order to reduce distribution bandwidth. identical in order to reduce distribution bandwidth.
4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications
It MUST be possible to authenticate a manifest multiple times so that A manifest format MUST be able to carry multiple signatures so that
authorizations from multiple parties with different permissions can authorizations from multiple parties with different permissions can
be required in order to authorize installation of a manifest. be required in order to authorize installation of a manifest.
Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5) Satisfies: USER_STORY.MULTI_AUTH (Section 4.4.5)
Implemented by: Signature (Section 3.15) Implemented by: Signature (Section 3.15)
4.5.5. REQ.USE.IMG.FORMAT: Format Usability 4.5.5. REQ.USE.IMG.FORMAT: Format Usability
The manifest format MUST accommodate any payload format that an The manifest format MUST accommodate any payload format that an
skipping to change at page 38, line 47 skipping to change at page 38, line 27
The manifest format MUST provide a mechanism to list multiple The manifest format MUST provide a mechanism to list multiple
equivalent payloads by Execute-In-Place Installation Address, equivalent payloads by Execute-In-Place Installation Address,
including the payload digest and, optionally, payload URIs. including the payload digest and, optionally, payload URIs.
Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10) Satisfies: USER_STORY.IMG.SELECT (Section 4.4.10)
Implemented by: XIP Address (Section 3.20) Implemented by: XIP Address (Section 3.20)
4.5.9. REQ.USE.EXEC: Executable Manifest 4.5.9. REQ.USE.EXEC: Executable Manifest
It MUST be possible to describe an executable system with a manifest The manifest format MUST allow to describe an executable system with
on both Execute-In-Place microcontrollers and on complex operating a manifest on both Execute-In-Place microcontrollers and on complex
systems. This requires the manifest to specify the digest of each operating systems. In addition, the manifest format MUST be able to
statically linked dependency. In addition, the manifest format MUST express metadata, such as a kernel command-line, used by any loader
be able to express metadata, such as a kernel command-line, used by or bootloader.
any loader or bootloader.
Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11) Satisfies: USER_STORY.EXEC.MFST (Section 4.4.11)
Implemented by: Run-time metadata (Section 3.22) Implemented by: Run-time metadata (Section 3.22)
4.5.10. REQ.USE.LOAD: Load-Time Information 4.5.10. REQ.USE.LOAD: Load-Time Information
It MUST be possible to specify additional metadata for load time The manifest format MUST enable carrying additional metadata for load
processing of a payload, such as cryptographic information, load- time processing of a payload, such as cryptographic information,
address, and compression algorithm. load-address, and compression algorithm. Note that load comes before
execution/boot.
N.B. load comes before exec/boot.
Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12) Satisfies: USER_STORY.EXEC.DECOMPRESS (Section 4.4.12)
Implemented by: Load-time metadata (Section 3.21) Implemented by: Load-time metadata (Section 3.21)
4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope
It MUST be possible to place a payload in the same structure as the The manifest format MUST allow placing a payload in the same
manifest. This may place the payload in the same packet as the structure as the manifest. This may place the payload in the same
manifest. packet as the manifest.
Integrated payloads may include, for example, wrapped encryption Integrated payloads may include, for example, binaries as well as
keys, configuration information, public keys, authorization tokens, configuration information, and keying material.
or X.509 certificates.
When an integrated payload is provided, this increases the size of When an integrated payload is provided, this increases the size of
the manifest. Manifest size can cause several processing and storage the manifest. Manifest size can cause several processing and storage
concerns that require careful consideration. The payload can prevent concerns that require careful consideration. The payload can prevent
the whole manifest from being contained in a single network packet, the whole manifest from being contained in a single network packet,
which can cause fragmentation and the loss of portions of the which can cause fragmentation and the loss of portions of the
manifest in lossy networks. This causes the need for reassembly and manifest in lossy networks. This causes the need for reassembly and
retransmission logic. The manifest MUST be held immutable between retransmission logic. The manifest MUST be held immutable between
verification and processing (see REQ.SEC.MFST.CONST verification and processing (see REQ.SEC.MFST.CONST
(Section 4.3.20)), so a larger manifest will consume more memory with (Section 4.3.20)), so a larger manifest will consume more memory with
skipping to change at page 40, line 21 skipping to change at page 39, line 44
size of the integrated payload. size of the integrated payload.
See also: REQ.SEC.MFST.CONST (Section 4.3.20). See also: REQ.SEC.MFST.CONST (Section 4.3.20).
Satisfies: USER_STORY.MFST.IMG (Section 4.4.13) Satisfies: USER_STORY.MFST.IMG (Section 4.4.13)
Implemented by: Payload (Section 3.23) Implemented by: Payload (Section 3.23)
4.5.12. REQ.USE.PARSE: Simple Parsing 4.5.12. REQ.USE.PARSE: Simple Parsing
The structure of the manifest MUST be simple to parse, without need The structure of the manifest MUST be simple to parse to reduce the
for a general-purpose parser. attack vectors against manifest parsers.
Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14) Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14)
Implemented by: N/A Implemented by: N/A
4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest
Any manifest format MUST enable the delivery of a key claim with, but A manifest format MUST enable the delivery of delegation information.
not authenticated by, a manifest. This key claim delivers a new key This information delivers a new key with which the recipient can
with which the recipient can verify the manifest. verify the manifest.
Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15)
Implemented by: Delegation Chain (Section 3.24) Implemented by: Delegation Chain (Section 3.24)
5. IANA Considerations 5. IANA Considerations
This document does not require any actions by IANA. This document does not require any actions by IANA.
6. Acknowledgements 6. Acknowledgements
skipping to change at page 41, line 17 skipping to change at page 40, line 42
Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said
Gharout, and Milen Stoychev. Gharout, and Milen Stoychev.
We would like to thank those who contributed to the development of We would like to thank those who contributed to the development of
this information model. In particular, we would like to thank this information model. In particular, we would like to thank
Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary
Thomson. Thomson.
Finally, we would like to thank the following IESG members for their Finally, we would like to thank the following IESG members for their
review feedback: Erik Kline, Murray Kucherawy, Barry Leiba, Alissa review feedback: Erik Kline, Murray Kucherawy, Barry Leiba, Alissa
Cooper, and Benjamin Kaduk. Cooper, Stephen Farrell and Benjamin Kaduk.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-suit-architecture] [I-D.ietf-suit-architecture]
Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
Firmware Update Architecture for Internet of Things", Firmware Update Architecture for Internet of Things",
draft-ietf-suit-architecture-15 (work in progress), draft-ietf-suit-architecture-15 (work in progress),
January 2021. January 2021.
skipping to change at page 41, line 45 skipping to change at page 41, line 21
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[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>.
[STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018,
<https://msdn.microsoft.com/en-us/library/ <https://msdn.microsoft.com/en-us/library/
ee823878(v=cs.20).aspx>. ee823878(v=cs.20).aspx>.
Authors' Addresses Authors' Addresses
Brendan Moran Brendan Moran
Arm Limited Arm Limited
EMail: Brendan.Moran@arm.com EMail: Brendan.Moran@arm.com
 End of changes. 140 change blocks. 
310 lines changed or deleted 289 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/