< draft-ietf-suit-information-model-11.txt   draft-ietf-suit-information-model-12.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: October 8, 2021 H. Birkholz Expires: November 25, 2021 H. Birkholz
Fraunhofer SIT Fraunhofer SIT
April 06, 2021 May 24, 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-11 draft-ietf-suit-information-model-12
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 October 8, 2021. This Internet-Draft will expire on November 25, 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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements and Terminology . . . . . . . . . . . . . . . . 6 2. Requirements and Terminology . . . . . . . . . . . . . . . . 6
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 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.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 . . . . . . . . . . . . 10
3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 9 3.4.3. Example 3: Shared Functionality . . . . . . . . . . . 10
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 . . . . . . . . . . . . 11
3.6. Required Image Version List . . . . . . . . . . . . . . . 10 3.6. Required Image Version List . . . . . . . . . . . . . . . 11
3.7. Expiration Time . . . . . . . . . . . . . . . . . . . . . 11 3.7. Expiration Time . . . . . . . . . . . . . . . . . . . . . 11
3.8. Payload Format . . . . . . . . . . . . . . . . . . . . . 11 3.8. Payload Format . . . . . . . . . . . . . . . . . . . . . 12
3.9. Processing Steps . . . . . . . . . . . . . . . . . . . . 11 3.9. Processing Steps . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . 13
3.10.2. Example 2: File System . . . . . . . . . . . . . . . 12 3.10.2. Example 2: File System . . . . . . . . . . . . . . . 13
3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 12 3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 13
3.11. Component Identifier . . . . . . . . . . . . . . . . . . 12 3.11. Component Identifier . . . . . . . . . . . . . . . . . . 13
3.12. Payload Indicator . . . . . . . . . . . . . . . . . . . . 13 3.12. Payload Indicator . . . . . . . . . . . . . . . . . . . . 13
3.13. Payload Digests . . . . . . . . . . . . . . . . . . . . . 13 3.13. Payload Digests . . . . . . . . . . . . . . . . . . . . . 14
3.14. Size . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.14. Size . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.15. Manifest Envelope Element: Signature . . . . . . . . . . 14 3.15. Manifest Envelope Element: Signature . . . . . . . . . . 14
3.16. Additional Installation Instructions . . . . . . . . . . 14 3.16. Additional Installation Instructions . . . . . . . . . . 15
3.17. Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.17. Manifest text information . . . . . . . . . . . . . . . . 15
3.18. Dependencies . . . . . . . . . . . . . . . . . . . . . . 15 3.18. Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.19. Encryption Wrapper . . . . . . . . . . . . . . . . . . . 15 3.19. Dependencies . . . . . . . . . . . . . . . . . . . . . . 15
3.20. XIP Address . . . . . . . . . . . . . . . . . . . . . . . 15 3.20. Encryption Wrapper . . . . . . . . . . . . . . . . . . . 16
3.21. Load-time Metadata . . . . . . . . . . . . . . . . . . . 15 3.21. XIP Address . . . . . . . . . . . . . . . . . . . . . . . 16
3.22. Run-time metadata . . . . . . . . . . . . . . . . . . . . 16 3.22. Load-time Metadata . . . . . . . . . . . . . . . . . . . 16
3.23. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.23. Run-time metadata . . . . . . . . . . . . . . . . . . . . 17
3.24. Manifest Envelope Element: Delegation Chain . . . . . . . 16 3.24. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.25. Manifest Envelope Element: Delegation Chain . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 17 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 19
4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 17 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 19
4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old 4.2.2. THREAT.IMG.EXPIRED.OFFLINE : Offline device + Old
Firmware . . . . . . . . . . . . . . . . . . . . . . 18 Firmware . . . . . . . . . . . . . . . . . . . . . . 19
4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 18 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 20
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 . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . 21
4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic
payload hosting . . . . . . . . . . . . . . . . . . . 20 payload hosting . . . . . . . . . . . . . . . . . . . 21
4.2.7. THREAT.NET.ONPATH: Traffic interception . . . . . . . 20 4.2.7. THREAT.NET.ONPATH: Traffic interception . . . . . . . 21
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 . . . . . 22
4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor
images . . . . . . . . . . . . . . . . . . . . . . . 21 images . . . . . . . . . . . . . . . . . . . . . . . 22
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 . . . . . . 24
4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest
Elements . . . . . . . . . . . . . . . . . . . . . . 23 Elements . . . . . . . . . . . . . . . . . . . . . . 25
4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element
Exposure . . . . . . . . . . . . . . . . . . . . . . 24 Exposure . . . . . . . . . . . . . . . . . . . . . . 25
4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 24 4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 25
4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 24 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 25
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 . . . . . . . . . . . . . . 26
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 . . . . . . . . . . . . . . . 26
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 . . . . 27
4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 26 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 27
4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 26 4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 27
4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 26 4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 28
4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 27 4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 28
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 . . . . . . . . . . . 28
4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload 27 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote Payload 29
4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 27 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 29
4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor
images . . . . . . . . . . . . . . . . . . . . . . . 28 images . . . . . . . . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . . . . . . . . . . . . . . 29
4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 28 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 29
4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 28 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 30
4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 29 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 30
4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 29 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 31
4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 29 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 31
4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 30 4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to 4.3.18. REQ.SEC.KEY.ROTATION: Protected storage of signing
deployment . . . . . . . . . . . . . . . . . . . . . 30 keys . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a 4.3.19. REQ.SEC.MFST.CHECK: Validate manifests prior to
trusted environment . . . . . . . . . . . . . . . . . 30 deployment . . . . . . . . . . . . . . . . . . . . . 32
4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between 4.3.20. REQ.SEC.MFST.TRUSTED: Construct manifests in a
check and use . . . . . . . . . . . . . . . . . . . . 31 trusted environment . . . . . . . . . . . . . . . . . 32
4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 31 4.3.21. REQ.SEC.MFST.CONST: Manifest kept immutable between
check and use . . . . . . . . . . . . . . . . . . . . 32
4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 33
4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation
Instructions . . . . . . . . . . . . . . . . . . . . 31 Instructions . . . . . . . . . . . . . . . . . . . . 33
4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 31 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 33
4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest
Elements . . . . . . . . . . . . . . . . . . . . . . 32 Elements . . . . . . . . . . . . . . . . . . . . . . 33
4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 32 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 34
4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations . . . 32 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations . . . 34
4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 33 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 34
4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential
Information Disclosures . . . . . . . . . . . . . . . 33 Information Disclosures . . . . . . . . . . . . . . . 35
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 . . . . . . . . . . . . . . 35
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 . . . . . . . . . . . . . 35
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 . . . . . . . . . . . . . . . . . . . 35
4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using
Manifests . . . . . . . . . . . . . . . . . . . . . . 34 Manifests . . . . . . . . . . . . . . . . . . . . . . 36
4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 34 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 36
4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 34 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 36
4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 34 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 36
4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in
Manifest . . . . . . . . . . . . . . . . . . . . . . 35 Manifest . . . . . . . . . . . . . . . . . . . . . . 36
4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 35 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 37
4.5. Usability Requirements . . . . . . . . . . . . . . . . . 35 4.4.17. USER_STORY.MFST.ADMINISTRATION: Administration of
4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 35 manifests . . . . . . . . . . . . . . . . . . . . . . 37
4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 37
Resource Location . . . . . . . . . . . . . . . . . . 35 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 37
4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 36 4.5.2. REQ.USE.MFST.TEXT: Descriptive Manifest Information . 37
4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 37 4.5.3. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote
4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 37 Resource Location . . . . . . . . . . . . . . . . . . 38
4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 37 4.5.4. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 38
4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 38 4.5.5. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 39
4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 38 4.5.6. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 39
4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 38 4.5.7. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 40
4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 38 4.5.8. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 40
4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope . . . . 38 4.5.9. REQ.USE.IMG.SELECT: Select Image by Destination . . . 40
4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 39 4.5.10. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 40
4.5.13. REQ.USE.DELEGATION: Delegation of Authority in 4.5.11. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 41
Manifest . . . . . . . . . . . . . . . . . . . . . . 40 4.5.12. REQ.USE.PAYLOAD: Payload in Manifest Envelope . . . . 41
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 4.5.13. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 42
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 4.5.14. REQ.USE.DELEGATION: Delegation of Authority in
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 Manifest . . . . . . . . . . . . . . . . . . . . . . 42
7.1. Normative References . . . . . . . . . . . . . . . . . . 40 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
7.2. Informative References . . . . . . . . . . . . . . . . . 41 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.1. Normative References . . . . . . . . . . . . . . . . . . 43
7.2. Informative References . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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 6, line 29 skipping to change at page 6, line 33
2.2. Terminology 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 both authenticated and guaranteed to be correct to within
whenever the time source is accessible. some predetermined bounds, 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", 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
skipping to change at page 7, line 38 skipping to change at page 7, line 38
The Vendor ID element helps to distinguish between identically named The Vendor ID element helps to distinguish between identically named
products from different vendors. Vendor ID is not intended to be a products from different vendors. Vendor ID is not intended to be a
human-readable element. It is intended for binary match/mismatch human-readable element. It is intended for binary match/mismatch
comparison only. comparison only.
Recommended practice is to use [RFC4122] version 5 UUIDs with the Recommended practice is to use [RFC4122] version 5 UUIDs with the
vendor's domain name and the DNS name space ID. Other options vendor's domain name and the DNS name space ID. Other options
include type 1 and type 4 UUIDs. include type 1 and type 4 UUIDs.
Fixed-size binary identifiers are preferred because they are simple
to match, unambiguous in length, explicitly non-parsable, and require
no issuing authority. Guaranteed unique integers are preferred
because they are small and simple to match, however they may not be
fixed length and they may require an issuing authority to ensure
uniqueness. Free-form text is avoided because it is variable-length,
prone to error, and often requires parsing outside the scope of the
manifest serialization.
If human-readable content is required, it SHOULD be contained in a
separate manifest information element: Manifest text information
(Section 3.17)
This element is RECOMMENDED. This element is RECOMMENDED.
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).
Here is an example for a domain name-based UUID. Vendor A creates a 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 = UUID based on a domain name it controls, such as vendorId =
UUID5(DNS, "vendor-a.example") UUID5(DNS, "vendor-a.example")
Because the DNS infrastructure prevents multiple registrations of the Because the DNS infrastructure prevents multiple registrations of the
skipping to change at page 8, line 44 skipping to change at page 9, line 8
o silicon batch number o silicon batch number
The Class ID UUID should use the Vendor ID as the name space The Class ID UUID should use the Vendor ID as the name space
identifier. Other options include version 1 and 4 UUIDs. Classes identifier. Other options include version 1 and 4 UUIDs. Classes
may be more fine-grained granular than is required to identify may be more fine-grained granular than is required to identify
firmware compatibility. Classes must not be less granular than is firmware compatibility. Classes must not be less granular than is
required to identify firmware compatibility. Devices may have required to identify firmware compatibility. Devices may have
multiple Class 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. A manifest
serialization SHOULD NOT permit free-form text content to be used for
Class ID. A fixed-size binary identifier SHOULD be used.
Some organizations desire to keep the same product naming across
multiple, incompatible hardware revisions for ease of user
experience. If this naming is propagated into the firmware, then
matching a specific hardware version becomes a challenge. An opaque,
non-readable binary identifier has no naming implications and so is
more likely to be usable for distinguishing among incompatible device
groupings, regardless of naming.
Fixed-size binary identifiers are preferred because they are simple
to match, unambiguous in length, opaque and free from naming
implications, and explicitly non-parsable. Free-form text is avoided
because it is variable-length, prone to error, often requires parsing
outside the scope of the manifest serialization, and may be
homogenized across incompatible device groupings.
If 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.
This element is RECOMMENDED. 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
skipping to change at page 11, line 9 skipping to change at page 11, line 41
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. This element is OPTIONAL.
Implements: REQ.USE.IMG.VERSIONS (Section 4.5.7) Implements: REQ.USE.IMG.VERSIONS (Section 4.5.8)
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.
skipping to change at page 11, line 37 skipping to change at page 12, line 22
Implements: REQ.SEC.EXP (Section 4.3.3) Implements: REQ.SEC.EXP (Section 4.3.3)
3.8. Payload Format 3.8. Payload Format
This element describes the payload format within the signed metadata. This element describes the payload format within the signed metadata.
It is used to enable devices to decode payloads correctly. It is used to enable devices to decode payloads correctly.
This element is REQUIRED. This element is REQUIRED.
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.6)
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 algorithms are encrypted. The representation must describe which algorithms are
used and must convey any additional parameters required by those used and must convey any additional parameters required by those
algorithms. algorithms.
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.
This element is RECOMMENDED. This element is RECOMMENDED.
Implements: REQ.USE.IMG.NESTED (Section 4.5.6) Implements: REQ.USE.IMG.NESTED (Section 4.5.7)
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. This element is REQUIRED.
Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6) Implements: REQ.SEC.AUTH.IMG_LOC (Section 4.3.6)
skipping to change at page 12, line 52 skipping to change at page 13, line 40
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 to which payload. To resolve this, a component identifier indicates to which
part of the storage subsystem the payload shall be placed. part of the storage subsystem the payload shall be placed.
A serialization may choose to combine Component Identifier and A serialization may choose to combine Component Identifier and
Storage Location (Section 3.10). Storage Location (Section 3.10).
This element is OPTIONAL. This element is OPTIONAL.
Implements: REQ.USE.MFST.COMPONENT (Section 4.5.3) Implements: REQ.USE.MFST.COMPONENT (Section 4.5.4)
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 functionality is only needed when the acquire the payload. This functionality is only needed when the
target device does not intrinsically know where to find the payload. target device does not intrinsically know where to find the payload.
This can be encoded in several ways: This can be encoded in several ways:
o One URI o One URI
skipping to change at page 13, line 38 skipping to change at page 14, line 25
This allows the target device to ensure authenticity of the This allows the target device to ensure authenticity of the
payload(s) when combined with the Signature (Section 3.15) element. payload(s) when combined with the Signature (Section 3.15) element.
A manifest format must provide a mechanism to select one payload from A manifest format must provide a mechanism to select one payload from
a list based on system parameters, such as Execute-In-Place a list based on system parameters, such as Execute-In-Place
Installation Address. Installation Address.
This element is REQUIRED. Support for more than one digest is This element is REQUIRED. Support for more than one digest is
OPTIONAL. OPTIONAL.
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.9)
3.14. Size 3.14. Size
The size of the payload in bytes, which informs the target device how 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 big of a payload to expect. Without it, devices are exposed to some
classes of denial of service attack. classes of denial of service attack.
This element is REQUIRED. This element is REQUIRED.
Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8) Implements: REQ.SEC.AUTH.EXEC (Section 4.3.8)
skipping to change at page 14, line 28 skipping to change at page 15, line 12
the recipient can distinguish between different actors with different the recipient can distinguish between different actors with different
permissions. permissions.
The Signature element must support multiple signers and multiple The Signature element must support multiple signers and multiple
signing algorithms. A manifest format may allow multiple manifests signing algorithms. A manifest format may allow multiple manifests
to be covered by a single Signature element. to be covered by a single Signature element.
This element is REQUIRED in non-dependency manifests. This element is REQUIRED in non-dependency manifests.
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.5)
3.16. Additional Installation Instructions 3.16. Additional Installation Instructions
Additional installation instructions are machine-readable commands Additional installation instructions are machine-readable commands
the device should execute when processing the manifest. This the device should execute when processing the manifest. This
information is distinct from the information necessary to process a information is distinct from the information necessary to process a
payload. Additional installation instructions include information payload. Additional installation instructions include information
such as update timing (for example, install only on Sunday, at 0200), such as update timing (for example, install only on Sunday, at 0200),
procedural considerations (for example, shut down the equipment under procedural considerations (for example, shut down the equipment under
control before executing the update), pre- and post-installation control before executing the update), pre- and post-installation
steps (for example, run a script). Other installation instructions steps (for example, run a script). Other installation instructions
could include requesting user confirmation before installing. could include requesting user confirmation before installing.
This element is OPTIONAL. 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. Manifest text information
Textual information pertaining to the update described by the
manifest. This information is for human consumption only. It MUST
NOT be the basis of any decision made by the recipient.
Implements: REQ.USE.MFST.TEXT (Section 4.5.2)
3.18. 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. This element is OPTIONAL.
Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) Implements: REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.3)
3.18. Dependencies 3.19. 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 support 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.4)
3.19. Encryption Wrapper 3.20. 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. firmware.
This element is REQUIRED 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.21. 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. This element is OPTIONAL.
Implements: REQ.USE.IMG.SELECT (Section 4.5.8) Implements: REQ.USE.IMG.SELECT (Section 4.5.9)
3.21. Load-time Metadata 3.22. 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 (e.g. non-volatile storage)
o the destination (e.g. an address in RAM)
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. This element is OPTIONAL.
Implements: REQ.USE.LOAD (Section 4.5.10) Implements: REQ.USE.LOAD (Section 4.5.11)
3.22. Run-time metadata 3.23. 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 the entry-point of an needed to boot the device. This may include the entry-point of an
XIP image or the kernel command-line to boot a Linux image. XIP image or the kernel command-line to boot a Linux image.
This element is OPTIONAL. This element is OPTIONAL.
Implements: REQ.USE.EXEC (Section 4.5.9) Implements: REQ.USE.EXEC (Section 4.5.10)
3.23. Payload 3.24. Payload
The Payload element is contained within the manifest or manifest The Payload element is contained within the manifest or manifest
envelope and enables the manifest and payload to be delivered envelope and enables the manifest and payload to be delivered
simultaneously. This is used for delivering small payloads, such as simultaneously. This is used for delivering small payloads, such as
cryptographic keys or configuration data. cryptographic keys or configuration data.
This element is OPTIONAL. This element is OPTIONAL.
Implements: REQ.USE.PAYLOAD (Section 4.5.11) Implements: REQ.USE.PAYLOAD (Section 4.5.12)
3.24. Manifest Envelope Element: Delegation Chain 3.25. Manifest Envelope Element: Delegation Chain
The delegation chain offers enhanced authorization functionality via The delegation chain offers enhanced authorization functionality via
authorization tokens. Each token itself is protected and does not authorization tokens, such as CBOR Web Tokens [RFC8392] with Proof of
require another layer of protection. Because the delegation chain is Possession Key Semantics [RFC8747]. Each token itself is protected
needed to verify the signature, it must be placed in the Manifest and does not require another layer of protection. Each authorization
Envelope, rather than the Manifest. token typically includes a public key or a public key fingerprint,
however this is dependent on the tokens used. Each token MAY include
additional metadata, such as key usage information. Because the
delegation chain is needed to verify the signature, it must be placed
in the Manifest Envelope, rather than the Manifest.
The first token in any delegation chain MUST be autheticated by the
recipient's Trust Anchor. Each subsequent token MUST be
authenticated using the previous token. This allows a recipient to
discard each antecedent token after it has authenticated the
subsequent token. The final token MUST enable authentication of the
manifest. More than one delegation chain MAY be used if more than
one signature is used. Note that no restriction is placed on the
encoding order of these tokens, the order of elements is logical
only.
This element is OPTIONAL. This element is OPTIONAL.
Implements: REQ.USE.DELEGATION (Section 4.5.13) Implements: REQ.USE.DELEGATION (Section 4.5.14), REQ.SEC.KEY.ROTATION
(Section 4.3.18)
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.
Note that it is worthwhile to recall that a firmware update is, by Note that it is worthwhile to recall that a firmware update is, by
definition, remote code execution. Hence, if a device is configured definition, remote code execution. Hence, if a device is configured
skipping to change at page 17, line 48 skipping to change at page 19, line 9
o Elevation of privilege o Elevation of privilege
This threat model only covers elements related to the transport of This threat model only covers elements related to the transport of
firmware updates. It explicitly does not cover threats outside of firmware updates. It explicitly does not cover threats outside of
the transport of firmware updates. For example, threats to an IoT the transport of firmware updates. For example, threats to an IoT
device due to physical access are out of scope. device due to physical access are out of scope.
4.2. Threat Descriptions 4.2. Threat Descriptions
Many of the threats detailed in this section contain a "threat
escalation" description. This explains how the described threat
might fit together with other threats and produce a high severity
threat. This is important because some of the described threats may
seem low severity but could be used with others to construct a high
severity compromise.
4.2.1. THREAT.IMG.EXPIRED: Old Firmware 4.2.1. THREAT.IMG.EXPIRED: Old Firmware
Classification: Elevation of Privilege Classification: Elevation of Privilege
An attacker sends an old, but valid manifest with an old, but valid An attacker sends an old, but valid manifest with an old, but valid
firmware image to a device. If there is a known vulnerability in the firmware image to a device. If there is a known vulnerability in the
provided firmware image, this may allow an attacker to exploit the provided firmware image, this may allow an attacker to exploit the
vulnerability and gain control of the device. vulnerability and gain control of the device.
Threat Escalation: If the attacker is able to exploit the known Threat Escalation: If the attacker is able to exploit the known
vulnerability, then this threat can be escalated to ALL TYPES. vulnerability, then this threat can be escalated to ALL TYPES.
Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1) Mitigated by: REQ.SEC.SEQUENCE (Section 4.3.1)
skipping to change at page 24, line 41 skipping to change at page 26, line 7
example in an hardware security module (HSM), then they can perform example in an hardware security module (HSM), then they can perform
the same actions as the legitimate owner of the key. If the key is the same actions as the legitimate owner of the key. If the key is
trusted for firmware update, then the third party can perform trusted for firmware update, then the third party can perform
firmware updates as though 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),
REQ.SEC.KEY.ROTATION (Section 4.3.18)
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
Classification: All Types Classification: All Types
If an attacker can alter a manifest or payload before it is signed, If an attacker can alter a manifest or payload before it is signed,
they can perform all the same actions as the manifest author. This they can perform all the same actions as the manifest author. This
allows the attacker to deploy firmware updates to any devices that allows the attacker to deploy firmware updates to any devices that
trust the manifest author. If an attacker can modify the code of a trust the manifest author. If an attacker can modify the code of a
skipping to change at page 25, line 15 skipping to change at page 26, line 31
signed, they can redirect the manifest to their own payload. signed, they can redirect the manifest to their own payload.
For example, the attacker deploys malware to the developer's computer For example, the attacker deploys malware to the developer's computer
or signing service that watches manifest creation activities and or signing service that watches manifest creation activities and
inserts code into any binary that is referenced by a manifest. inserts code into any binary that is referenced by a manifest.
For example, the attacker deploys malware to the developer's computer For example, the attacker deploys malware to the developer's computer
or signing service that replaces the referenced binary (digest) and or signing service that replaces the referenced binary (digest) and
URI with the attacker's binary (digest) and URI. URI with the attacker's binary (digest) and URI.
Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.18), Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.19),
REQ.SEC.MFST.TRUSTED (Section 4.3.19) REQ.SEC.MFST.TRUSTED (Section 4.3.20)
4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between 4.2.18. THREAT.MFST.TOCTOU: Modification of manifest between
authentication and use authentication and use
Classification: All Types Classification: All Types
If an attacker can modify a manifest after it is authenticated (Time If an attacker can modify a manifest after it is authenticated (Time
Of Check) but before it is used (Time Of Use), then the attacker can Of Check) but before it is used (Time Of Use), then the attacker can
place any content whatsoever in the manifest. place any content whatsoever in the manifest.
Mitigated by: REQ.SEC.MFST.CONST (Section 4.3.20) Mitigated by: REQ.SEC.MFST.CONST (Section 4.3.21)
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,
skipping to change at page 26, line 32 skipping to change at page 28, line 5
have a secure clock (local or remote). If a secure clock is provided have a secure clock (local or remote). If a secure clock is provided
and the Firmware manifest has an expiration timestamp, the device and the Firmware manifest has an expiration timestamp, the device
must reject the manifest if current time is later than the expiration must reject the manifest if current time is later than the expiration
time. time.
Special consideration is required for end-of-life in case device 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
for 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.
If a device has a flawed time source (either local or remote), an old
update can be deployed as new.
Mitigates: THREAT.IMG.EXPIRED.OFFLINE (Section 4.2.2) 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
skipping to change at page 29, line 10 skipping to change at page 30, line 31
Encryption helps to prevent third parties, including attackers, from Encryption helps to prevent third parties, including attackers, from
reading the content of the firmware image. This can protect against reading the content of the firmware image. This can protect against
confidential information disclosures and discovery of vulnerabilities confidential information disclosures and discovery of vulnerabilities
through reverse engineering. Therefore the manifest must convey the through reverse engineering. Therefore the manifest must convey the
information required to allow an intended recipient to decrypt an information required to allow an intended recipient to decrypt an
encrypted payload. encrypted payload.
Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.ONPATH Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.ONPATH
(Section 4.2.7) (Section 4.2.7)
Implemented by: Encryption Wrapper (Section 3.19) Implemented by: Encryption Wrapper (Section 3.20)
4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control
If a device grants different rights to different actors, then an If a device grants different rights to different actors, then an
exercise of those rights MUST be validated against a list of rights exercise of those rights MUST be validated against a list of rights
for the actor. This typically takes the form of an Access Control for the actor. This typically takes the form of an Access Control
List (ACL). ACLs are applied to two scenarios: List (ACL). ACLs are applied to two scenarios:
1. An ACL decides which elements of the manifest may be overridden 1. An ACL decides which elements of the manifest may be overridden
and by which actors. and by which actors.
skipping to change at page 30, line 30 skipping to change at page 32, line 5
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.
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.KEY.ROTATION: Protected storage of signing keys
Cryptographic keys for signing/authenticating manifests SHOULD be
replaced from time to time. Because it is difficult and risky to
replace a Trust Anchor, keys used for signing updates SHOULD be
delegates of that Trust Anchor.
If key expiration is performed based on time, then a secure clock is
needed. If the time source used by a recipient to check for
expiration is flawed, an old signing key can be used as current,
which compounds THREAT.KEY.EXPOSURE (Section 4.2.16).
Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16)
4.3.19. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment
Manifests SHOULD be verified prior to deployment. This reduces Manifests SHOULD be verified prior to deployment. This reduces
problems that may arise with devices installing firmware images that problems that may arise with devices installing firmware images that
damage devices unintentionally. 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.20. 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
does not fulfill this requirement (see THREAT.MFST.MODIFICATION does not fulfill this requirement (see THREAT.MFST.MODIFICATION
(Section 4.2.17)). (Section 4.2.17)).
Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17) Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17)
4.3.20. REQ.SEC.MFST.CONST: Manifest kept immutable between check and 4.3.21. REQ.SEC.MFST.CONST: Manifest kept immutable between check and
use use
Both the manifest and any data extracted from it MUST be held Both the manifest and any data extracted from it MUST be held
immutable between its authenticity verification (time of check) and immutable between its authenticity verification (time of check) and
its use (time of use). To make this guarantee, the manifest MUST fit its use (time of use). To make this guarantee, the manifest MUST fit
within an internal memory or a secure memory, such as encrypted within an internal memory or a secure memory, such as encrypted
memory. The recipient SHOULD defend the manifest from tampering by memory. The recipient SHOULD defend the manifest from tampering by
code or hardware resident in the recipient, for example other code or hardware resident in the recipient, for example other
processes or debuggers. processes or debuggers.
skipping to change at page 32, line 33 skipping to change at page 34, line 21
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: REQ.USE.MFST.COMPONENT (Section 4.5.3) Satisfied by: REQ.USE.MFST.COMPONENT (Section 4.5.4)
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.4)
4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorizations
As a Device Operator, I want to ensure the quality of a firmware As a Device Operator, I want to ensure the quality of a firmware
update before installing it, so that I can ensure interoperability of update before installing it, so that I can ensure interoperability of
all devices in my product family. I want to restrict the ability to all devices in my product family. I want to restrict the ability to
make changes to my devices to require my express approval. make changes to my devices to require my express approval.
Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.4), Satisfied by: REQ.USE.MFST.MULTI_AUTH (Section 4.5.5),
REQ.SEC.ACCESS_CONTROL (Section 4.3.13) REQ.SEC.ACCESS_CONTROL (Section 4.3.13)
4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats
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.6)
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 in As a firmware author, I want to prevent confidential information in
the manifest from being disclosed when distributing manifests and the manifest from being disclosed when distributing manifests and
firmware images. Confidential information may include information firmware images. Confidential information may include information
about the device these updates are being applied to as well as about the device these updates are being applied to as well as
information in the firmware image itself. information in the firmware image itself.
skipping to change at page 33, line 38 skipping to change at page 35, line 30
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 Payload This amounts to overriding Processing Steps (Section 3.9) and Payload
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.6), REQ.USE.IMG.NESTED
(Section 4.5.6), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.2) (Section 4.5.7), REQ.USE.MFST.OVERRIDE_REMOTE (Section 4.5.3)
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.
Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.7) Satisfied by: REQ.USE.IMG.VERSIONS (Section 4.5.8)
4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose Between Images
As a developer, I want to be able to sign two or more versions of my As a developer, I want to be able to sign two or more versions of my
firmware in a single manifest so that I can use a very simple firmware in a single manifest so that I can use a very simple
bootloader that chooses between two or more images that are executed bootloader that chooses between two or more images that are executed
in-place. in-place.
Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.8) Satisfied by: REQ.USE.IMG.SELECT (Section 4.5.9)
4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using Manifests
As a signer for both secure execution/boot and firmware deployment, I As a signer for both secure execution/boot and firmware deployment, I
would like to use the same signed document for both tasks so that my would like to use the same signed document for both tasks so that my
data size is smaller, I can share common code, and I can reduce data size is smaller, I can share common code, and I can reduce
signature verifications. signature verifications.
Satisfied by: REQ.USE.EXEC (Section 4.5.9) Satisfied by: REQ.USE.EXEC (Section 4.5.10)
4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load
As a developer of firmware for a run-from-RAM device, I would like to As a developer of firmware for a run-from-RAM device, I would like to
use compressed images and to indicate to the bootloader that I am use compressed images and to indicate to the bootloader that I am
using a compressed image in the manifest so that it can be used with using a compressed image in the manifest so that it can be used with
secure execution/boot. secure execution/boot.
Satisfied by: REQ.USE.LOAD (Section 4.5.10) Satisfied by: REQ.USE.LOAD (Section 4.5.11)
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 content encryption Small payloads may include, for example, wrapped content encryption
keys, configuration information, public keys, authorization tokens, keys, configuration information, public keys, authorization tokens,
or X.509 certificates. or X.509 certificates.
Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11) Satisfied by: REQ.USE.PAYLOAD (Section 4.5.12)
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.13)
4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest
As a Device Operator that rotates delegated authority more often than As a Device Operator that rotates delegated authority more often than
delivering firmware updates, I would like to delegate a new authority delivering firmware updates, I would like to delegate a new authority
when I deliver a firmware update so that I can accomplish both tasks when I deliver a firmware update so that I can accomplish both tasks
in a single transmission. in a single transmission.
Satisfied by: REQ.USE.DELEGATION (Section 4.5.13) Satisfied by: REQ.USE.DELEGATION (Section 4.5.14)
4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation
As an operator of a constrained network, I would like devices on my As an operator of a constrained network, I would like devices on my
network to be able to evaluate the suitability of an update prior to network to be able to evaluate the suitability of an update prior to
initiating any large download so that I can prevent unnecessary initiating any large download so that I can prevent unnecessary
consumption of bandwidth. consumption of bandwidth.
Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1) Satisfied by: REQ.USE.MFST.PRE_CHECK (Section 4.5.1)
4.4.17. USER_STORY.MFST.ADMINISTRATION: Administration of manifests
As a Device Operator, I want to understand what an update will do and
to which devices it applies so that I can make informed choices about
which updates to apply, when to apply them, and which devices should
be updated.
Satisfied by REQ.USE.MFST.TEXT (Section 4.5.2)
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
A manifest format MUST be able to carry all information required to A manifest format MUST be able to carry all information required to
process an update. 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. a differential update must be placed in the manifest.
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.TEXT: Descriptive Manifest Information
It MUST be possible for a Device Operator to determine what a
manifest will do and which devices will accept it prior to
distribution.
Satisfies: USER_STORY.MFST.ADMINISTRATION (Section 4.4.17)
Implemented by: Manifest text information (Section 3.17)
4.5.3. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote Resource Location
A manifest format MUST be able to redirect payload fetches. This A manifest format MUST be able to redirect payload fetches. This
applies where two manifests are used in conjunction. For example, a applies where two manifests are used in conjunction. For example, a
Device Operator creates a manifest specifying a payload and signs it, Device Operator creates a manifest specifying a payload and signs it,
and provides a URI for that payload. A Network Operator creates a and provides a URI for that payload. A Network Operator creates a
second manifest, with a dependency on the first. They use this second manifest, with a dependency on the first. They use this
second 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.18)
4.5.3. REQ.USE.MFST.COMPONENT: Component Updates 4.5.4. REQ.USE.MFST.COMPONENT: Component Updates
A manifest format MUST be able to express the requirement to install A manifest format MUST be able to express the requirement to install
one or more payloads from one or more authorities so that a multi- one or more payloads from one or more authorities so that a multi-
payload update can be described. This allows multiple parties with payload update can be described. This allows multiple parties with
different permissions to collaborate in creating a single update for different permissions to collaborate in creating a single update for
the IoT device, across multiple components. the IoT device, across multiple components.
This requirement implies that it must be possible to construct a tree This requirement implies that it must be possible to 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.4.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.4.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.
4.5.3.3. Example 3: Multiple Software Modules 4.5.4.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.5. REQ.USE.MFST.MULTI_AUTH: Multiple authentications
A manifest format MUST be able to carry multiple signatures 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.6. 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
Operator wishes to use. This enables the recipient to detect which Operator wishes to use. This enables the recipient to detect which
format the Operator has chosen. Some examples of payload format are: format the Operator has chosen. Some examples of payload format are:
o Binary o Binary
o Executable and Linkable Format (ELF) o Executable and Linkable Format (ELF)
o Differential o Differential
skipping to change at page 37, line 36 skipping to change at page 40, line 4
o Differential o Differential
o Compressed o Compressed
o Packed configuration o Packed configuration
o Intel HEX o Intel HEX
o Motorola S-Record o Motorola S-Record
Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6) Satisfies: USER_STORY.IMG.FORMAT (Section 4.4.6)
USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8) USER_STORY.IMG.UNKNOWN_FORMAT (Section 4.4.8)
Implemented by: Payload Format (Section 3.8) Implemented by: Payload Format (Section 3.8)
4.5.6. REQ.USE.IMG.NESTED: Nested Formats 4.5.7. REQ.USE.IMG.NESTED: Nested Formats
The manifest format MUST accommodate nested formats, announcing to The manifest format MUST accommodate nested formats, announcing to
the target device all the nesting steps and any parameters used by the target device all the nesting steps and any parameters used by
those steps. those steps.
Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7) Satisfies: USER_STORY.IMG.CONFIDENTIALITY (Section 4.4.7)
Implemented by: Processing Steps (Section 3.9) Implemented by: Processing Steps (Section 3.9)
4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching 4.5.8. REQ.USE.IMG.VERSIONS: Target Version Matching
The manifest format MUST provide a method to specify multiple version The manifest format MUST provide a method to specify multiple version
numbers of firmware to which the manifest applies, either with a list numbers of firmware to which the manifest applies, either with a list
or with range matching. or with range matching.
Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9) Satisfies: USER_STORY.IMG.CURRENT_VERSION (Section 4.4.9)
Implemented by: Required Image Version List (Section 3.6) Implemented by: Required Image Version List (Section 3.6)
4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination 4.5.9. REQ.USE.IMG.SELECT: Select Image by Destination
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.21)
4.5.9. REQ.USE.EXEC: Executable Manifest 4.5.10. REQ.USE.EXEC: Executable Manifest
The manifest format MUST allow to describe an executable system with The manifest format MUST allow to describe an executable system with
a manifest on both Execute-In-Place microcontrollers and on complex a manifest on both Execute-In-Place microcontrollers and on complex
operating systems. In addition, the manifest format MUST be able to operating systems. In addition, the manifest format MUST be able to
express metadata, such as a kernel command-line, used by any loader express metadata, such as a kernel command-line, used by any loader
or bootloader. 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.23)
4.5.10. REQ.USE.LOAD: Load-Time Information 4.5.11. REQ.USE.LOAD: Load-Time Information
The manifest format MUST enable carrying additional metadata for load The manifest format MUST enable carrying additional metadata for load
time processing of a payload, such as cryptographic information, time processing of a payload, such as cryptographic information,
load-address, and compression algorithm. Note that load comes before load-address, and compression algorithm. Note that load comes before
execution/boot. execution/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.22)
4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Envelope 4.5.12. REQ.USE.PAYLOAD: Payload in Manifest Envelope
The manifest format MUST allow placing a payload in the same The manifest format MUST allow placing a payload in the same
structure as the manifest. This may place the payload in the same structure as the manifest. This may place the payload in the same
packet as the manifest. packet as the manifest.
Integrated payloads may include, for example, binaries as well as Integrated payloads may include, for example, binaries as well as
configuration information, and keying material. configuration information, and keying material.
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.21)), so a larger manifest will consume more memory with
immutability guarantees, for example internal RAM or NVRAM, or immutability guarantees, for example internal RAM or NVRAM, or
external secure memory. If the manifest exceeds the available external secure memory. If the manifest exceeds the available
immutable memory, then it MUST be processed modularly, evaluating immutable memory, then it MUST be processed modularly, evaluating
each of: delegation chains, the security container, and the actual each of: delegation chains, the security container, and the actual
manifest, which includes verifying the integrated payload. If the manifest, which includes verifying the integrated payload. If the
security model calls for downloading the manifest and validating it security model calls for downloading the manifest and validating it
before storing to NVRAM in order to prevent wear to NVRAM and energy before storing to NVRAM in order to prevent wear to NVRAM and energy
expenditure in NVRAM, then either increasing memory allocated to expenditure in NVRAM, then either increasing memory allocated to
manifest storage or modular processing of the received manifest may manifest storage or modular processing of the received manifest may
be required. While the manifest has been organised to enable this be required. While the manifest has been organised to enable this
type of processing, it creates additional complexity in the parser. type of processing, it creates additional complexity in the parser.
If the manifest is stored in NVRAM prior to processing, the If the manifest is stored in NVRAM prior to processing, the
integrated payload may cause the manifest to exceed the available integrated payload may cause the manifest to exceed the available
storage. Because the manifest is received prior to validation of storage. Because the manifest is received prior to validation of
applicability, authority, or correctness, integrated payloads cause applicability, authority, or correctness, integrated payloads cause
the recipient to expend network bandwidth and energy that may not be the recipient to expend network bandwidth and energy that may not be
required if the manifest is discarded and these costs vary with the required if the manifest is discarded and these costs vary with the
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.21).
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.24)
4.5.12. REQ.USE.PARSE: Simple Parsing 4.5.13. REQ.USE.PARSE: Simple Parsing
The structure of the manifest MUST be simple to parse to reduce the The structure of the manifest MUST be simple to parse to reduce the
attack vectors against manifest parsers. 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.14. REQ.USE.DELEGATION: Delegation of Authority in Manifest
A manifest format MUST enable the delivery of delegation information. A manifest format MUST enable the delivery of delegation information.
This information delivers a new key with which the recipient can This information delivers a new key 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.25)
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
We would like to thank our working group chairs, Dave Thaler, Russ We would like to thank our working group chairs, Dave Thaler, Russ
Housley and David Waltermire, for their review comments and their Housley and David Waltermire, for their review comments and their
support. support.
skipping to change at page 40, line 51 skipping to change at page 43, line 18
review feedback: Erik Kline, Murray Kucherawy, Barry Leiba, Alissa review feedback: Erik Kline, Murray Kucherawy, Barry Leiba, Alissa
Cooper, Stephen Farrell 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-16 (work in progress),
January 2021. 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>.
[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>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>.
7.2. Informative References 7.2. Informative References
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>. <https://www.rfc-editor.org/info/rfc3444>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
 End of changes. 109 change blocks. 
187 lines changed or deleted 298 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/