Subject: [Suit] Threat Model and User Stories for draft-moran-suit-manifest-00

From: Brendan Moran <[email-masked]>
Date: Fri, 10 Nov 2017 15:27:09 +0000

The manifest format as described in draft-moran-suit-manifest-00 was designed using a threat model and a set of User stories. From the threat model, we extracted security requirements that mitigate the threats and placed fields in the manifest that enable implementation of the security requirements. From the user stories, we extracted usability requirements that enable those user stories, and placed fields in the manifest that implement those usability requirements.

Note that not all user stories are covered here. This is intentional, since there are a great many possible user stories, only sufficient user stories to cover the fields in the Manifest have been included.

Best Regards,
Brendan Moran

Threat Model
=======================
I will describe the threats we have considered, the security requirements that are derived from those threats and the fields that permit implementation of the security requirements. I will address the threats in the order that the relevant fields appear.

This model uses the S.T.R.I.D.E. approach. Each threat is classified according to:
* Spoofing Identity
* Tampering with data
* Repudiation
* Information disclosure
* Denial of service
* Elevation of privilege
See here for more information on The STRIDE Threat Model: https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx

N.B. In firmware update, it is common for an attack to expose all classes of threat.

Threat Descriptions
=======================

Threat MFT1: Old Firmware
-----------------------------------
Classification: Escalation of Privilege

An attacker sends an old, but valid manifest to a device with an old, but valid payload. If there is a known vulnerability in the payload, this can allow an attacker to gain complete control of a device.

Threat Escalation: If the attacker is able to exploit the known vulnerability, then this threat can be escalated to ALL TYPES

Threat MFT2: Mismatched Firmware
-----------------------------------
Classification: Denial of Service

An attacker sends valid firmware, for the wrong type of device, signed by an actor with firmware installation authority on both types of device. The firmware is trusted by the device because it is signed by an actor with firmware installation authority. This could have wide-ranging consequences. For devices that are similar, it could cause minor breakage, or expose security vulnerabilities. For devices that are very different, it is likely to render devices inoperable.

Threat MFT3: Offline device + Old Firmware
-----------------------------------
Classification: Escalation of Privilege

An attacker targets a device that has been offline for a long time and runs an old firmware version. The attacker sends an old, but valid manifest to a device with an old, but valid payload. The attacker-provided firmware is newer than the installed one but older than the most recently available firmware. If there is a known vulnerability in the payload, this can allow an attacker to gain complete control of a device. Because the device has been offline for a long time, it is unaware of any new updates. As such it will treat the old manifest as the most current.

Threat Escalation: If the attacker is able to exploit the known vulnerability, then this threat can be escalated to ALL TYPES

Threat MFT4: The target device misinterprets the type of payload.
-----------------------------------
Classification: Denial of Service

If a device misinterprets the payload type, it may cause a device to install a payload incorrectly. An incorrectly installed payload would likely cause the device to stop functioning.

Threat Escalation: An attacker that can cause a device to misinterpret the received code and could gain an Escalation of Privilege and potentially expand this to all types of threat.

Threat MFT5: The target device installs the payload to the wrong location
-----------------------------------
Classification: Denial of Service

If a device installs code or data to the wrong part of the device, then it is likely to break. A firmware installed as configuration or a network stack installed as an application could cause a device to stop functioning.

Threat Escalation: An attacker that can cause a device to misinterpret the received code and could gain an Escalation of Privilege and potentially expand this to all types of threat.

Threat MFT6: Redirection
-----------------------------------
Classification: Denial of Service

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 attacker to provide broken payloads to devices without needing to construct a Man in the Middle.

Threat MFT7: Payload Verification on Boot
-----------------------------------
Classification: All Types

An attacker replaces a newly downloaded firmware after a device finishes verifying a manifest. This could cause the device to execute the attacker’s code. This attack likely requires physical access to the device, however it is possible that it could be carried out when combined with another threat that allows remote execution.

Threat MFT8: Unauthenticated Updates
-----------------------------------
Classification: All Types

If an attacker can install their firmware on a device, by manipulating either payload or metadata, then they have complete control of the device.

