Draft: draft-ietf-suit-information-model

Commentary: This change set includes editorial fixes from review and several threats and security requirements that are necessary to justify the requirement for an End - to - End security model in SUIT . The new threats listed are : THREAT.NET.MITM THREAT.KEY.EXPOSURE THREAT.MFST.MODIFICATION These were omitted from the previous Information Model drafts because they do not directly inform the fields present in the manifest , so they were not directly relevant to the SUIT manifest . However , references to End - to - End security imply some system architecture which requires a firm justification . These threats have been to explain why an End - to - End security model is needed . The new security requirements are : REQ.SEC.REPORTING REQ.SEC.KEY.PROTECTION REQ.SEC.MFST.CHECK REQ.SEC.MFST.TRUSTED These requirements address the Author side of the End - to - End security model
Paragraph (version A):
Vulnerabilities with Internet of Things (IoT) devices have raised the
need for a solid and secure firmware update mechanism that is also
suitable for constrained devices.  Incorporating such an update
mechanism to fix vulnerabilities, to update configuration settings,
as well as adding new functionality is recommended by security
experts.
Paragraph (version A):
This document uses terms defined in I-D.ietf-suit-architecture.  The
term 'Operator' refers to both, Device and Network Operator.
Paragraph (version B):
This document uses terms defined in I-D.ietf-suit-architecture.  The
term 'Operator' refers to both Device and Network Operator.
Paragraph (version A):
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 RFC4122 version 5 UUIDs with the vendor's domain name and
the UUID DNS prefix.  Other options include type 1 and type 4 UUIDs.
Paragraph (version A):
Vendor ID is not intended to be a human-readable element.  It is
intended for match/mismatch comparison only.
Paragraph (version B):
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 RFC4122 version 5 UUIDs with the vendor's domain name and
the DNS name space ID.  Other options include type 1 and type 4
UUIDs.
Paragraph (version B):
Vendor ID is not intended to be a human-readable element.  It is
intended for binary match/mismatch comparison only.
Paragraph (version A):
Because the DNS infrastructure prevents multiple registrations of the
same domain name, this UUID is guaranteed to be unique.  Because the
domain name is known, this UUID is reproducible.  Type 1 and type 4
UUIDs produce similar guarantees of uniqueness, but not
reproducibility.
Paragraph (version B):
Because the DNS infrastructure prevents multiple registrations of the
same domain name, this UUID is (with very high probability)
guaranteed to be unique.  Because the domain name is known, this UUID
is reproducible.  Type 1 and type 4 UUIDs produce similar guarantees
of uniqueness, but not reproducibility.
Paragraph (version A):
The Class Identifier UUID SHOULD use the Vendor ID as the UUID
prefix.  Other options include version 1 and 4 UUIDs.  Classes MAY be
more granular than is required to identify firmware compatibility.
Classes MUST NOT be less granular than is required to identify
firmware compatibility.  Devices MAY have multiple Class IDs.
Paragraph (version A):
Class ID is not intended to be a human-readable element.  It is
intended for match/mismatch comparison only.
Paragraph (version A):
If Class ID is not implemented, then each logical device class MUST
use a unique Root of Trust for authorisation.
Paragraph (version B):
The Class Identifier UUID SHOULD use the Vendor ID as the name space
ID.  Other options include version 1 and 4 UUIDs.  Classes MAY be
more granular than is required to identify firmware compatibility.
Classes MUST NOT be less granular than is required to identify
firmware compatibility.  Devices MAY have multiple Class IDs.
Paragraph (version B):
Class ID is not intended to be a human-readable element.  It is
intended for binary match/mismatch comparison only.
Paragraph (version B):
If Class ID is not implemented, then each logical device class MUST
use a unique trust anchor for authorisation.
Paragraph (version A):
The format of the payload MUST be indicated to devices is in an
unambiguous way.  This element provides a mechanism to describe the
payload format, within the signed metadata.
Paragraph (version B):
The format of the payload MUST be indicated to devices in an
unambiguous way.  This element provides a mechanism to describe the
payload format, within the signed metadata.
Paragraph (version A):
A device supports a full filesystem.  The firmware authority chooses
to use the storage identifier as the path at which to install the
payload.  The payload may be a tarball, in which case, it unpacks the
tarball into the specified path.
Paragraph (version A):
A device supports flash memory.  The firmware authority chooses to
make the storage identifier the offset where the image should be
written.
Paragraph (version B):
A device supports a full filesystem.  The Author chooses to use the
storage identifier as the path at which to install the payload.  The
payload may be a tarball, in which case, it unpacks the tarball into
the specified path.
Paragraph (version B):
A device supports flash memory.  The Author chooses to make the
storage identifier the offset where the image should be written.
Paragraph (version A):
This element contains one or more digests of one or more payloads.
This allows the target device to ensure authenticity of the
payload(s).  A serialisation MUST provide a mechanism to select one
payload from a list based on system parameters, such as XIP address.
Paragraph (version B):
This element contains one or more digests of one or more payloads.
This allows the target device to ensure authenticity of the
payload(s).  A serialisation MUST provide a mechanism to select one
payload from a list based on system parameters, such as Execute-In-
Place Installation Address.
Paragraph (version A):
Instructions that the device should execute when processing the
manifest.  This information is distinct from the information
necessary to process a payload.  Additional installation instructions
include information such as update timing (For example, install only
on Sunday, at 0200), procedural considerations (for example, shut
down the equipment under control before executing the update), pre
and post-installation steps (for example, run a script).
Paragraph (version B):
Instructions that the device should execute when processing the
manifest.  This information is distinct from the information
necessary to process a payload.  Additional installation instructions
include information such as update timing (for example, install only
on Sunday, at 0200), procedural considerations (for example, shut
down the equipment under control before executing the update), pre-
and post-installation steps (for example, run a script).
Paragraph (version A):
A list of other manifests that are required by the current manifest.
Manifests are identified an an unambiguous way, such as a digest.
Paragraph (version B):
A list of other manifests that are required by the current manifest.
Manifests are identified an unambiguous way, such as a digest.
Paragraph (version A):
The following sub-sections describe the threat model, user stories,
security requirements, and usability requirements.
Paragraph (version B):
The following sub-sections describe the threat model, user stories,
security requirements, and usability requirements.  This section also
provides the motivations for each of the manifest information
elements.
Paragraph (version A):
If the vendors are the firmware authorities, then devices from Vendor
A will reject images signed by Vendor B since they use different
credentials.  However, if both devices trust the same firmware
authority, then, devices from Vendor A could install firmware
intended for devices from Vendor B.
Paragraph (version B):
If the vendors are the firmware authorities, then devices from Vendor
A will reject images signed by Vendor B since they use different
credentials.  However, if both devices trust the same Author, then,
devices from Vendor A could install firmware intended for devices
from Vendor B.
Paragraph (version B):
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.
Paragraph (version B):
Mitigated by: req-sec-authentic, req-sec-image-confidentiality, req-
sec-authenticated-remote-resource, req-sec-mfst-confidentiality,
Paragraph (version A):
This threat can appear in several ways, however it is ultimately
about interoperability of devices with other systems.  The owner or
operator of a network needs to approve firmware for their network in
order to ensure interoperability with other devices on the network,
or the network itself.  If the firmware is not qualified, it may not
work.  Therefore, if a device installs firmware without the approval
of the network owner or operator, this is a threat to devices and the
network.
Paragraph (version B):
This threat can appear in several ways, however it is ultimately
about ensuring that devices retain the behaviour required by their
Owner, Device Operator, or Network Operator.  The owner or operator
of a device typically requires that the device maintain certain
features, functions, capabilities, behaviours, or interoperability
constraints (more generally, behaviour).  If these requirements are
broken, then a device will not fulfill its purpose.  Therefore, if
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
An authorised actor, but not the firmware authority, uses an override
mechanism (user-story-override) to change an information element in a
manifest signed by the firmware authority.  For example, if the
authorised actor overrides the digest and URI of the payload, the
actor can replace the entire payload with a payload of their choice.
Paragraph (version B):
An authorised actor, but not the Author, uses an override mechanism
(user-story-override) to change an information element in a manifest
signed by the Author.  For example, if the authorised actor overrides
the digest and URI of the payload, the actor can replace the entire
payload with a payload of their choice.
Paragraph (version B):
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
own code in order to make better use of an existing vulnerability.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
Mitigated by: req-sec-mfst-check,
Paragraph (version A):
The authenticity of an update MUST be demonstrable.  Typically, this
means that updates must be digitally authenticated.  Because the
manifest contains information about how to install the update, the
manifest's authenticity MUST also be demonstrable.  To reduce the
overhead required for validation, the manifest contains the digest of
the firmware image, rather than a second digital signature.  The
authenticity of the manifest can be verified with a digital signature
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.
Paragraph (version B):
The authenticity of an update MUST be demonstrable.  Typically, this
means that updates must be digitally authenticated.  Because the
manifest contains information about how to install the update, the
manifest's authenticity MUST also be demonstrable.  To reduce the
overhead required for validation, the manifest contains the digest of
the firmware image, rather than a second digital signature.  The
authenticity of the manifest can be verified with a digital signature
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.
Paragraph (version B):
Mitigates: threat-img-unauthenticated,
Paragraph (version B):
Mitigates: threat-net-redirect,
Paragraph (version A):
If a device grants different rights to different actors, exercising
those rights MUST be accompanied by proof of those rights, in the
form of proof of authenticity.  Authenticity mechanisms such as those
required in req-sec-authentic are acceptable but need to follow the
end-to-end security model.
Paragraph (version A):
For example, if a device has a policy that requires that firmware
have both an Authorship right and a Qualification right and if that
device grants Authorship and Qualification rights to different
parties, such as a Device Operator and a Network Operator,
respectively, then the firmware cannot be installed without proof of
rights from both the Device and the Network Operator.
Paragraph (version B):
If a device grants different rights to different actors, exercising
those rights MUST be accompanied by proof of those rights, in the
form of proof of authenticity.  Authenticity mechanisms such as those
required in req-sec-authentic can be used to prove authenticity.
Paragraph (version B):
For example, if a device has a policy that requires that firmware
have both an Authorship right and a Qualification right and if that
device grants Authorship and Qualification rights to different
parties, such as a Device Operator and a Network Operator,
respectively, then the firmware cannot be installed without proof of
rights from both the Device Operator and the Network Operator.
Paragraph (version B):
Mitigates: threat-img-disclosure,
Paragraph (version B):
Mitigates: threat-mfst-exposure,
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
Manifests SHOULD be parsed and examined prior to deployment to
validate that their contents have not been modified during creation
and signing.
Paragraph (version B):
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).
Paragraph (version A):
As a Network Operator, I would like to be able to override the non-
critical information in the manifest so that I can control my devices
more precisely.  The authority to override this information is
provided via the installation of a limited trust relationship by
another authority.
Paragraph (version A):
manifest-element-resource-indicator: this allows the Network
Operator to direct devices to their own infrastructure in order to
reduce network load.
Paragraph (version A):
Conditions: this allows the Network Operator to pose additional
constraints on the installation of the manifest.
Paragraph (version A):
manifest-element-additional-install-info: this allows the Network
Operator to add more instructions such as time of installation.
Paragraph (version B):
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
more precisely.  The authority to override this information is
provided via the installation of a limited trust anchor by another
authority.
Paragraph (version B):
manifest-element-resource-indicator: this allows the Device
Operator to direct devices to their own infrastructure in order to
reduce network load.
Paragraph (version B):
Conditions: this allows the Device Operator to pose additional
constraints on the installation of the manifest.
Paragraph (version B):
manifest-element-additional-install-info: this allows the Device
Operator to add more instructions such as time of installation.
Paragraph (version A):
As an Operator, I want to divide my firmware into components, so that
I can reduce the size of updates, make different parties responsible
for different components, and divide my firmware into frequently
updated and infrequently updated components.
Paragraph (version B):
As a Device Operator, I want to divide my firmware into components,
so that I can reduce the size of updates, make different parties
responsible for different components, and divide my firmware into
frequently updated and infrequently updated components.
Paragraph (version A):
As an Operator, 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.
Paragraph (version A):
As an firmware author, I want to prevent confidential information
from being disclosed during firmware updates.  It is assumed that
channel security or at-rest encryption is adequate to protect the
manifest itself against information disclosure.
Paragraph (version B):
As a Device Operator, I want to be able to send multiple payload
formats to suit the needs of my update, so that I can optimise the
bandwidth used by my devices.
Paragraph (version B):
As a firmware author, I want to prevent confidential information from
being disclosed during firmware updates.  It is assumed that channel
security or at-rest encryption is adequate to protect the manifest
itself against information disclosure.
Paragraph (version A):
As an operator of a constrained network, I would like to be able to
send a small payload in the same packet as the manifest so that I can
reduce network traffic.
Paragraph (version B):
As an operator of devices on a constrained network, I would like the
manifest to be able to include a small payload in the same packet so
that I can reduce network traffic.
Paragraph (version A):
As an operator that rotates delegated authority more often than
delivering firmware updates, I would like to delegate a new authority
when I deliver a firmware update so that I can accomplish both tasks
in a single transmission.
Paragraph (version B):
As a Device Operator that rotates delegated authority more often than
delivering firmware updates, I would like to delegate a new authority
when I deliver a firmware update so that I can accomplish both tasks
in a single transmission.
Paragraph (version A):
Any serialisation MUST enable the delivery of a key claim with, but
not authenticated by a manifest.  This key claim delivers a new key
with which the recipient can verify the manifest.
Paragraph (version B):
Any serialisation MUST enable the delivery of a key claim with, but
not authenticated by, a manifest.  This key claim delivers a new key
with which the recipient can verify the manifest.
Paragraph (version A):
Security considerations for this document are covered in design-
motivation.