< draft-ietf-suit-information-model-03.txt   draft-ietf-suit-information-model-04.txt >
SUIT B. Moran SUIT B. Moran
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Intended status: Standards Track Arm Limited Intended status: Standards Track Arm Limited
Expires: January 9, 2020 H. Birkholz Expires: May 2, 2020 H. Birkholz
Fraunhofer SIT Fraunhofer SIT
July 08, 2019 October 30, 2019
Firmware Updates for Internet of Things Devices - An Information Model An Information Model for Firmware Updates in IoT Devices
for Manifests draft-ietf-suit-information-model-04
draft-ietf-suit-information-model-03
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 solid and secure firmware update mechanism that is also need for a solid and secure firmware update mechanism that is also
suitable for constrained devices. Incorporating such an update suitable for constrained devices. Ensuring that devices function and
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 is recommended by security as well as adding new functionality
experts.
One component of such a firmware update is a concise and machine- One component of such a firmware update is a concise and machine-
processable meta-data document, or manifest, that describes the processable meta-data document, or manifest, that describes the
firmware image(s) and offers appropriate protection. This document firmware image(s) and offers appropriate protection. This document
describes the information that must be present in the manifest. describes the information that must be present in the manifest.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 43 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 January 9, 2020. This Internet-Draft will expire on May 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 30 skipping to change at page 2, line 30
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
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. Manifest Element: Version ID of the manifest structure . 6
3.2. Manifest Element: Monotonic Sequence Number . . . . . . . 6 3.2. Manifest Element: Monotonic Sequence Number . . . . . . . 6
3.3. Manifest Element: Vendor ID . . . . . . . . . . . . . . . 6 3.3. Manifest Element: 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. Manifest Element: Class ID . . . . . . . . . . . . . . . 7
3.4.1. Example 1: Different Classes . . . . . . . . . . . . 8 3.4.1. Example 1: Different Classes . . . . . . . . . . . . 8
3.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 8 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.5. Manifest Element: Precursor Image Digest Condition . . . 9 3.5. Manifest Element: Precursor Image Digest Condition . . . 9
3.6. Manifest Element: Required Image Version List . . . . . . 9 3.6. Manifest Element: Required Image Version List . . . . . . 10
3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10 3.7. Manifest Element: Expiration Time . . . . . . . . . . . . 10
3.8. Manifest Element: Payload Format . . . . . . . . . . . . 10 3.8. Manifest Element: Payload Format . . . . . . . . . . . . 10
3.9. Manifest Element: Processing Steps . . . . . . . . . . . 10 3.9. Manifest Element: Processing Steps . . . . . . . . . . . 11
3.10. Manifest Element: Storage Location . . . . . . . . . . . 11 3.10. Manifest Element: Storage Location . . . . . . . . . . . 11
3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 11 3.10.1. Example 1: Two Storage Locations . . . . . . . . . . 11
3.10.2. Example 2: File System . . . . . . . . . . . . . . . 11 3.10.2. Example 2: File System . . . . . . . . . . . . . . . 11
3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 11 3.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 12
3.11. Manifest Element: Component Identifier . . . . . . . . . 11 3.11. Manifest Element: Component Identifier . . . . . . . . . 12
3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12 3.12. Manifest Element: Resource Indicator . . . . . . . . . . 12
3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 12 3.13. Manifest Element: Payload Digests . . . . . . . . . . . . 12
3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 12 3.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 13
3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 13 3.15. Manifest Element: Signature . . . . . . . . . . . . . . . 13
3.16. Manifest Element: Additional installation instructions . 13 3.16. Manifest Element: Additional installation instructions . 13
3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 13 3.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 14
3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 13 3.18. Manifest Element: Dependencies . . . . . . . . . . . . . 14
3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 14 3.19. Manifest Element: Encryption Wrapper . . . . . . . . . . 14
3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 14 3.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 14
3.21. Manifest Element: Load-time metadata . . . . . . . . . . 14 3.21. Manifest Element: Load-time metadata . . . . . . . . . . 15
3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 14 3.22. Manifest Element: Run-time metadata . . . . . . . . . . . 15
3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 15 3.23. Manifest Element: Payload . . . . . . . . . . . . . . . . 15
3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 15 3.24. Manifest Element: Key Claims . . . . . . . . . . . . . . 15
4. Motivation for Manifest Fields . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 16 4.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 16
4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 16 4.2.1. THREAT.IMG.EXPIRED: Old Firmware . . . . . . . . . . 16
4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old 4.2.2. THREAT.IMG.EXPIRED.ROLLBACK : Offline device + Old
Firmware . . . . . . . . . . . . . . . . . . . . . . 16 Firmware . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 16 4.2.3. THREAT.IMG.INCOMPATIBLE: Mismatched Firmware . . . . 17
4.2.4. THREAT.IMG.FORMAT: The target device misinterprets 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets
the type of payload . . . . . . . . . . . . . . . . . 17 the type of payload . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . 17 payload to the wrong location . . . . . . . . . . . . 18
4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic
payload hosting . . . . . . . . . . . . . . . . . . . 18 payload hosting . . . . . . . . . . . . . . . . . . . 18
4.2.7. THREAT.NET.MITM . . . . . . . . . . . . . . . . . . . 18 4.2.7. THREAT.NET.MITM: Traffic interception . . . . . . . . 18
4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 18 4.2.8. THREAT.IMG.REPLACE: Payload Replacement . . . . . . . 19
4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 18 4.2.9. THREAT.IMG.NON_AUTH: Unauthenticated Images . . . . . 19
4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor 4.2.10. THREAT.UPD.WRONG_PRECURSOR: Unexpected Precursor
images . . . . . . . . . . . . . . . . . . . . . . . 18 images . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.11. THREAT.UPD.INTEROP: Unqualified Firmware . . . . . . 19 4.2.11. THREAT.UPD.UNAPPROVED: Unapproved Firmware . . . . . 20
4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of 4.2.12. THREAT.IMG.DISCLOSURE: Reverse Engineering Of
Firmware Image for Vulnerability Analysis . . . . . . 20 Firmware Image for Vulnerability Analysis . . . . . . 21
4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest
Elements . . . . . . . . . . . . . . . . . . . . . . 20 Elements . . . . . . . . . . . . . . . . . . . . . . 22
4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element
Exposure . . . . . . . . . . . . . . . . . . . . . . 21 Exposure . . . . . . . . . . . . . . . . . . . . . . 22
4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 21 4.2.15. THREAT.IMG.EXTRA: Extra data after image . . . . . . 22
4.3. Security Requirements . . . . . . . . . . . . . . . . . . 21 4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys . . . . 22
4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 21 4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or
4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 22 payload prior to signing . . . . . . . . . . . . . . 23
4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 22 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 23
4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 22 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers . . . . 23
4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 22 4.3.2. REQ.SEC.COMPATIBLE: Vendor, Device-type Identifiers . 24
4.3.3. REQ.SEC.EXP: Expiration Time . . . . . . . . . . . . 24
4.3.4. REQ.SEC.AUTHENTIC: Cryptographic Authenticity . . . . 24
4.3.5. REQ.SEC.AUTH.IMG_TYPE: Authenticated Payload Type . . 25
4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC: 4.3.6. Security Requirement REQ.SEC.AUTH.IMG_LOC:
Authenticated Storage Location . . . . . . . . . . . 23 Authenticated Storage Location . . . . . . . . . . . 25
4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote 4.3.7. REQ.SEC.AUTH.REMOTE_LOC: Authenticated Remote
Resource Location . . . . . . . . . . . . . . . . . . 23 Resource Location . . . . . . . . . . . . . . . . . . 25
4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 23 4.3.8. REQ.SEC.AUTH.EXEC: Secure Execution . . . . . . . . . 25
4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor 4.3.9. REQ.SEC.AUTH.PRECURSOR: Authenticated precursor
images . . . . . . . . . . . . . . . . . . . . . . . 23 images . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and 4.3.10. REQ.SEC.AUTH.COMPATIBILITY: Authenticated Vendor and
Class IDs . . . . . . . . . . . . . . . . . . . . . . 23 Class IDs . . . . . . . . . . . . . . . . . . . . . . 26
4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 24 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity . . . . . 26
4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 24 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption . . . 26
4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 24 4.3.13. REQ.SEC.ACCESS_CONTROL: Access Control . . . . . . . 27
4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 25 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests . . 27
4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 25 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest . . . 27
4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 25 4.3.16. REQ.SEC.REPORTING: Secure Reporting . . . . . . . . . 28
4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing
keys . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to
deployment . . . . . . . . . . . . . . . . . . . . . 28
4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a
trusted environment . . . . . . . . . . . . . . . . . 28
4.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 29
4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation 4.4.1. USER_STORY.INSTALL.INSTRUCTIONS: Installation
Instructions . . . . . . . . . . . . . . . . . . . . 25 Instructions . . . . . . . . . . . . . . . . . . . . 29
4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 26 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early . . . . . . . 29
4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest
Elements . . . . . . . . . . . . . . . . . . . . . . 26 Elements . . . . . . . . . . . . . . . . . . . . . . 29
4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 27 4.4.4. USER_STORY.COMPONENT: Component Update . . . . . . . 30
4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations . . . 27 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations . . . 30
4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 27 4.4.6. USER_STORY.IMG.FORMAT: Multiple Payload Formats . . . 30
4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential 4.4.7. USER_STORY.IMG.CONFIDENTIALITY: Prevent Confidential
Information Disclosures . . . . . . . . . . . . . . . 27 Information Disclosures . . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . 27 Unpacking Unknown Formats . . . . . . . . . . . . . . 31
4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version 4.4.9. USER_STORY.IMG.CURRENT_VERSION: Specify Version
Numbers of Target Firmware . . . . . . . . . . . . . 28 Numbers of Target Firmware . . . . . . . . . . . . . 31
4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose 4.4.10. USER_STORY.IMG.SELECT: Enable Devices to Choose
Between Images . . . . . . . . . . . . . . . . . . . 28 Between Images . . . . . . . . . . . . . . . . . . . 31
4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using 4.4.11. USER_STORY.EXEC.MFST: Secure Execution Using
Manifests . . . . . . . . . . . . . . . . . . . . . . 28 Manifests . . . . . . . . . . . . . . . . . . . . . . 31
4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 28 4.4.12. USER_STORY.EXEC.DECOMPRESS: Decompress on Load . . . 32
4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 28 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest . . . . . . 32
4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 29 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing . . . . . . . . 32
4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in
Manifest . . . . . . . . . . . . . . . . . . . . . . 29 Manifest . . . . . . . . . . . . . . . . . . . . . . 32
4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 29 4.4.16. USER_STORY.MFST.PRE_CHECK: Update Evaluation . . . . 32
4.5. Usability Requirements . . . . . . . . . . . . . . . . . 29 4.5. Usability Requirements . . . . . . . . . . . . . . . . . 32
4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 29 4.5.1. REQ.USE.MFST.PRE_CHECK: Pre-Installation Checks . . . 33
4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE: Override Remote
Resource Location . . . . . . . . . . . . . . . . . . 30 Resource Location . . . . . . . . . . . . . . . . . . 33
4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 30
4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 31 4.5.3. REQ.USE.MFST.COMPONENT: Component Updates . . . . . . 33
4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 31 4.5.4. REQ.USE.MFST.MULTI_AUTH: Multiple authentications . . 34
4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 32 4.5.5. REQ.USE.IMG.FORMAT: Format Usability . . . . . . . . 34
4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 32 4.5.6. REQ.USE.IMG.NESTED: Nested Formats . . . . . . . . . 35
4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 32 4.5.7. REQ.USE.IMG.VERSIONS: Target Version Matching . . . . 35
4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 32 4.5.8. REQ.USE.IMG.SELECT: Select Image by Destination . . . 35
4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 33 4.5.9. REQ.USE.EXEC: Executable Manifest . . . . . . . . . . 36
4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 33 4.5.10. REQ.USE.LOAD: Load-Time Information . . . . . . . . . 36
4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 33 4.5.11. REQ.USE.PAYLOAD: Payload in Manifest Superstructure . 36
4.5.12. REQ.USE.PARSE: Simple Parsing . . . . . . . . . . . . 36
4.5.13. REQ.USE.DELEGATION: Delegation of Authority in 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in
Manifest . . . . . . . . . . . . . . . . . . . . . . 33 Manifest . . . . . . . . . . . . . . . . . . . . . . 37
5. Security Considerations . . . . . . . . . . . . . . . . . . . 34 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1. Normative References . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . 34 7.2. Informative References . . . . . . . . . . . . . . . . . 38
8.2. Informative References . . . . . . . . . . . . . . . . . 35 Appendix A. Mailing List Information . . . . . . . . . . . . . . 39
Appendix A. Mailing List Information . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The information model describes all the information elements required The information model describes all the information elements required
to secure firmware updates of IoT devices from the threats described to secure firmware updates of IoT devices from the threats described
in Section 4.1 and enables the user stories captured in Section 4.4. in Section 4.1 and enables the user stories captured in Section 4.4.
These threats and user stories are not intended to be an exhaustive These threats and user stories are not intended to be an exhaustive
list of the threats against IoT devices, nor of the possible user list of the threats against IoT devices, nor of the possible user
stories that describe how to conduct a firmware update. Instead they stories that describe how to conduct a firmware update. Instead they
are intended to describe the threats against firmware updates in are intended to describe the threats against firmware updates in
skipping to change at page 5, line 48 skipping to change at page 6, line 11
provide important security or usability properties that are needed on provide important security or usability properties that are needed on
most devices. Elements marked as optional enable security or most devices. Elements marked as optional enable security or
usability properties that are useful in some applications. usability properties that are useful in some applications.
The definition of some of the information elements include examples The definition of some of the information elements include examples
that illustrate their semantics and how they are intended to be used. that illustrate their semantics and how they are intended to be used.
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.
This document treats devices with a homogeneous storage architecture This document treats devices with a homogeneous storage architecture
as devices with a heterogeneous storage architecture, but with a as devices with a heterogeneous storage architecture, but with a
single storage subsystem. single storage subsystem.
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
skipping to change at page 6, line 48 skipping to change at page 7, line 7
choosing one out of several manifests can choose which is the latest. choosing one out of several manifests can choose which is the latest.
This element is MANDATORY and is necessary to prevent malicious This element is MANDATORY and is necessary to prevent malicious
actors from reverting a firmware update against the policies of the actors from reverting a firmware update against the policies of the
relevant authority. 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. Manifest Element: 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 UUID DNS prefix. Other options include type 1 and type 4 UUIDs. the DNS name space ID. Other options include type 1 and type 4
UUIDs.
Vendor ID is not intended to be a human-readable element. It is Vendor ID is not intended to be a human-readable element. It is
intended for 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 their domain name:
vendorId = UUID5(DNS, "vendor-a.com") 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 guaranteed to be unique. Because the same domain name, this UUID is (with very high probability)
domain name is known, this UUID is reproducible. Type 1 and type 4 guaranteed to be unique. Because the domain name is known, this UUID
UUIDs produce similar guarantees of uniqueness, but not is reproducible. Type 1 and type 4 UUIDs produce similar guarantees
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. Manifest Element: 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
skipping to change at page 8, line 4 skipping to change at page 8, line 14
o model name or number o model name or number
o hardware revision o hardware revision
o runtime library version o runtime library version
o bootloader version o bootloader version
o ROM revision o ROM revision
o silicon batch number o silicon batch number
The Class Identifier UUID SHOULD use the Vendor ID as the UUID The Class Identifier UUID SHOULD use the Vendor ID as the name space
prefix. 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 granular than is required to identify firmware compatibility.
Classes MUST NOT be less granular than is required to identify Classes MUST NOT be less granular than is required to identify
firmware compatibility. Devices MAY have multiple Class IDs. 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 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 Root of Trust for authorisation. use a unique trust anchor for authorisation.
Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2), Implements: Security Requirement REQ.SEC.COMPATIBLE (Section 4.3.2),
REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10). REQ.SEC.AUTH.COMPATIBILITY (Section 4.3.10).
3.4.1. Example 1: Different Classes 3.4.1. Example 1: Different Classes
Vendor A creates product Z and product Y. The firmware images of Vendor A creates product Z and product Y. The firmware images of
products Z and Y are not interchangeable. Vendor A creates UUIDs as products Z and Y are not interchangeable. Vendor A creates UUIDs as
follows: follows:
skipping to change at page 10, line 27 skipping to change at page 10, line 39
with a secure source of time. with a secure source of time.
This element is OPTIONAL and MAY enable user stories where a secure This element is OPTIONAL and MAY enable user stories where a secure
source of time is provided and firmware is intended to expire source of time is provided and firmware is intended to expire
predictably. predictably.
Implements: REQ.SEC.EXP (Section 4.3.3) Implements: REQ.SEC.EXP (Section 4.3.3)
3.8. Manifest Element: Payload Format 3.8. Manifest Element: Payload Format
The format of the payload MUST be indicated to devices is 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 MANDATORY and MUST be present to enable devices to This element is MANDATORY and MUST be present to enable devices to
decode payloads correctly. 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. Manifest Element: Processing Steps
skipping to change at page 11, line 20 skipping to change at page 11, line 37
This element is MANDATORY and MUST be present to enable devices to This element is MANDATORY and MUST be present to enable devices to
store payloads to the correct location. 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 firmware authority ensure compatibility between the components. The Author chooses two
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 firmware authority chooses A device supports a full filesystem. The Author chooses to use the
to use the storage identifier as the path at which to install the storage identifier as the path at which to install the payload. The
payload. The payload may be a tarball, in which case, it unpacks the payload may be a tarball, in which case, it unpacks the tarball into
tarball into the specified path. the specified path.
3.10.3. Example 3: Flash Memory 3.10.3. Example 3: Flash Memory
A device supports flash memory. The firmware authority chooses to A device supports flash memory. The Author chooses to make the
make the storage identifier the offset where the image should be storage identifier the offset where the image should be written.
written.
3.11. Manifest Element: Component Identifier 3.11. Manifest Element: Component Identifier
In a heterogeneous storage architecture, a storage identifier is In a heterogeneous storage architecture, a storage identifier is
insufficient to identify where and how to store a payload. To insufficient to identify where and how to store a payload. To
resolve this, a component identifier indicates which part of the resolve this, a component identifier indicates which part of the
storage architecture is targeted by the payload. In a homogeneous storage architecture is targeted by the payload. In a homogeneous
storage architecture, this element is unnecessary. storage architecture, this element is unnecessary.
This element is OPTIONAL and only necessary in heterogeneous storage This element is OPTIONAL and only necessary in heterogeneous storage
skipping to change at page 12, line 4 skipping to change at page 12, line 23
insufficient to identify where and how to store a payload. To insufficient to identify where and how to store a payload. To
resolve this, a component identifier indicates which part of the resolve this, a component identifier indicates which part of the
storage architecture is targeted by the payload. In a homogeneous storage architecture is targeted by the payload. In a homogeneous
storage architecture, this element is unnecessary. storage architecture, this element is unnecessary.
This element is OPTIONAL and only necessary in heterogeneous storage This element is OPTIONAL and only necessary in heterogeneous storage
architecture devices. architecture devices.
N.B. A serialisation MAY choose to combine Component Identifier and N.B. A serialisation 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. Manifest Element: Resource 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 resource. 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 or 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 and only needed when the target device does
not intrinsically know where to find the payload. 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. Manifest Element: 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 serialisation MUST provide a mechanism to select one payload(s). A serialisation MUST provide a mechanism to select one
payload from a list based on system parameters, such as XIP address. payload from a list based on system parameters, such as Execute-In-
Place Installation Address.
This element is MANDATORY to implement and fundamentally necessary to This element is MANDATORY to implement and fundamentally necessary to
ensure the authenticity and integrity of the payload. Support for ensure the authenticity and integrity of the payload. Support for
more than one digest is OPTIONAL to implement in a recipient device. more than 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. Manifest Element: Size
skipping to change at page 13, line 28 skipping to change at page 13, line 48
URIs). URIs).
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. Manifest Element: Additional installation instructions
Instructions that the device should execute when processing the Instructions that the device should execute when processing the
manifest. This information is distinct from the information manifest. This information is distinct from the information
necessary to process a payload. Additional installation instructions necessary to process a payload. Additional installation instructions
include information such as update timing (For example, install only include information such as update timing (for example, install only
on Sunday, at 0200), procedural considerations (for example, shut on Sunday, at 0200), procedural considerations (for example, shut
down the equipment under control before executing the update), pre down the equipment under control before executing the update), pre-
and post-installation steps (for example, run a script). and post-installation steps (for example, run a script).
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. Manifest Element: Aliases 3.17. Manifest Element: 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 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. Manifest Element: 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 an unambiguous way, such as a digest. Manifests are identified an unambiguous way, such as a digest.
This element is MANDATORY to use in deployments that include both This element is MANDATORY 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. Manifest Element: 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
skipping to change at page 14, line 48 skipping to change at page 15, line 20
active use location of that image. The metadata contains the source active use location of that image. The metadata contains the source
and destination of the image as well as any operations that are and destination of the image as well as any operations that are
performed on the image. performed on the image.
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. Manifest Element: 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.
Implements: REQ.USE.EXEC (Section 4.5.9) Implements: REQ.USE.EXEC (Section 4.5.9)
3.23. Manifest Element: Payload 3.23. Manifest Element: Payload
The Payload element provides a recipient device with the whole The Payload element provides a recipient device with the whole
payload, contained within the manifest superstructure. This enables payload, contained within the manifest superstructure. This enables
the manifest and payload to be delivered simultaneously. the manifest and payload to be delivered simultaneously.
skipping to change at page 15, line 22 skipping to change at page 15, line 42
3.24. Manifest Element: Key Claims 3.24. Manifest Element: Key Claims
The Key Claims element is not authenticated by the Signature The Key Claims element is not authenticated by the Signature
(Section 3.15), instead, it provides a chain of key delegations (or (Section 3.15), instead, it provides a chain of key delegations (or
references to them) for the device to follow in order to verify the references to them) for the device to follow in order to verify the
key that authenticated the manifest using a trusted key. key that authenticated the manifest using a trusted key.
Implements: REQ.USE.DELEGATION (Section 4.5.13) Implements: REQ.USE.DELEGATION (Section 4.5.13)
4. Motivation for Manifest Fields 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. security requirements, and usability requirements. This section also
provides the motivations for each of the manifest information
elements.
4.1. Threat Model 4.1. Threat Model
The following sub-sections aim to provide information about the The following sub-sections aim to provide information about the
threats that were considered, the security requirements that are threats that were considered, the security requirements that are
derived from those threats and the fields that permit implementation derived from those threats and the fields that permit implementation
of the security requirements. This model uses the S.T.R.I.D.E. of the security requirements. This model uses the S.T.R.I.D.E.
[STRIDE] approach. Each threat is classified according to: [STRIDE] approach. Each threat is classified according to:
o Spoofing Identity o Spoofing identity
o Tampering with data o Tampering with data
o Repudiation o Repudiation
o Information disclosure o Information disclosure
o Denial of service o Denial of service
o Elevation of privilege o Elevation of privilege
skipping to change at page 17, line 16 skipping to change at page 17, line 41
4.2.3.1. Example: 4.2.3.1. Example:
Suppose that two vendors, Vendor A and Vendor B, adopt the same trade Suppose that two vendors, Vendor A and Vendor B, adopt the same trade
name in different geographic regions, and they both make products name in different geographic regions, and they both make products
with the same names, or product name matching is not used. This with the same names, or product name matching is not used. This
causes firmware from Vendor A to match devices from Vendor B. causes firmware from Vendor A to match devices from Vendor B.
If the vendors are the firmware authorities, then devices from Vendor If the vendors are the firmware authorities, then devices from Vendor
A will reject images signed by Vendor B since they use different A will reject images signed by Vendor B since they use different
credentials. However, if both devices trust the same firmware credentials. However, if both devices trust the same Author, then,
authority, then, devices from Vendor A could install firmware devices from Vendor A could install firmware intended for devices
intended for devices from Vendor B. from Vendor B.
4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of 4.2.4. THREAT.IMG.FORMAT: The target device misinterprets the type of
payload payload
Classification: Denial of Service Classification: Denial of Service
If a device misinterprets the format of the firmware image, it may If a device misinterprets the format of the firmware image, it may
cause a device to install a firmware image incorrectly. An cause a device to install a firmware image incorrectly. An
incorrectly installed firmware image would likely cause the device to incorrectly installed firmware image would likely cause the device to
stop functioning. stop functioning.
skipping to change at page 18, line 15 skipping to change at page 18, line 39
4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting 4.2.6. THREAT.NET.REDIRECT: Redirection to inauthentic payload hosting
Classification: Denial of Service Classification: Denial of Service
If a device does not know where to obtain the payload for an update, If a device does not know where to obtain the payload for an update,
it may be redirected to an attacker's server. This would allow an it may be redirected to an attacker's server. This would allow an
attacker to provide broken payloads to devices. attacker to provide broken payloads to devices.
Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7) Mitigated by: REQ.SEC.AUTH.REMOTE_LOC (Section 4.3.7)
4.2.7. THREAT.NET.MITM 4.2.7. THREAT.NET.MITM: Traffic interception
Classification: Spoofing Identity, Tampering with Data
An attacker intercepts all traffic to and from a device. The
attacker can monitor or modify any data sent to or received from the
device. This can take the form of: manifests, payloads, status
reports, and capability reports being modified or not delivered to
the intended recipient. It can also take the form of analysis of
data sent to or from the device, either in content, size, or
frequency.
Mitigated by: REQ.SEC.AUTHENTIC (Section 4.3.4),
REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12), REQ.SEC.AUTH.REMOTE_LOC
(Section 4.3.7), REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14),
REQ.SEC.REPORTING (Section 4.3.16)
4.2.8. THREAT.IMG.REPLACE: Payload Replacement 4.2.8. THREAT.IMG.REPLACE: Payload Replacement
Classification: Elevation of Privilege Classification: Elevation of Privilege
An attacker replaces a newly downloaded firmware after a device An attacker replaces a newly downloaded firmware after a device
finishes verifying a manifest. This could cause the device to finishes verifying a manifest. This could cause the device to
execute the attacker's code. This attack likely requires physical execute the attacker's code. This attack likely requires physical
access to the device. However, it is possible that this attack is access to the device. However, it is possible that this attack is
carried out in combination with another threat that allows remote carried out in combination with another threat that allows remote
skipping to change at page 19, line 13 skipping to change at page 20, line 5
available on the target device, it could cause the update to break. available on the target device, it could cause the update to break.
An attacker that can cause a device to install a payload against the An attacker that can cause a device to install a payload against the
wrong precursor image could gain elevation of privilege and wrong precursor image could gain elevation of privilege and
potentially expand this to all types of threat. However, it is potentially expand this to all types of threat. However, it is
unlikely that a valid differential update applied to an incorrect unlikely that a valid differential update applied to an incorrect
precursor would result in a functional, but vulnerable firmware. precursor would result in a functional, but vulnerable firmware.
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.INTEROP: Unqualified 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 interoperability of devices with other systems. The owner or about ensuring that devices retain the behaviour required by their
operator of a network needs to approve firmware for their network in Owner, Device Operator, or Network Operator. The owner or operator
order to ensure interoperability with other devices on the network, of a device typically requires that the device maintain certain
or the network itself. If the firmware is not qualified, it may not features, functions, capabilities, behaviours, or interoperability
work. Therefore, if a device installs firmware without the approval constraints (more generally, behaviour). If these requirements are
of the network owner or operator, this is a threat to devices and the broken, then a device will not fulfill its purpose. Therefore, if
network. any party other than the device's Owner or the Owner's contracted
Device Operator has the ability to modify device behaviour without
approval, then this constitutes an elevation of privilege.
Similarly, a network operator may require that devices behave in a
particular way in order to maintain the integrity of the network. If
devices behaviour on a network can be modified without the approval
of the network operator, then this constitutes an elevation of
privilege with respect to the network.
For example, if the owner of a device has purchased that device
because of Features A, B, and C, and a firmware update is issued by
the manufacturer, which removes Feature A, then the device may not
fulfill the owner's requirements any more. In certain circumstances,
this can cause significantly greater threats. Suppose that Feature A
is used to implement a safety-critical system, whether the
manufacturer intended this behaviour or not. When unapproved
firmware is installed, the system may become unsafe.
In a second example, the owner or operator of a system of two or more
interoperating devices needs to approve firmware for their system in
order to ensure interoperability with other devices in the system.
If the firmware is not qualified, the system as a whole may not work.
Therefore, if a device installs firmware without the approval of the
device owner or operator, this is a threat to devices or the system
as a whole.
Similarly, the operator of a network may need to approve firmware for
devices attached to the network in order to ensure favourable
operating conditions within the network. If the firmware is not
qualified, it may degrade the performance of the network. Therefore,
if a device installs firmware without the approval of the network
operator, this is a threat to the network itself.
Threat Escalation: If the 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 20, line 39 skipping to change at page 22, line 13
the attack he or she retrieves the provided firmware image and the attack he or she retrieves the provided firmware image and
performs reverse engineering of the firmware image to analyze it for performs reverse engineering of the firmware image to analyze it for
specific vulnerabilities. specific vulnerabilities.
Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12) Mitigated by: REQ.SEC.IMG.CONFIDENTIALITY (Section 4.3.12)
4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements 4.2.13. THREAT.MFST.OVERRIDE: Overriding Critical Manifest Elements
Classification: Elevation of Privilege Classification: Elevation of Privilege
An authorised actor, but not the firmware authority, uses an override An authorised actor, but not the Author, uses an override mechanism
mechanism (USER_STORY.OVERRIDE (Section 4.4.3)) to change an (USER_STORY.OVERRIDE (Section 4.4.3)) to change an information
information element in a manifest signed by the firmware authority. element in a manifest signed by the Author. For example, if the
For example, if the authorised actor overrides the digest and URI of authorised actor overrides the digest and URI of the payload, the
the payload, the actor can replace the entire payload with a payload actor can replace the entire payload with a payload of their choice.
of their choice.
Threat Escalation: By overriding elements such as payload Threat Escalation: By overriding elements such as payload
installation instructions or firmware digest, this threat can be installation instructions or firmware digest, this threat can be
escalated to all types. escalated to all types.
Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13) Mitigated by: REQ.SEC.ACCESS_CONTROL (Section 4.3.13)
4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure 4.2.14. THREAT.MFST.EXPOSURE: Confidential Manifest Element Exposure
Classification: Information Disclosure Classification: Information Disclosure
skipping to change at page 21, line 20 skipping to change at page 22, line 40
manifest. manifest.
Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14) Mitigated by: REQ.SEC.MFST.CONFIDENTIALITY (Section 4.3.14)
4.2.15. THREAT.IMG.EXTRA: Extra data after image 4.2.15. THREAT.IMG.EXTRA: Extra data after image
Classification: All Types Classification: All Types
If a third party modifies the image so that it contains extra code If a third party modifies the image so that it contains extra code
after a valid, authentic image, that third party can then use their after a valid, authentic image, that third party can then use their
own code in order to make better use of an existing vulnerability own code in order to make better use of an existing vulnerability.
Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15) Mitigated by: REQ.SEC.IMG.COMPLETE_DIGEST (Section 4.3.15)
4.2.16. THREAT.KEY.EXPOSURE: Exposure of signing keys
Classification: All Types
If a third party obtains a key or even indirect access to a key, for
example in an HSM, then they can perform the same actions as the
legitimate owner of the key. If the key is trusted for firmware
update, then the third party can perform firmware updates as though
they were the legitimate owner of the key.
For example, if manifest signing is performed on a server connected
to the internet, an attacker may compromise the server and then be
able to sign manifests, even if the keys for manifest signing are
held in an HSM that is accessed by the server.
Mitigated by: REQ.SEC.KEY.PROTECTION (Section 4.3.17)
4.2.17. THREAT.MFST.MODIFICATION: Modification of manifest or payload
prior to signing
Classification: All Types
If an attacker can alter a manifest or payload before it is signed,
they can perform all the same actions as the manifest author. This
allows the attacker to deploy firmware updates to any devices that
trust the manifest author. If an attacker can modify the code of a
payload before the corresponding manifest is created, they can insert
their own code. If an attacker can modify the manifest before it is
signed, they can redirect the manifest to their own payload.
For example, the attacker deploys malware to the developer's computer
or signing service that watches manifest creation activities and
inserts code into any binary that is referenced by a manifest.
For example, the attacker deploys malware to the developer's computer
or signing service that replaces the referenced binary (digest) and
URI with the attacker's binary (digest) and URI.
Mitigated by: REQ.SEC.MFST.CHECK (Section 4.3.18),
REQ.SEC.MFST.TRUSTED (Section 4.3.19)
4.3. Security Requirements 4.3. Security Requirements
The security requirements here are a set of policies that mitigate The security requirements here are a set of policies that mitigate
the threats described in Section 4.1. the threats described in Section 4.1.
4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers 4.3.1. REQ.SEC.SEQUENCE: Monotonic Sequence Numbers
Only an actor with firmware installation authority is permitted to Only an actor with firmware installation authority is permitted to
decide when device firmware can be installed. To enforce this rule, decide when device firmware can be installed. To enforce this rule,
manifests MUST contain monotonically increasing sequence numbers. manifests MUST contain monotonically increasing sequence numbers.
skipping to change at page 22, line 38 skipping to change at page 24, line 48
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 authenticated. Because the
manifest contains information about how to install the update, the manifest contains information about how to install the update, the
manifest's authenticity MUST also be demonstrable. To reduce the manifest's authenticity MUST also be demonstrable. To reduce the
overhead required for validation, the manifest contains the digest of overhead required for validation, the manifest contains the digest of
the firmware image, rather than a second digital signature. The the firmware image, rather than a second digital signature. The
authenticity of the manifest can be verified with a digital signature authenticity of the manifest can be verified with a digital signature
or Message Authentication Code, the authenticity of the firmware or Message Authentication Code. The authenticity of the firmware
image is tied to the manifest by the use of a digest of the firmware image is tied to the manifest by the use of a digest of the firmware
image. image.
Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9) Mitigates: THREAT.IMG.NON_AUTH (Section 4.2.9), THREAT.NET.MITM
(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 serialized configuration data. is XIP firmware, a loadable module, or serialized configuration data.
skipping to change at page 23, line 25 skipping to change at page 25, line 37
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 Resource Location
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) Mitigates: THREAT.NET.REDIRECT (Section 4.2.6), THREAT.NET.MITM
(Section 4.2.7)
Implemented by: Resource Indicator (Section 3.12) Implemented by: Resource 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)
skipping to change at page 24, line 15 skipping to change at page 26, line 31
Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3) Mitigates: THREAT.IMG.INCOMPATIBLE (Section 4.2.3)
Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition Implemented By: Vendor ID Condition (Section 3.3), Class ID Condition
(Section 3.4) (Section 3.4)
4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity 4.3.11. REQ.SEC.RIGHTS: Rights Require Authenticity
If a device grants different rights to different actors, exercising If a device grants different rights to different actors, exercising
those rights MUST be accompanied by proof of those rights, in the those rights MUST be accompanied by proof of those rights, in the
form of proof of authenticity. Authenticity mechanisms such as those form of proof of authenticity. Authenticity mechanisms such as those
required in REQ.SEC.AUTHENTIC (Section 4.3.4) are acceptable but need required in REQ.SEC.AUTHENTIC (Section 4.3.4) can be used to prove
to follow the end-to-end security model. authenticity.
For example, if a device has a policy that requires that firmware For example, if a device has a policy that requires that firmware
have both an Authorship right and a Qualification right and if that have both an Authorship right and a Qualification right and if that
device grants Authorship and Qualification rights to different device grants Authorship and Qualification rights to different
parties, such as a Device Operator and a Network Operator, parties, such as a Device Operator and a Network Operator,
respectively, then the firmware cannot be installed without proof of respectively, then the firmware cannot be installed without proof of
rights from both the Device and the Network Operator. rights from both the Device Operator and the Network Operator.
Mitigates: THREAT.UPD.INTEROP (Section 4.2.11) Mitigates: THREAT.UPD.UNAPPROVED (Section 4.2.11)
Implemented by: Signature (Section 3.15) Implemented by: Signature (Section 3.15)
4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption 4.3.12. REQ.SEC.IMG.CONFIDENTIALITY: Payload Encryption
The manifest information model MUST enable encrypted payloads. The manifest information model MUST enable encrypted payloads.
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) Mitigates: THREAT.IMG.DISCLOSURE (Section 4.2.12), THREAT.NET.MITM
(Section 4.2.7)
Implemented by: Encryption Wrapper (Section 3.19) Implemented by: Encryption Wrapper (Section 3.19)
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.
2. An ACL decides which component identifier/storage identifier 2. An ACL decides which component identifier/storage identifier
pairs can be written by which actors. pairs can be written by which actors.
Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13), THREAT.UPD.INTEROP Mitigates: THREAT.MFST.OVERRIDE (Section 4.2.13),
(Section 4.2.11) THREAT.UPD.UNAPPROVED (Section 4.2.11)
Implemented by: Client-side code, not specified in manifest. Implemented by: Client-side code, not specified in manifest.
4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests 4.3.14. REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests
It MUST be possible to encrypt part or all of the manifest. This may It MUST be possible to encrypt part or all of the manifest. This may
be accomplished with either transport encryption or with at-rest be accomplished with either transport encryption or with at-rest
encryption. encryption.
Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14) Mitigates: THREAT.MFST.EXPOSURE (Section 4.2.14), THREAT.NET.MITM
(Section 4.2.7)
Implemented by: External Encryption Wrapper / Transport Security Implemented by: External Encryption Wrapper / Transport Security
4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest 4.3.15. REQ.SEC.IMG.COMPLETE_DIGEST: Whole Image Digest
The digest SHOULD cover all available space in a fixed-size storage The digest SHOULD cover all available space in a fixed-size storage
location. Variable-size storage locations MUST be restricted to location. Variable-size storage locations MUST be restricted to
exactly the size of deployed payload. This prevents any data from exactly the size of deployed payload. This prevents any data from
being distributed without being covered by the digest. For example, being distributed without being covered by the digest. For example,
XIP microcontrollers typically have fixed-size storage. These XIP microcontrollers typically have fixed-size storage. These
devices should deploy a digest that covers the deployed firmware devices should deploy a digest that covers the deployed firmware
image, concatenated with the default erased value of any remaining image, concatenated with the default erased value of any remaining
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
Status reports from the device to any remote system SHOULD be
performed over an authenticated, confidential channel in order to
prevent modification or spoofing of the reports.
Mitigates: THREAT.NET.MITM (Section 4.2.7)
4.3.17. REQ.SEC.KEY.PROTECTION: Protected storage of signing keys
Cryptographic keys for signing manifests SHOULD be stored in a manner
that is inaccessible to networked devices, for example in an HSM, or
an air-gapped computer. This protects against an attacker obtaining
the keys.
Keys SHOULD be stored in a way that limits the risk of a legitimate,
but compromised, entity (such as a server or developer computer)
issuing signing requests.
Mitigates: THREAT.KEY.EXPOSURE (Section 4.2.16)
4.3.18. REQ.SEC.MFST.CHECK: Validate manifests prior to deployment
Manifests SHOULD be parsed and examined prior to deployment to
validate that their contents have not been modified during creation
and signing.
Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17)
4.3.19. REQ.SEC.MFST.TRUSTED: Construct manifests in a trusted
environment
For high risk deployments, such as large numbers of devices or
critical function devices, manifests SHOULD be constructed in an
environment that is protected from interference, such as an air-
gapped computer. Note that a networked computer connected to an HSM
does not fulfill this requirement (see THREAT.MFST.MODIFICATION
(Section 4.2.17)).
Mitigates: THREAT.MFST.MODIFICATION (Section 4.2.17)
4.4. User Stories 4.4. User Stories
User stories provide expected use cases. These are used to feed into User stories provide expected use cases. These are used to feed into
usability requirements. usability requirements.
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.
skipping to change at page 26, line 26 skipping to change at page 29, line 42
4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early 4.4.2. USER_STORY.MFST.FAIL_EARLY: Fail Early
As a designer of a resource-constrained IoT device, I want bad As a designer of a resource-constrained IoT device, I want bad
updates to fail as early as possible to preserve battery life and updates to fail as early as possible to preserve battery life and
limit consumed bandwidth. limit consumed 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.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements 4.4.3. USER_STORY.OVERRIDE: Override Non-Critical Manifest Elements
As a Network Operator, I would like to be able to override the non- As a Device Operator, I would like to be able to override the non-
critical information in the manifest so that I can control my devices critical information in the manifest so that I can control my devices
more precisely. The authority to override this information is more precisely. The authority to override this information is
provided via the installation of a limited trust relationship by provided via the installation of a limited trust anchor by another
another authority. authority.
Some examples of potentially overridable information: Some examples of potentially overridable information:
o URIs (Section 3.12): this allows the Network Operator to direct o URIs (Section 3.12): this allows the Device Operator to direct
devices to their own infrastructure in order to reduce network devices to their own infrastructure in order to reduce network
load. load.
o Conditions: this allows the Network Operator to pose additional o Conditions: this allows the Device Operator to pose additional
constraints on the installation of the manifest. constraints on the installation of the manifest.
o Directives (Section 3.16): this allows the Network 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: USER_STORY.OVERRIDE (Section 4.4.3),
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 an Operator, I want to divide my firmware into components, so that As a Device Operator, I want to divide my firmware into components,
I can reduce the size of updates, make different parties responsible so that I can reduce the size of updates, make different parties
for different components, and divide my firmware into frequently responsible for different components, and divide my firmware into
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)
4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations 4.4.5. USER_STORY.MULTI_AUTH: Multiple Authorisations
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.4),
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 an Operator, I want to be able to send multiple payload formats to As a Device Operator, I want to be able to send multiple payload
suit the needs of my update, so that I can optimise the bandwidth formats to suit the needs of my update, so that I can optimise the
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 an firmware author, I want to prevent confidential information As a firmware author, I want to prevent confidential information from
from being disclosed during firmware updates. It is assumed that being disclosed during firmware updates. It is assumed that channel
channel security or at-rest encryption is adequate to protect the security or at-rest encryption is adequate to protect the manifest
manifest itself against information disclosure. itself against information disclosure.
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
skipping to change at page 28, line 49 skipping to change at page 32, line 16
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.10)
4.4.13. USER_STORY.MFST.IMG: Payload in Manifest 4.4.13. USER_STORY.MFST.IMG: Payload in Manifest
As an operator of a constrained network, I would like to be able to As an operator of devices on a constrained network, I would like the
send a small payload in the same packet as the manifest so that I can manifest to be able to include a small payload in the same packet so
reduce network traffic. that I can reduce network traffic.
Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11) Satisfied by: REQ.USE.PAYLOAD (Section 4.5.11)
4.4.14. USER_STORY.MFST.PARSE: Simple Parsing 4.4.14. USER_STORY.MFST.PARSE: Simple Parsing
As a developer for constrained devices, I want a low complexity As a developer for constrained devices, I want a low complexity
library for processing updates so that I can fit more application library for processing updates so that I can fit more application
code on my device. code on my device.
Satisfied by: REQ.USE.PARSE (Section 4.5.12) Satisfied by: REQ.USE.PARSE (Section 4.5.12)
4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest 4.4.15. USER_STORY.MFST.DELEGATION: Delegated Authority in Manifest
As an 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.13)
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
skipping to change at page 33, line 45 skipping to change at page 37, line 8
The structure of the manifest MUST be simple to parse, without need The structure of the manifest MUST be simple to parse, without need
for a general-purpose parser. for a general-purpose parser.
Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14) Satisfies: USER_STORY.MFST.PARSE (Section 4.4.14)
Implemented by: N/A Implemented by: N/A
4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest 4.5.13. REQ.USE.DELEGATION: Delegation of Authority in Manifest
Any serialisation MUST enable the delivery of a key claim with, but Any serialisation MUST enable the delivery of a key claim with, but
not authenticated by a manifest. This key claim delivers a new key not authenticated by, a manifest. This key claim delivers a new key
with which the recipient can verify the manifest. with which the recipient can verify the manifest.
Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15) Satisfies: USER_STORY.MFST.DELEGATION (Section 4.4.15)
Implemented by: Key Claims (Section 3.24) Implemented by: Key Claims (Section 3.24)
5. Security Considerations 5. IANA Considerations
Security considerations for this document are covered in Section 4.
6. IANA Considerations
This document does not require any actions by IANA. This document does not require any actions by IANA.
7. 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.
We would like to thank the participants of the 2018 Berlin SUIT We would like to thank the participants of the 2018 Berlin SUIT
Hackathon and the June 2018 virtual design team meetings for their Hackathon and the June 2018 virtual design team meetings for their
discussion input. In particular, we would like to thank Koen discussion input. In particular, we would like to thank Koen
Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus
Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson,
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, Gary Milosch Meriac, Jean-Luc Giraud, Dan Ros, Amyas Philips, and Gary
Thomson. Thomson.
8. References 7. References
8.1. Normative References 7.1. Normative References
[I-D.ietf-suit-architecture] [I-D.ietf-suit-architecture]
Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A
Firmware Update Architecture for Internet of Things Firmware Update Architecture for Internet of Things
Devices", draft-ietf-suit-architecture-05 (work in Devices", draft-ietf-suit-architecture-07 (work in
progress), April 2019. progress), October 2019.
[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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.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>.
8.3. URIs 7.3. URIs
[1] mailto:suit@ietf.org [1] mailto:suit@ietf.org
[2] https://www1.ietf.org/mailman/listinfo/suit [2] https://www1.ietf.org/mailman/listinfo/suit
[3] https://www.ietf.org/mail-archive/web/suit/current/index.html [3] https://www.ietf.org/mail-archive/web/suit/current/index.html
Appendix A. Mailing List Information Appendix A. Mailing List Information
The discussion list for this document is located at the e-mail The discussion list for this document is located at the e-mail
 End of changes. 97 change blocks. 
190 lines changed or deleted 333 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/