Threat MFT9: Unexpected Precursor images
-----------------------------------
Classification: Denial of Service

An attacker sends a valid, current manifest to a device that has an unexpected precursor image. If a payload format requires a precursor image (for example, delta updates) and that precursor image is not available on the target device, it could cause the update to break.

Threat Escalation: An attacker that can cause a device to install a payload against the wrong precursor image could gain an Escalation of Privilege and potentially expand this to all types of threat.

Security Requirements
=======================
The security requirements here are a set of policies that mitigate the threats described in the previous section

Security Requirement MFSR1: monotonic sequence numbers
-----------------------------------
Only an actor with firmware installation authority is permitted to decide when device firmware can be installed. To enforce this rule, Manifests MUST contain a monotonic sequence number. Manifests MAY use UTC epoch timestamps to coordinate monotonic sequence numbers across many actors in many locations. Devices MUST reject manifests with sequence numbers smaller than any onboard sequence number.

N.B. This is not a firmware version. It is a manifest sequence number. A firmware version may be rolled back by creating a new manifest for the old firmware version with a later sequence number.

Mitigates: Threat MFT1

Security Requirement MFSR2: Vendor, device-type identifiers
-----------------------------------
Devices MUST only apply firmware that is intended for them. Devices MUST know with fine granularity that a given update applies to their vendor, model, hardware revision, software revision. Human-readable identifiers are often error-prone in this regard, so Unique-IDs SHOULD be used.

Mitigates: Threat MFT2

Security Requirement MFSR3: Best-Before timestamps
-----------------------------------
Firmware MAY expire after a given time. Devices MAY provide a secure clock (local or remote). If a secure clock is provided and the Firmware Manifest has a best-before timestamp, the device MUST reject the manifest if current time is larger than the best-before time.

Mitigates: Threat MFT3

Security Requirement MFSR4: Signed Payload Descriptor
-----------------------------------
All descriptive information about the payload MUST be signed. This MUST include:
* The location to store the payload
* The payload digest, in each state of installation (encrypted, plaintext, installed, etc.)
* The payload size
* The payload format
* Where to obtain the payload
* All instructions or parameters for applying the payload
* Any rules that identify whether or not the payload can be used on this device

Mitigates: Threats MFT5, MFT6, MFT7, MFT9

Security Requirement MFSR5: Provable authenticity
-----------------------------------
The authenticity of an update must be provable, with sufficient levels of entropy to remain secure for the lifetime of the device. Typically, this means that updates must be signed. Other proof mechanisms are acceptable, such as MACs, or Authenticated Encryption, or AEAD algorithms. Because the manifest contains information about how to install the update, the manifest's authenticity must be provable. To reduce the overhead required for validation, the manifest contains the digest of the payload, rather than another signature. This does not change the provability of the payload. The authenticity of the manifest is provable with a signature, the authenticity of the payload digest is provable with the manifest, and the authenticity of the payload is provable with the payload digest.

Mitigates: Threat MFT8

User Stories
=======================
User stories provide expected use-cases. These are used to feed into usability requirements.

Use Case MFUC1: Installation Instructions
-----------------------------------
As an OEM for IoT devices, I want to provide my devices with additional installation instructions so that I can keep process detail out of my payload data.

Some installation instructions might be:
* Specify a package handler
* Use a table of hashes to ensure that each block of the payload is validate before writing.
* Run post-processing script after the update is installed
* Do not report progress
* Pre-cache the update, but do not install
* Install the pre-cached update matching this manifest
* Install this update immediately, overriding any long-running tasks.

Use Case MFUC2: Operator Infrastructure
-----------------------------------
As an Operator of IoT devices, I would like to tell my devices to look at my own infrastructure for payloads so that I can manage the traffic generated by firmware updates on my network and my peers’ networks.

Use Case MFUC3: Modular Update
-----------------------------------
As an OEM of IoT devices, I want to divide my firmware into frequently updated and infrequently updated components, so that I can reduce the size of updates and make different parties responsible for different components.

Use Case MFUC4: Multiple Authorisations
-----------------------------------
As an Operator, I want to ensure the quality of a firmware update before installing it, so that I can ensure a high standard of reliability on my network. The OEM may restrict my ability to create firmware, so I cannot be the only authority on the device.

