< draft-ietf-suit-information-model-08.txt   draft-ietf-suit-information-model-09.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: May 1, 2021 H. Birkholz Expires: August 26, 2021 H. Birkholz
Fraunhofer SIT Fraunhofer SIT
October 28, 2020 February 22, 2021
An Information Model for Firmware Updates in IoT Devices A Manifest Information Model for Firmware Updates in IoT Devices
draft-ietf-suit-information-model-08 draft-ietf-suit-information-model-09
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 May 1, 2021. This Internet-Draft will expire on August 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6
3. Manifest Information Elements . . . . . . . . . . . . . . . . 6 3. Manifest Information Elements . . . . . . . . . . . . . . . . 6
3.1. Manifest Element: Version ID of the manifest structure . 6 3.1. Version ID of the manifest structure . . . . . . . . . . 7
3.2. Manifest Element: Monotonic Sequence Number . . . . . . . 6 3.2. Monotonic Sequence Number . . . . . . . . . . . . . . . . 7
3.3. Manifest Element: Vendor ID . . . . . . . . . . . . . . . 7 3.3. Vendor ID . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 7 3.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 7
3.4. Manifest Element: Class ID . . . . . . . . . . . . . . . 7 3.4. Class ID . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. Example 1: Different Classes . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . 9 3.4.4. Example 4: White-labelling . . . . . . . . . . . . . 10
3.5. Manifest Element: Precursor Image Digest Condition . . . 10 3.5. Precursor Image Digest Condition . . . . . . . . . . . . 10
3.6. Manifest Element: Required Image Version List . . . . . . 10 3.6. Required Image Version List . . . . . . . . . . . . . . . 11
3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10 3.7. Expiration Time . . . . . . . . . . . . . . . . . . . . . 11
3.8. Manifest Element: Payload Format . . . . . . . . . . . . 11 3.8. Payload Format . . . . . . . . . . . . . . . . . . . . . 11
3.9. Manifest Element: Processing Steps . . . . . . . . . . . 11 3.9. Processing Steps . . . . . . . . . . . . . . . . . . . . 12
3.10. Manifest Element: Storage Location . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . 12 3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 13
3.11. Manifest Element: Component Identifier . . . . . . . . . 12 3.11. Component Identifier . . . . . . . . . . . . . . . . . . 13
3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12 3.12. Payload Indicator . . . . . . . . . . . . . . . . . . . . 13
3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 13 3.13. Payload Digests . . . . . . . . . . . . . . . . . . . . . 13
3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 13 3.14. Size . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.15. Manifest Envelope Element: Signature . . . . . . . . . . 13 3.15. Manifest Envelope Element: Signature . . . . . . . . . . 14
3.16. Manifest Element: Additional installation instructions . 14 3.16. Additional installation instructions . . . . . . . . . . 15
3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 14 3.17. Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 15 3.18. Dependencies . . . . . . . . . . . . . . . . . . . . . . 15
3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 15 3.19. Encryption Wrapper . . . . . . . . . . . . . . . . . . . 15
3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 15 3.20. XIP Address . . . . . . . . . . . . . . . . . . . . . . . 16
3.21. Manifest Element: Load-time metadata . . . . . . . . . . 15 3.21. Load-time metadata . . . . . . . . . . . . . . . . . . . 16
3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 16 3.22. Run-time metadata . . . . . . . . . . . . . . . . . . . . 16
3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 16 3.23. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.24. Manifest Envelope Element: Delegation Chain . . . . . . . 16 3.24. Manifest Envelope Element: Delegation Chain . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 17 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 18
4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 17 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 18
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 . . . . 18 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 19
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 . . . . . . . . . . . . 19 payload to the wrong location . . . . . . . . . . . . 20
4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic
payload hosting . . . . . . . . . . . . . . . . . . . 20 payload hosting . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . 20 4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 21
4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 21 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 21
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 . . . . . 21 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . . 23 Elements . . . . . . . . . . . . . . . . . . . . . . 24
4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element
Exposure . . . . . . . . . . . . . . . . . . . . . . 24 Exposure . . . . . . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . 24 payload prior to signing . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . 25 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 26
4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 25 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 26
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 . . . . 26 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 27
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 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload 28
Resource Location . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 27 images . . . . . . . . . . . . . . . . . . . . . . . 28
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 . . . 28 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 29
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 . . 29 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 30
4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 29 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 30
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 . . . . . . . . . . . . . . . . . . . . . 30 deployment . . . . . . . . . . . . . . . . . . . . . 31
4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a 4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a
trusted environment . . . . . . . . . . . . . . . . . 30 trusted environment . . . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . . . . . 30 check and use . . . . . . . . . . . . . . . . . . . . 31
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 . . . . . . . 31 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 32
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 . . . . . . . 32 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 33
4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations . . . 32 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations . . . 33
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 . . . . . . . . . . . . . 33 Numbers of Target Firmware . . . . . . . . . . . . . 34
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 . . . . . . 34 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 35
4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 34 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 35
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 . . . . . . . . . . . . . . . . . . 35 Resource Location . . . . . . . . . . . . . . . . . . 36
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 . . . . . . . . . 37 4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 38
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 . . . . . . . . . 38 4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 39
4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope . . . . 39 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope . . . . 39
4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 40 4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 40
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 . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1. Normative References . . . . . . . . . . . . . . . . . . 41 7.1. Normative References . . . . . . . . . . . . . . . . . . 41
7.2. Informative References . . . . . . . . . . . . . . . . . 41 7.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
The information model describes all the information elements required Vulnerabilities with Internet of Things (IoT) devices have raised the
to secure firmware updates of IoT devices from the threats described need for a reliable and secure firmware update mechanism that is also
in Section 4.1 and enables the user stories captured in Section 4.4. suitable for constrained devices. Ensuring that devices function and
These threats and user stories are not intended to be an exhaustive remain secure over their service life requires such an update
list of the threats against IoT devices, nor of the possible user mechanism to fix vulnerabilities, to update configuration settings,
stories that describe how to conduct a firmware update. Instead they as well as adding new functionality.
are intended to describe the threats against firmware updates in
isolation and provide sufficient motivation to specify the
information elements that cover a wide range of user stories. The
information model does not define the serialization, encoding,
ordering, or structure of information elements, only their semantics.
Because the information model covers a wide range of user stories and One component of such a firmware update is a concise and machine-
a wide range of threats, not all information elements apply to all processable meta-data document, or manifest, that describes the
scenarios. As a result, various information elements could be firmware image(s) and offers appropriate protection. This document
considered optional to implement and optional to use, depending on describes the information that must be present in the manifest.
which threats exist in a particular domain of application and which
user stories are required. Elements marked as REQUIRED provide
baseline security and usability properties that are expected to be
required for most applications. Those elements are required to be
implemented and used. 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.
The definition of some of the information elements include examples This document describes all the information elements required in a
that illustrate their semantics and how they are intended to be used. manifest to secure firmware updates of IoT devices. Each information
element is motiviated by user stories and threats it aims to
mitigate. These threats and user stories are not intended to be an
exhaustive list of the threats against IoT devices, nor of the
possible user stories that describe how to conduct a firmware update.
Instead they are intended to describe the threats against firmware
updates in isolation and provide sufficient motivation to specify the
information elements that cover a wide range of user stories.
To distinguish information elements from their encoding and
serialization over the wire this document presents an information
model.
Because this document covers a wide range of user stories and a wide
range of threats, not all information elements apply to all
scenarios. As a result, various information elements are optional to
implement and optional to use, depending on which threats exist in a
particular domain of application and which user stories are important
for deployments.
Elements marked as REQUIRED provide baseline security and usability
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. Conventions and 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.
The term Envelope is used to describe an encoding that allows the The term Envelope is used to describe an encoding that allows the
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" as device during an update. This is distinct from a "firmware image",
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 2.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. 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. Manifest Element: 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 element is REQUIRED in order to allow devices to identify the This element is REQUIRED to be implemented to allow devices to
version of the manifest data model that is in use. identify the version of the manifest data model that is in use.
3.2. Manifest Element: Monotonic Sequence Number 3.2. Monotonic Sequence Number
A monotonically increasing sequence number. For convenience, the A monotonically increasing sequence number. For convenience, the
monotonic sequence number MAY be a UTC timestamp. This allows global monotonic sequence number MAY be a UTC timestamp. This allows global
synchronisation of sequence numbers without any additional synchronisation of sequence numbers without any additional
management. This number MUST be possible to extract with a simple, management. This number MUST be possible to extract with a simple,
minimal parser so that code choosing one out of several manifests can minimal parser so that code choosing one out of several manifests can
choose which is the latest without fully parsing a complex structure. choose which is the latest without fully parsing a complex structure.
This element is REQUIRED and is necessary to prevent malicious actors This element is REQUIRED to be implemented and is necessary to
from reverting a firmware update against the policies of the relevant prevent malicious actors from reverting a firmware update against the
authority. policies of the relevant authority.
Implements: REQ.SEC.SEQUENCE (Section 4.3.1) Implements: REQ.SEC.SEQUENCE (Section 4.3.1)
3.3. Manifest Element: Vendor ID 3.3. Vendor ID
Vendor IDs must be unique. This is to prevent similarly, or Vendor IDs must be unique. This is to prevent similarly, or
identically named entities from different geographic regions from identically named entities from different geographic regions from
colliding in their customer's infrastructure. Recommended practice colliding in their customer's infrastructure. Recommended practice
is to use [RFC4122] version 5 UUIDs with the vendor's domain name and is to use [RFC4122] version 5 UUIDs with the vendor's domain name and
the DNS name space ID. Other options include type 1 and type 4 the DNS name space ID. Other options include type 1 and type 4
UUIDs. UUIDs.
Vendor ID is not intended to be a human-readable element. It is Vendor 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 a Vendor ID is RECOMMENDED. It helps to distinguish The use of a Vendor ID is RECOMMENDED. It helps to distinguish
between identically named products from different vendors. 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 3.3.1. Example: Domain Name-based UUIDs
Vendor A creates a UUID based on their domain name: Vendor A creates a UUID based on a domain name it controls, such as
vendorId = UUID5(DNS, "vendor-a.example")
vendorId = UUID5(DNS, "vendor-a.com")
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. Manifest Element: 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. Class IDs MUST be
unique within the scope of a Vendor ID. This is to prevent unique within the scope of a Vendor ID. This is to prevent
similarly, or identically named devices colliding in their customer's similarly, or identically named devices colliding in their customer's
infrastructure. 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:
skipping to change at page 8, line 25 skipping to change at page 8, line 40
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 Identifier UUID SHOULD use the Vendor ID as the name space
ID. Other options include version 1 and 4 UUIDs. Classes MAY be ID. Other options include version 1 and 4 UUIDs. Classes MAY be
more granular than is required to identify firmware compatibility. more fine-grained granular than is required to identify firmware
Classes MUST NOT be less granular than is required to identify compatibility. Classes MUST NOT be less granular than is required to
firmware compatibility. Devices MAY have multiple Class IDs. identify firmware compatibility. Devices MAY have 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 The use of Class ID is RECOMMENDED. It allows devices to determine
applicability of a firmware in an unambiguous way. applicability of a firmware in an unambiguous way.
If Class ID is not implemented, then each logical device class MUST 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.
skipping to change at page 10, line 20 skipping to change at page 10, line 39
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. Manifest Element: Precursor Image Digest Condition 3.5. Precursor Image Digest Condition
When a precursor image is required by the payload format (for When a precursor image is required by the payload format (for
example, differential updates), a precursor image digest condition example, differential updates), a precursor image digest condition
MUST be present. The precursor image MAY be installed or stored as a MUST be present. The precursor image MAY be installed or stored as a
candidate. candidate.
This element is OPTIONAL to implement. This element is OPTIONAL to implement.
Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) Implements: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9)
3.6. Manifest Element: Required Image Version List 3.6. Required Image Version List
When a payload applies to multiple versions of a firmware, the Payloads may only be applied to a specific firmware version or
required image version list specifies which versions must be present firmware versions. For example, a payload containing a differential
for the update to be applied. This allows the update author to update may be applied only to a specific firmware version.
target specific versions of firmware for an update, while excluding
those to which it should not be applied.
Where an update can only be applied over specific predecessor When a payload applies to multiple versions of a firmware, the
versions, that version MUST be specified by the Required Image required image version list specifies which firmware versions must be
Version List. present for the update to be applied. This allows the update author
to target specific versions of firmware for an update, while
excluding those to which it should not or cannot be applied.
This element is OPTIONAL to implement. This element is OPTIONAL to implement.
Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7) Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7)
3.7. Manifest Element: 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. The last valid firmware should not have an expiration to a device. In this case the last valid firmware should not have an
time. expiration time.
This element is OPTIONAL to implement. This element is OPTIONAL to implement.
Implements: REQ.SEC.EXP (Section 4.3.3) Implements: REQ.SEC.EXP (Section 4.3.3)
3.8. Manifest Element: Payload Format 3.8. Payload Format
The format of the payload MUST be indicated to devices in an The format of the payload MUST be indicated to devices in an
unambiguous way. This element provides a mechanism to describe the unambiguous way. This element provides a mechanism to describe the
payload format, within the signed metadata. payload format, within the signed metadata.
This element is REQUIRED and MUST be present to enable devices to This element is REQUIRED to be implemented and MUST be used to enable
decode payloads correctly. 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. Manifest Element: 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 algorithm(s) is
used and any additional parameters required by the algorithm(s). The used and any additional parameters required by the algorithm(s). The
representation MAY group Processing Steps together in predefined representation MAY group Processing Steps together in predefined
combinations. 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. Processing steps are RECOMMENDED to implement.
Implements: REQ.USE.IMG.NESTED (Section 4.5.6) Implements: REQ.USE.IMG.NESTED (Section 4.5.6)
3.10. Manifest Element: 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 and MUST be present to enable devices to This element is REQUIRED to be implemented and MUST be present to
store payloads to the correct location. 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:
o "OS" o "OS"
o "APP" o "APP"
3.10.2. Example 2: File System 3.10.2. Example 2: File System
A device supports a full filesystem. The Author chooses to use the A device supports a full-featured filesystem. The Author chooses to
storage identifier as the path at which to install the payload. The use the storage identifier as the path at which to install the
payload may be a tarball, in which case, it unpacks the tarball into payload. The payload may be a tarball, in which case, it unpacks the
the specified path. tarball into the specified path.
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. Manifest Element: 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 which
part of the storage architecture is targeted by the payload. part of the storage architecture is targeted by the payload.
This element is OPTIONAL and only necessary in devices with multiple This element is OPTIONAL to implement and only necessary in devices
storage subsystems. with multiple storage subsystems.
N.B. A serialization MAY choose to combine Component Identifier and N.B. A serialization MAY choose to combine Component Identifier and
Storage Location (Section 3.10) 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. Manifest Element: Resource 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 resource. This can be encoded in several ways: acquire 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 and only needed when the target device does This element is OPTIONAL to implement and only needed when the target
not intrinsically know where to find the payload. device does not intrinsically know where to find the payload.
N.B. Devices will typically require URIs. 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. Manifest Element: 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). A manifest format MUST provide a mechanism to select one
payload from a list based on system parameters, such as Execute-In- payload from a list based on system parameters, such as Execute-In-
Place Installation Address. Place Installation Address.
This element is REQUIRED to implement and fundamentally necessary to This element is REQUIRED to be implemented and necessary to ensure
ensure the authenticity and integrity of the payload. Support for the authenticity and integrity of the payload. Support for more than
more than one digest is OPTIONAL to implement in a recipient device. 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. Manifest Element: Size 3.14. Size
The size of the payload in bytes. The size of the payload in bytes.
Variable-size storage locations MUST be set to exactly the size Variable-size storage locations MUST be set to exactly the size
listed in this element. listed in this element.
This element is REQUIRED and informs the target device how big of a This element is REQUIRED to be implemented and informs the target
payload to expect. Without it, devices are exposed to some classes device how big of a payload to expect. Without it, devices are
of denial of service attack. 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 MUST contain all the information necessary to
cryptographically verify the contents of the manifest against a root cryptographically verify the contents of the manifest against a root
of trust. Because the Signature element authenticates the manifest, of trust. Because the Signature element authenticates the manifest,
it cannot be contained within the manifest. Instead, the manifest is it cannot be contained within the manifest. Instead, the manifest is
either contained within the signature element, or the signature either contained within the signature element, or the signature
element is a member of the Manifest Envelope and bundled with the element is a member of the Manifest Envelope and bundled with the
manifest. manifest.
This element MAY be provided either by the manifest envelope The Signature element MUST support multiple signers and multiple
serialization or by another serialization of authentication objects, signing algorithms. It is OPTIONAL for a serialization to
such as a COSE ([RFC8152]) or CMS ([RFC5652]) signature object. The
Signature element MUST support multiple actors and multiple
authentication methods. It is NOT REQUIRED for a serialization to
authenticate multiple manifests with a single Signature element. authenticate multiple manifests with a single Signature element.
This element is REQUIRED in non-dependency manifests and represents This element is REQUIRED to be implemented in non-dependency
the foundation of all security properties of the manifest. Manifests manifests and represents the foundation of all security properties of
which are included as dependencies by another manifest SHOULD include the manifest. Manifests, which are included as dependencies by
a signature so that the recipient can distinguish between different another manifests, SHOULD include a signature so that the recipient
actors with different permissions. can distinguish between different actors with different permissions.
A manifest MUST NOT be considered authenticated by channel security The design of the manifest security framework MUST NOT rely on
even if it contains only channel information (such as URIs). If the channel security. Where public key operations require too many
authenticated remote or channel were compromised, the threat actor resources, the use of message authentication codes is RECOMMENDED
could induce recipients to execute queries over any accessible with a per-device symmetric key.
network. Where public key operations require too many resources, the
recommended authentication mechanism is MAC with a per-device pre-
shared 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. Manifest Element: Additional installation instructions 3.16. Additional installation instructions
Instructions that the device should execute when processing the Machine-readable instructions that the device should execute when
manifest. This information is distinct from the information processing the manifest. This information is distinct from the
necessary to process a payload. Additional installation instructions information necessary to process a payload. Additional installation
include information such as update timing (for example, install only instructions include information such as update timing (for example,
on Sunday, at 0200), procedural considerations (for example, shut install only on Sunday, at 0200), procedural considerations (for
down the equipment under control before executing the update), pre- example, shut down the equipment under control before executing the
and post-installation steps (for example, run a script). Other update), pre- and post-installation steps (for example, run a
installation instructions could include requesting user confirmation script). Other installation instructions could include requesting
before installing. user confirmation before installing.
This element is OPTIONAL. This element is OPTIONAL to implement.
Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) Implements: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
3.17. Manifest Element: 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 and enables some user stories. This element is OPTIONAL to implement and enables some user stories.
Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2)
3.18. Manifest Element: 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 digest. Manifests are identified an unambiguous way, such as a cryptographic
digest.
This element is REQUIRED to use in deployments that include both This element is REQUIRED to use in 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. Manifest Element: 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. This MAY be included in a decryption step contained in
Processing Steps (Section 3.9). Processing Steps (Section 3.9).
This element is REQUIRED to use for encrypted payloads, This element is REQUIRED to use for encrypted payloads,
Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) Implements: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)
3.20. Manifest Element: XIP Address 3.20. XIP Address
In order to support XIP systems with multiple possible base In order to support execute in place (XIP) systems with multiple
addresses, it is necessary to specify which address the payload is possible base addresses, it is necessary to specify which address the
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 to implement.
Implements: REQ.USE.IMG.SELECT (Section 4.5.8) Implements: REQ.USE.IMG.SELECT (Section 4.5.8)
3.21. Manifest Element: 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 the destination address
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 to implement.
Implements: REQ.USE.LOAD (Section 4.5.10) Implements: REQ.USE.LOAD (Section 4.5.10)
3.22. Manifest Element: 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 information such as the
entry-point of an XIP image or the kernel command-line of a Linux entry-point of an XIP image or the kernel command-line of a Linux
image. image.
This element is OPTIONAL to implement. This element is OPTIONAL to implement.
Implements: REQ.USE.EXEC (Section 4.5.9) Implements: REQ.USE.EXEC (Section 4.5.9)
3.23. Manifest Element: 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. This enables the manifest and payload to be delivered
simultaneously. Typically this is used for delivering small payloads simultaneously. Typically this is used for delivering small payloads
such as cryptographic keys, or configuration data. such as cryptographic keys, or configuration data.
This element is OPTIONAL to implement. This element is OPTIONAL to implement.
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
The Signature (Section 3.15) is NOT REQUIRED to cover the delegation It is OPTIONAL for the Signature (Section 3.15) to cover the
chain. The delegation chain offers enhanced authorization delegation chain. The delegation chain offers enhanced authorization
functionality via authorization tokens. Each token itself is functionality via authorization tokens. Each token itself is
protected and does not require another layer of protection and protected and does not require another layer of protection. Because
because the delegation chain is needed to verify the signature, it the delegation chain is needed to verify the signature, it must be
must be placed in the Manifest Envelope, rather than the Manifest. placed in the Manifest Envelope, rather than the Manifest.
This element is OPTIONAL to implement. This element is OPTIONAL to implement.
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
skipping to change at page 21, line 9 skipping to change at page 21, line 26
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
If an attacker can install their firmware on a device, 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
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
skipping to change at page 21, line 38 skipping to change at page 22, line 11
precursor would result in a functional, but vulnerable firmware. precursor would result in a functional, but vulnerable firmware.
Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9) Mitigated by: REQ.SEC.AUTH.PRECURSOR (Section 4.3.9)
4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware
Classification: Denial of Service, Elevation of Privilege Classification: Denial of Service, Elevation of Privilege
This threat can appear in several ways, however it is ultimately This threat can appear in several ways, however it is ultimately
about ensuring that devices retain the behaviour required by their about ensuring that devices retain the behaviour required by their
Owner, Device Operator, or Network Operator. The owner or operator owner, or operator. The owner or operator of a device typically
of a device typically requires that the device maintain certain requires that the device maintain certain features, functions,
features, functions, capabilities, behaviours, or interoperability capabilities, behaviours, or interoperability constraints (more
constraints (more generally, behaviour). If these requirements are generally, behaviour). If these requirements are broken, then a
broken, then a device will not fulfill its purpose. Therefore, if device will not fulfill its purpose. Therefore, if any party other
any party other than the device's Owner or the Owner's contracted than the device's owner or the owner's contracted Device Operator has
Device Operator has the ability to modify device behaviour without the ability to modify device behaviour without approval, then this
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.
skipping to change at page 22, line 26 skipping to change at page 22, line 47
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
as a whole. as a whole.
Similarly, the operator of a network may need to approve firmware for Similarly, the operator of a network may need to approve firmware for
devices attached to the network in order to ensure favourable devices attached to the network in order to ensure favourable
operating conditions within the network. If the firmware is not operating conditions within the network. If the firmware is not
qualified, it may degrade the performance of the network. Therefore, qualified, it may degrade the performance of the network. Therefore,
if a device installs firmware without the approval of the network if a device installs firmware without the approval of the Network
operator, this is a threat to the network itself. Operator, this is a threat to the network itself.
Threat Escalation: If the firmware expects configuration that is Threat Escalation: If the firmware expects configuration that is
present in devices deployed in Network A, but not in devices deployed present in devices deployed in Network A, but not in devices deployed
in Network B, then the device may experience degraded security, in Network B, then the device may experience degraded security,
leading to threats of All Types. leading to threats of All Types.
Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL Mitigated by: REQ.SEC.RIGHTS (Section 4.3.11), REQ.SEC.ACCESS_CONTROL
(Section 4.3.13) (Section 4.3.13)
4.2.11.1. Example 1: Multiple Network Operators with a Single Device 4.2.11.1. Example 1: Multiple Network Operators with a Single Device
skipping to change at page 26, line 8 skipping to change at page 26, line 33
number. A firmware version may be rolled back by creating a new number. A firmware version may be rolled back by creating a new
manifest for the old firmware version with a later sequence number. 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 with fine granularity that a given update applies to their must know that a given update applies to their vendor, model,
vendor, model, hardware revision, software revision. Human-readable hardware revision, and software revision. Human-readable identifiers
identifiers are often error-prone in this regard, so unique are often error-prone in this regard, so unique identifiers SHOULD be
identifiers SHOULD be used. 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. Devices MAY
provide a secure clock (local or remote). If a secure clock is provide a secure clock (local or remote). If a secure clock is
skipping to change at page 26, line 38 skipping to change at page 27, line 14
to a device. The last valid firmware should not have an expiration to 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 authenticated. Because the means that updates must be digitally signed. Because the manifest
manifest contains information about how to install the update, the contains information about how to install the update, the manifest's
manifest's authenticity MUST also be demonstrable. To reduce the authenticity MUST also be demonstrable. To reduce the overhead
overhead required for validation, the manifest contains the digest of required for validation, the manifest contains the cryptographic
the firmware image, rather than a second digital signature. The digest of the firmware image, rather than a second digital signature.
authenticity of the manifest can be verified with a digital signature The authenticity of the manifest can be verified with a digital
or Message Authentication Code. The authenticity of the firmware signature or Message Authentication Code. The authenticity of the
image is tied to the manifest by the use of a digest of the firmware firmware image is tied to the manifest by the use of a cryptographic
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 (which may be independent of format) MUST be
authenticated. For example, the target must know whether the payload authenticated. For example, the target must know whether the payload
is XIP firmware, a loadable module, or configuration data. is XIP firmware, a loadable module, or 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), Storage Location Implemented by: Payload Format (Section 3.8), Signature
(Section 3.10) (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
authenticated. authenticated.
Mitigates: THREAT.IMG.LOCATION (Section 4.2.5) Mitigates: THREAT.IMG.LOCATION (Section 4.2.5)
Implemented by: Storage Location (Section 3.10) Implemented by: Storage Location (Section 3.10)
4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Resource Location 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload
The location where a target should find a payload MUST be The location where a target should find a payload MUST be
authenticated. authenticated.
Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.ONPATH Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.ONPATH
(Section 4.2.7) (Section 4.2.7)
Implemented by: Resource Indicator (Section 3.12) Implemented by: Payload Indicator (Section 3.12)
4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution
The target SHOULD verify firmware at time of boot. This requires The target SHOULD verify firmware at time of boot. This requires
authenticated payload size, and digest. authenticated payload size, and digest.
Mitigates: THREAT.IMG.REPLACE (Section 4.2.8) Mitigates: THREAT.IMG.REPLACE (Section 4.2.8)
Implemented by: Payload Digest (Section 3.13), Size (Section 3.14) Implemented by: Payload Digest (Section 3.13), Size (Section 3.14)
skipping to change at page 30, line 7 skipping to change at page 30, line 33
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
space. space.
Mitigates: THREAT.IMG.EXTRA (Section 4.2.15) Mitigates: THREAT.IMG.EXTRA (Section 4.2.15)
Implemented by: Payload Digests (Section 3.13) Implemented by: Payload Digests (Section 3.13)
4.3.16. REQ.SEC.REPORTING: Secure Reporting 4.3.16. REQ.SEC.REPORTING: Secure Reporting
Status reports from the device to any remote system SHOULD be Status reports from the device to any remote system MUST be performed
performed over an authenticated, confidential channel in order to over an authenticated, confidential channel in order to prevent
prevent modification or spoofing of the reports. modification or spoofing of the reports.
Mitigates: THREAT.NET.ONPATH (Section 4.2.7) Mitigates: THREAT.NET.ONPATH (Section 4.2.7)
4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys 4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys
Cryptographic keys for signing/authenticating manifests SHOULD be Cryptographic keys for signing/authenticating manifests SHOULD be
stored in a manner that is inaccessible to networked devices, for stored in a manner that is inaccessible to networked devices, for
example in an HSM, or an air-gapped computer. This protects against example in an HSM, or an air-gapped computer. This protects against
an attacker obtaining the keys. an attacker obtaining the keys.
skipping to change at page 31, line 27 skipping to change at page 32, line 6
4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation Instructions
As a Device Operator, I want to provide my devices with additional As a Device Operator, I want to provide my devices with additional
installation instructions so that I can keep process details out of installation instructions so that I can keep process details out of
my payload data. my payload data.
Some installation instructions might be: Some installation instructions might be:
o Use a table of hashes to ensure that each block of the payload is o Use a table of hashes to ensure that each block of the payload is
validate before writing. validated before writing.
o Do not report progress. o Do not report progress.
o Pre-cache the update, but do not install. o Pre-cache the update, but do not install.
o Install the pre-cached update matching this manifest. o Install the pre-cached update matching this manifest.
o Install this update immediately, overriding any long-running o Install this update immediately, overriding any long-running
tasks. tasks.
skipping to change at page 32, line 31 skipping to change at page 33, line 5
o Directives (Section 3.16): this allows the Device Operator to add o Directives (Section 3.16): this allows the Device Operator to add
more instructions such as time of installation. more instructions such as time of installation.
o Processing Steps (Section 3.9): If an intermediary performs an o Processing Steps (Section 3.9): If an intermediary performs an
action on behalf of a device, it may need to override the action on behalf of a device, it may need to override the
processing steps. It is still possible for a device to verify the processing steps. It is still possible for a device to verify the
final content and the result of any processing step that specifies final content and the result of any processing step that specifies
a digest. Some processing steps should be non-overridable. a digest. Some processing steps should be non-overridable.
Satisfied by: USER_STORY.OVERRIDE (Section 4.4.3), Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3)
REQ.USE.MFST.COMPONENT (Section 4.5.3)
4.4.4. USER_STORY.COMPONENT: Component Update 4.4.4. USER_STORY.COMPONENT: Component Update
As a Device Operator, I want to divide my firmware into components, As a Device Operator, I want to divide my firmware into components,
so that I can reduce the size of updates, make different parties so that I can reduce the size of updates, make different parties
responsible for different components, and divide my firmware into responsible for different components, and divide my firmware into
frequently updated and infrequently updated components. frequently updated and infrequently updated components.
Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3) Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.3)
skipping to change at page 33, line 16 skipping to change at page 33, line 37
As a Device Operator, I want to be able to send multiple payload As a Device Operator, I want to be able to send multiple payload
formats to suit the needs of my update, so that I can optimise the formats to suit the needs of my update, so that I can optimise the
bandwidth used by my devices. bandwidth used by my devices.
Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5) Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5)
4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential Information
Disclosures Disclosures
As a firmware author, I want to prevent confidential information from As a firmware author, I want to prevent confidential information in
being disclosed during firmware updates. It is assumed that channel the manifest from being disclosed when distributing manifests and
security or at-rest encryption is adequate to protect the manifest firmware images. Confidential information may include information
itself against information disclosure. about the device these updates are being applied to as well as
information in the firmware image itself.
Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) Satisfied by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)
4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking 4.4.8. USER_STORY.IMG.UNKNOWN_FORMAT: Prevent Devices from Unpacking
Unknown Formats Unknown Formats
As a Device Operator, I want devices to determine whether they can As a Device Operator, I want devices to determine whether they can
process a payload prior to downloading it. process a payload prior to downloading it.
In some cases, it may be desirable for a third party to perform some In some cases, it may be desirable for a third party to perform some
processing on behalf of a target. For this to occur, the third party processing on behalf of a target. For this to occur, the third party
MUST indicate what processing occurred and how to verify it against MUST indicate what processing occurred and how to verify it against
the Trust Provisioning Authority's intent. the Trust Provisioning Authority's intent.
This amounts to overriding Processing Steps (Section 3.9) and This amounts to overriding Processing Steps (Section 3.9) and Payload
Resource Indicator (Section 3.12). Indicator (Section 3.12).
Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5), REQ.USE.IMG.NESTED Satisfied by: REQ.USE.IMG.FORMAT (Section 4.5.5), REQ.USE.IMG.NESTED
(Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) (Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2)
4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version Numbers of
Target Firmware Target Firmware
As a Device Operator, I want to be able to target devices for updates As a Device Operator, I want to be able to target devices for updates
based on their current firmware version, so that I can control which based on their current firmware version, so that I can control which
versions are replaced with a single manifest. versions are replaced with a single manifest.
skipping to change at page 36, line 31 skipping to change at page 37, line 4
This requirement effectively means that it must be possible to This requirement effectively means that it must be possible to
construct a tree of manifests on a multi-image target. construct a tree 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 Manifest Element: 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 (HeSA) will likely require multiple payloads with different device will likely require multiple payloads with different component
component identifiers. identifiers.
4.5.3.2. Example 2: Code and Configuration 4.5.3.2. Example 2: Code and Configuration
A firmware image can be divided into two payloads: code and A firmware image can be divided into two payloads: code and
configuration. These payloads may require authorizations from configuration. These payloads may require authorizations from
different actors in order to install (see REQ.SEC.RIGHTS different actors in order to install (see REQ.SEC.RIGHTS
(Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This (Section 4.3.11) and REQ.SEC.ACCESS_CONTROL (Section 4.3.13)). This
structure means that multiple manifests may be required, with a structure means that multiple manifests may be required, with a
dependency structure between them. dependency structure between them.
skipping to change at page 39, line 8 skipping to change at page 39, line 26
N.B. load comes before exec/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 It MUST be possible to place a payload in the same structure as the
manifest. This MAY place the payload in the same packet as the manifest. This may place the payload in the same packet as the
manifest. manifest.
Integrated payloads may include, for example, wrapped encryption Integrated payloads may include, for example, wrapped encryption
keys, configuration information, public keys, authorization tokens, keys, configuration information, public keys, authorization tokens,
or X.509 certificates. 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,
skipping to change at page 41, line 5 skipping to change at page 41, line 15
Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias Jan-Frederik Rieckers, Francisco Acosta, Anton Gerasimov, Matthias
Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm,
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
review feedback: Erik Kline, Murray Kucherawy, Barry Leiba, Alissa
Cooper, 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-14 (work in progress), draft-ietf-suit-architecture-15 (work in progress),
October 2020. January 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[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
[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>.
 End of changes. 110 change blocks. 
251 lines changed or deleted 254 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/