Use Case MFUC5: Multiple Payload Formats
-----------------------------------
As a OEM or Operator of devices, I want to be able to send multiple payload formats to suit the needs of my update, so that I can optimise the bandwidth used by my devices.

Usability Requirements
=======================
The following usability requirements satisfy the user stories listed above.

Usability Requirement MFUR1:
It must be possible to write additional installation instructions into the manifest.

Satisfies Use-Case MFUC1

Usability Requirement MFUR2:
-----------------------------------
It must be possible to redirect payload fetches. This applies where two manifests are used in conjunction. For example, an OEM manifest specifies a payload and signs it, and provides a URI for that payload. An Operator creates a second manifest, with a dependency on the first. They use this second manifest to override the URIs provided by the OEM, directing them into their own infrastructure instead.

Satisfies Use-Case MFUC2

Usability Requirement MFUR3:
-----------------------------------
It MUST be possible to link multiple manifests together so that a multi-component update can be described. This allows multiple parties with different permissions to collaborate in creating a single update for the IoT device, across multiple components.

Satisfies Use-Case MFUC2, MFUC3

Usability Requirement MFUR4:
-----------------------------------
It MUST be possible to sign a manifest multiple times so that signatures from multiple parties with different permissions can be required in order to authorise installation of a manifest.

Satisfies Use-Case MFUC4

Usability Requirement MFUR5:
-----------------------------------
The manifest format MUST accommodate any payload format that an operator or OEM wishes to use. Some examples of payload format would be:
* Binary
* Elf
* Differential
* Compressed
* Packed configuration

Satisfies Use-Case MFUC5

Manifest Fields:
=======================
Each manifest field is anchored in a security requirement or a usability requirement. The manifest fields are described below and justified by their requirements.

Manifest Field: Timestamp
-----------------------------------
A monotonic sequence number, implemented as an integer Timestamp.

Implements: Security Requirement MFSR1.

Manifest Field: Vendor ID condition
-----------------------------------
Vendor IDs MUST be unique. This is to prevent similarly, or identically named entities from different geographic regions from colliding in their customer’s infrastructure. Recommended practice is to use type 5 UUIDs with the vendor’s domain name and the UUID DNS prefix. Other options include type 1 and type 4 UUIDs.

Implements: Security Requirement MFSR2, MFSR4.

Manifest Field: Class ID condition
-----------------------------------
Class Identifiers MUST be unique within a Vendor ID. This is to prevent similarly, or identically named devices colliding in their customer’s infrastructure. Recommended practice is to use type 5 UUIDs with the model, hardware revision, etc. and use the Vendor ID as the UUID prefix. Other options include type 1 and type 4 UUIDs. A device “Class” is defined as any device that can run the same firmware without modification. Classes MAY be implemented in a more granular way. Classes MUST NOT be implemented in a less granular way. Class ID can encompass model name, hardware revision, software revision. Devices MAY have multiple Class IDs.

Implements: Security Requirement MFSR2, MFSR4.

Manifest Field: Precursor Image Digest Condition
-----------------------------------
When a precursor image is required by the payload format, a precursor image digest condition MUST be present in the conditions list.

Implements: Security Requirement MFSR4

Manifest Field: Best-Before timestamp
-----------------------------------
This field tells a device the last application time. This is only usable in conjunction with a secure clock.

Implements Security Requirement MFSR3

Manifest Field: Payload Format
-----------------------------------
The format of the payload must be indicated to devices is in an unambiguous way. This field provides a mechanism to describe the payload format, within the signed metadata.

Implements Security Requirement MFSR4, Usability Requirement MFUR5

Manifest Field: Storage Location
-----------------------------------
This field tells the device which component is being updated. The device can use this to establish which permissions are necessary and the physical location to use.

Implements Security Requirement MFSR4

Manifest Field: URIs
-----------------------------------
This field is a list of weighted URIs that the device uses to select where to obtain a payload.

Implements Security Requirement MFSR4

Manifest Field: digests
-----------------------------------
This field is a map of digests, each for a separate stage of installation. This allows the target device to ensure authenticity of the payload at every step of installation.

Implements Security Requirement MFSR4

Manifest Field: Size
-----------------------------------
The size of the payload in bytes.

Implements Security Requirement MFSR4

Manifest Field: Signature
-----------------------------------
This is not strictly a manifest field. Instead, the manifest is wrapped by a standardised signature container, such as a COSE or CMS signature object. The signature container MUST support multiple signatures.

Implements Security Requirement MFSR5, MFUR4

Manifest Field: Directives
-----------------------------------
A list of instructions that the device should execute, in order, when installing the payload.

Implements Usability Requirement MFUR1

Manifest Field: Aliases
-----------------------------------
A list of URI/Digest pairs. A device should build an alias table while paring a manifest tree and treat any aliases as top-ranked URIs for the corresponding digest.

Implements Usability Requirement MFUR2

Manifest Field: Dependencies
-----------------------------------
A list of URI/Digest pairs that refer to other manifests by digest. The manifests that are linked in this way must be acquired and installed simultaneously in order to form a complete update.

Implements Usability Requirement MFUR3

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 10 Nov 2017 23:38:23 +0800

+1 to STRIDE in respect to achievable threat models. Please consider that additional use cases e.g from Richard & Caraten might have to be taken into account, resulting in merged or added use cases (or usage scenarios, some of the use cases look more like those).

In any case, your approach is commendable and should be applied more rigorously in many cases, I think.

Alas, it is a very resource consuming  process, but I will try my best to provide comments and feedback after .sg, because your approach deserves both attention and support.

Thank you for taking on the effort, Brendon. You are addressing an important prerequisite.

Hochachtungsvoll,

Henk

On November 10, 2017 11:27:09 PM GMT+08:00, Brendan Moran <[email-masked]> wrote:
>The manifest format as described in draft-moran-suit-manifest-00 was
>designed using a threat model and a set of User stories. From the
>threat model, we extracted security requirements that mitigate the
>threats and placed fields in the manifest that enable implementation of
>the security requirements. From the user stories, we extracted
>usability requirements that enable those user stories, and placed
>fields in the manifest that implement those usability requirements.
>
>Note that not all user stories are covered here. This is intentional,
>since there are a great many possible user stories, only sufficient
>user stories to cover the fields in the Manifest have been included.
>
>Best Regards,
>Brendan Moran
>
>Threat Model
>=======================
>I will describe the threats we have considered, the security
>requirements that are derived from those threats and the fields that
>permit implementation of the security requirements. I will address the
>threats in the order that the relevant fields appear.
>
>See here for more information on The STRIDE Threat Model:
>https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx
>
>An attacker sends an old, but valid manifest to a device with an old,
>but valid payload. If there is a known vulnerability in the payload,
>this can allow an attacker to gain complete control of a device.
>
>Threat Escalation: If the attacker is able to exploit the known
>vulnerability, then this threat can be escalated to ALL TYPES
>
>An attacker sends valid firmware, for the wrong type of device, signed
>by an actor with firmware installation authority on both types of
>device. The firmware is trusted by the device because it is signed by
>an actor with firmware installation authority. This could have
>wide-ranging consequences. For devices that are similar, it could cause
>minor breakage, or expose security vulnerabilities. For devices that
>are very different, it is likely to render devices inoperable.
>
>An attacker targets a device that has been offline for a long time and
>runs an old firmware version. The attacker sends an old, but valid
>manifest to a device with an old, but valid payload. The
>attacker-provided firmware is newer than the installed one but older
>than the most recently available firmware. If there is a known
>vulnerability in the payload, this can allow an attacker to gain
>complete control of a device. Because the device has been offline for a
>long time, it is unaware of any new updates. As such it will treat the
>old manifest as the most current.
>
>Threat Escalation: If the attacker is able to exploit the known
>vulnerability, then this threat can be escalated to ALL TYPES
>
>If a device misinterprets the payload type, it may cause a device to
>install a payload incorrectly. An incorrectly installed payload would
>likely cause the device to stop functioning.
>
>Threat Escalation: An attacker that can cause a device to misinterpret
>the received code and could gain an Escalation of Privilege and
>potentially expand this to all types of threat.
>
>If a device installs code or data to the wrong part of the device, then
>it is likely to break. A firmware installed as configuration or a
>network stack installed as an application could cause a device to stop
>functioning.
>
>Threat Escalation: An attacker that can cause a device to misinterpret
>the received code and could gain an Escalation of Privilege and
>potentially expand this to all types of threat.
>
>Threat MFT6: Redirection
>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 attacker
>to provide broken payloads to devices without needing to construct a
>Man in the Middle.
>
>An attacker replaces a newly downloaded firmware after a device
>finishes verifying a manifest. This could cause the device to execute
>the attacker’s code. This attack likely requires physical access to the
>device, however it is possible that it could be carried out when
>combined with another threat that allows remote execution.
>
>If an attacker can install their firmware on a device, by manipulating
>either payload or metadata, then they have complete control of the
>device.
>
>An attacker sends a valid, current manifest to a device that has an
>unexpected precursor image. If a payload format requires a precursor
>image (for example, delta updates) and that precursor image is not
>available on the target device, it could cause the update to break.
>
>Threat Escalation: An attacker that can cause a device to install a
>payload against the wrong precursor image could gain an Escalation of
>Privilege and potentially expand this to all types of threat.
>
>
>Security Requirements
>=======================
>The security requirements here are a set of policies that mitigate the
>threats described in the previous section
>
>Only an actor with firmware installation authority is permitted to
>decide when device firmware can be installed. To enforce this rule,
>Manifests MUST contain a monotonic sequence number. Manifests MAY use
>UTC epoch timestamps to coordinate monotonic sequence numbers across
>many actors in many locations. Devices MUST reject manifests with
>sequence numbers smaller than any onboard sequence number.
>
>N.B. This is not a firmware version. It is a manifest sequence number.
>A firmware version may be rolled back by creating a new manifest for
>the old firmware version with a later sequence number.
>
>Mitigates: Threat MFT1
>
>Devices MUST only apply firmware that is intended for them. Devices
>MUST know with fine granularity that a given update applies to their
>vendor, model, hardware revision, software revision. Human-readable
>identifiers are often error-prone in this regard, so Unique-IDs SHOULD
>be used.
>
>Mitigates: Threat MFT2
>
>Firmware MAY expire after a given time. Devices MAY provide a secure
>clock (local or remote). If a secure clock is provided and the Firmware
>Manifest has a best-before timestamp, the device MUST reject the
>manifest if current time is larger than the best-before time.
>
>Mitigates: Threat MFT3
>
>The authenticity of an update must be provable, with sufficient levels
>of entropy to remain secure for the lifetime of the device. Typically,
>this means that updates must be signed. Other proof mechanisms are
>acceptable, such as MACs, or Authenticated Encryption, or AEAD
>algorithms. Because the manifest contains information about how to
>install the update, the manifest's authenticity must be provable. To
>reduce the overhead required for validation, the manifest contains the
>digest of the payload, rather than another signature. This does not
>change the provability of the payload. The authenticity of the manifest
>is provable with a signature, the authenticity of the payload digest is
>provable with the manifest, and the authenticity of the payload is
>provable with the payload digest.
>
>Mitigates: Threat MFT8
>
>User Stories
>=======================
>As an OEM for IoT devices, I want to provide my devices with additional
>installation instructions so that I can keep process detail out of my
>payload data.
>
>As an Operator of IoT devices, I would like to tell my devices to look
>at my own infrastructure for payloads so that I can manage the traffic
>generated by firmware updates on my network and my peers’ networks.
>
>As an OEM of IoT devices, I want to divide my firmware into frequently
>updated and infrequently updated components, so that I can reduce the
>size of updates and make different parties responsible for different
>components.
>
>As an Operator, I want to ensure the quality of a firmware update
>before installing it, so that I can ensure a high standard of
>reliability on my network. The OEM may restrict my ability to create
>firmware, so I cannot be the only authority on the device.
>
>As a OEM or Operator of devices, I want to be able to send multiple
>payload formats to suit the needs of my update, so that I can optimise
>the bandwidth used by my devices.
>
>
>Usability Requirements
>=======================
>It must be possible to redirect payload fetches. This applies where two
>manifests are used in conjunction. For example, an OEM manifest
>specifies a payload and signs it, and provides a URI for that payload.
>An Operator creates a second manifest, with a dependency on the first.
>They use this second manifest to override the URIs provided by the OEM,
>directing them into their own infrastructure instead.
>
>Satisfies Use-Case MFUC2
>
>It MUST be possible to link multiple manifests together so that a
>multi-component update can be described. This allows multiple parties
>with different permissions to collaborate in creating a single update
>for the IoT device, across multiple components.
>
>It MUST be possible to sign a manifest multiple times so that
>signatures from multiple parties with different permissions can be
>required in order to authorise installation of a manifest.
>
>Satisfies Use-Case MFUC4
>
>The manifest format MUST accommodate any payload format that an
>operator or OEM wishes to use. Some examples of payload format would
>be:
>* Binary
>* Elf
>* Differential
>* Compressed
>* Packed configuration
>
>Satisfies Use-Case MFUC5
>
>
>Manifest Fields:
>=======================
>Each manifest field is anchored in a security requirement or a
>usability requirement. The manifest fields are described below and
>justified by their requirements.
>
>Vendor IDs MUST be unique. This is to prevent similarly, or identically
>named entities from different geographic regions from colliding in
>their customer’s infrastructure. Recommended practice is to use type 5
>UUIDs with the vendor’s domain name and the UUID DNS prefix. Other
>options include type 1 and type 4 UUIDs.
>
>Class Identifiers MUST be unique within a Vendor ID. This is to prevent
>similarly, or identically named devices colliding in their customer’s
>infrastructure. Recommended practice is to use type 5 UUIDs with the
>model, hardware revision, etc. and use the Vendor ID as the UUID
>prefix. Other options include type 1 and type 4 UUIDs. A device “Class”
>is defined as any device that can run the same firmware without
>modification. Classes MAY be implemented in a more granular way.
>Classes MUST NOT be implemented in a less granular way. Class ID can
>encompass model name, hardware revision, software revision. Devices MAY
>have multiple Class IDs.
>
>When a precursor image is required by the payload format, a precursor
>image digest condition MUST be present in the conditions list.
>
>This field tells a device the last application time. This is only
>usable in conjunction with a secure clock.
>
>The format of the payload must be indicated to devices is in an
>unambiguous way. This field provides a mechanism to describe the
>payload format, within the signed metadata.
>
>This field tells the device which component is being updated. The
>device can use this to establish which permissions are necessary and
>the physical location to use.
>
>This field is a map of digests, each for a separate stage of
>installation. This allows the target device to ensure authenticity of
>the payload at every step of installation.
>
>This is not strictly a manifest field. Instead, the manifest is wrapped
>by a standardised signature container, such as a COSE or CMS signature
>object. The signature container MUST support multiple signatures.
>
>A list of URI/Digest pairs. A device should build an alias table while
>paring a manifest tree and treat any aliases as top-ranked URIs for the
>corresponding digest.
>
>A list of URI/Digest pairs that refer to other manifests by digest. The
>manifests that are linked in this way must be acquired and installed
>simultaneously in order to form a complete update.
>
>IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose the
>contents to any other person, use it for any purpose, or store or copy
>the information in any medium. Thank you.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Marti Bolivar <[email-masked]>
Date: Fri, 10 Nov 2017 14:03:13 -0500

Hi,

This is my first post to the list, so as a partial introduction, I'm a
developer who has done some work on mcuboot [1]. SUIT invited the mcuboot
developers to lurk / participate, and here I am.

First off, let me emphatically second Henk's comments regarding the
commendable and important work done here, and add another +1 to STRIDE.

As a question to Brendan, do you have any comments on the relationship
between the threats listed here and the goals discussed by Trishank in his
recent email to the list regarding TUF / Uptane, especially those
pertaining to compromise resiliency? My company is also interested in TUF /
Notary / etc. in the Linux arena [2], and it'd be useful to have your
perspective comparing and contrasting TUF's threat model and SUIT's.

Thanks,
Marti

[1] https://github.com/runtimeco/mcuboot
[2]
http://events.linuxfoundation.org/events/embedded-linux-conference-europe/program/schedule

On Fri, Nov 10, 2017 at 10:38 AM, Henk Birkholz <
[email-masked]> wrote:

> +1 to STRIDE in respect to achievable threat models. Please consider that
> additional use cases e.g from Richard & Caraten might have to be taken into
> account, resulting in merged or added use cases (or usage scenarios, some
> of the use cases look more like those).
>
> Alas, it is a very resource consuming process, but I will try my best to
> provide comments and feedback after .sg, because your approach deserves
> both attention and support.
>
>> designed using a threat model and a set of User stories. From the threat
>> model, we extracted security requirements that mitigate the threats and
>> placed fields in the manifest that enable implementation of the security
>> requirements. From the user stories, we extracted usability requirements
>> that enable those user stories, and placed fields in the manifest that
>> implement those usability requirements.
>>
>>
>> since there are a great many possible user stories, only sufficient user
>> stories to cover the fields in the Manifest have been included.
>>
>> Best Regards,
>> Brendan Moran
>>
>>
>> Threat Model
>>
>> =======================
>> I will describe the threats we have considered, the security requirements
>> that are derived from those threats and the fields that permit
>> implementation of the security requirements. I will address the threats in
>> the order that the relevant fields appear.
>>
>>
>> An attacker sends an old, but valid manifest to a device with an old, but
>> valid payload. If there is a known vulnerability in the payload, this can
>> allow an attacker to gain complete control of a device.
>>
>>
>> An attacker sends valid firmware, for the wrong type of device, signed by
>> an actor with firmware installation authority on both types of device. The
>> firmware is trusted by the device because it is signed by an actor with
>> firmware installation authority. This could have wide-ranging consequences.
>> For devices that are similar, it could cause minor breakage, or expose
>> security vulnerabilities. For devices that are very different, it is likely
>> to render devices inoperable.
>>
>>
>> runs an old firmware version. The attacker sends an old, but valid manifest
>> to a device with an old, but valid payload. The attacker-provided firmware
>> is newer than the installed one but older than the most recently available
>> firmware. If there is a known vulnerability in the payload, this can allow
>> an attacker to gain complete control of a device. Because the device has
>> been offline for a long time, it is unaware of any new updates. As such it
>> will treat the old manifest as the most current.
>>
>> the received code and could gain an Escalation of Privilege and potentially
>> expand this to all types of threat.
>>
>> it is likely to break. A firmware installed as configuration or a network
>> stack installed as an application could cause a device to stop functioning.
>>
>> the received code and could gain an Escalation of Privilege and potentially
>> expand this to all types of threat.
>>
>> Threat MFT6: Redirection
>>
>> may be redirected to an attacker’s server. This would allow an attacker to
>> provide broken payloads to devices without needing to construct a Man in
>> the Middle.
>>
>>
>> An attacker replaces a newly downloaded firmware after a device finishes
>> verifying a manifest. This could cause the device to execute the attacker’s
>> code. This attack likely requires physical access to the device, however it
>> is possible that it could be carried out when combined with another threat
>> that allows remote execution.
>>
>> either payload or metadata, then they have complete control of the device.
>>
>> unexpected precursor image. If a payload format requires a precursor image
>> (for example, delta updates) and that precursor image is not available on
>> the target device, it could cause the update to break.
>>
>> Only an actor with firmware installation authority is permitted to decide
>> when device firmware can be installed. To enforce this rule, Manifests MUST
>> contain a monotonic sequence number. Manifests MAY use UTC epoch timestamps
>> to coordinate monotonic sequence numbers across many actors in many
>> locations. Devices MUST reject manifests with sequence numbers smaller than
>> any onboard sequence number.
>>
>>
>> N.B. This is not a firmware version. It is a manifest sequence number. A
>> firmware version may be rolled back by creating a new manifest for the old
>> firmware version with a later sequence number.
>>
>>
>> Mitigates: Threat MFT1
>>
>>
>> Devices MUST only apply firmware that is intended for them. Devices MUST
>> know with fine granularity that a given update applies to their vendor,
>> model, hardware revision, software revision. Human-readable identifiers are
>> often error-prone in this regard, so Unique-IDs SHOULD be used.
>>
>>
>> Mitigates: Threat MFT2
>>
>>
>> Mitigates: Threats MFT5, MFT6, MFT7,
>>
>> MFT9
>>
>> The authenticity of an update must be provable, with sufficient levels of
>> entropy to remain secure for the lifetime of the device. Typically, this
>> means that updates must be signed. Other proof mechanisms are acceptable,
>> such as MACs, or Authenticated Encryption, or AEAD algorithms. Because the
>> manifest contains information about how to install the update, the
>> manifest's authenticity must be provable. To reduce the overhead required
>> for validation, the manifest contains the digest of the payload, rather
>> than another signature. This does not change the provability of the
>> payload. The authenticity of the manifest is provable with a signature, the
>> authenticity of the payload digest is provable with the manifest, and the
>> authenticity of the payload is provable with the payload digest.
>>
>> Mitigates: Threat MFT8
>>
>>
>> User Stories
>>
>> =======================
>> As an Operator of IoT devices, I would like to tell my devices to look at
>> my own infrastructure for payloads so that I can manage the traffic
>> updated and infrequently updated components, so that I can reduce the size
>> of updates and make different parties responsible for different components.
>>
>>
>> As an Operator, I want to ensure the quality of a firmware update before
>> installing it, so that I can ensure a high standard of reliability on my
>> network. The OEM may restrict my ability to create firmware, so I cannot be
>> the only authority on the device.
>>
>>
>> payload formats to suit the needs of my update, so that I can optimise the
>> bandwidth used by my devices.
>>
>>
>> Usability Requirements
>>
>> =======================
>> manifests are used in conjunction. For example, an OEM manifest specifies a
>> payload and signs it, and provides a URI for that payload. An Operator
>> creates a second manifest, with a dependency on the first. They use this
>> second manifest to override the URIs provided by the OEM, directing them
>> into their own infrastructure instead.
>>
>>
>> Satisfies Use-Case MFUC2
>>
>>
>> multi-component update can be described. This allows multiple parties with
>> different permissions to collaborate in creating a single update for the
>> IoT device, across multiple components.
>>
>>
>> It MUST be possible to sign a manifest multiple times so that signatures
>> from multiple parties with different permissions can be required in order
>> to authorise installation of a manifest.
>>
>> Satisfies Use-Case MFUC4
>>
>> The manifest format MUST accommodate any payload format that an operator
>> or OEM wishes to use. Some examples of payload format would be:
>>
>> * Binary
>>
>> * Elf
>>
>> * Differential
>>
>> * Compressed
>> * Packed configuration
>>
>> Satisfies Use-Case MFUC5
>>
>>
>> Manifest Fields:
>>
>> =======================
>> Each manifest field is anchored in a security requirement or a usability
>> requirement. The manifest fields are described below and justified by their
>> requirements.
>>
>>
>> named entities from different geographic regions from colliding in their
>> customer’s infrastructure. Recommended practice is to use type 5 UUIDs with
>> the vendor’s domain name and the UUID DNS prefix. Other options include
>> type 1 and type 4 UUIDs.
>>
>>
>> infrastructure. Recommended practice is to use type 5 UUIDs with the model,
>> hardware revision, etc. and use the Vendor ID as the UUID prefix. Other
>> options include type 1 and type 4 UUIDs. A device “Class” is defined as any
>> device that can run the same firmware without modification. Classes MAY be
>> implemented in a more granular way. Classes MUST NOT be implemented in a
>> less granular way. Class ID can encompass model name, hardware revision,
>> software revision. Devices MAY have multiple Class IDs.
>>
>>
>> unambiguous way. This field provides a mechanism to describe the payload
>> format, within the signed metadata.
>>
>>
>> Implements Security Requirement MFSR4, Usability Requirement
>>
>> MFUR5
>>
>>
>> This field tells the device which component is being updated. The device
>> can use this to establish which permissions are necessary and the physical
>> location to use.
>>
>>
>> installation. This allows the target device to ensure authenticity of the
>> payload at every step of installation.
>>
>>
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>
>
> --
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit
>
>