Re: [Suit] HR Review: Firmware Update Architecture for IoT Devices

[Kvamtrø, Frank Audun <[e-mail]>]

Initially: I don't see forced updates stated anywhere in 3.9. It only talks
about authorization. I do share your sentiment that there is a possible 
complexity in referring the term critical infrastructure, but I do see
where the terms come from. Possibly the wording of this could be simplified
by adding another type of actor or operator (mentioned later in this e-mail).
 
I don't argue that the device operator has the final say on the synchronization
of when a firmware upgrade is to be applied, but I don't think that the device
operator should invoke an acceptance on behalf of something that it doesn't 
have signing rights over. I feel the standard tries to do this by describing 
critical infrastructure and talk about the device operator as something that
potentially has more power than it should by being a bit vague in the 
description...

CC'ing in Brendan as this is a wider point than the change of wording in 
chapter 3.9.

I have a problem distinguishing between an author and a device operator and I
think the reason for this is that there may be a missing type of operator 
described in the standard. I suggest we add a third type, an OEM operator:

(listing all here for reference:)

 - Device Operator: The actor responsible for the day-to-day
 operation of a fleet of IoT devices.

 - OEM Operator: Actor responsible for the day-to-day operation of
 OEM units in IoT devices connected to an IoT network

 - Network Operator: The actor responsible for the operation of a
 network to which IoT devices connect.


If the OEM operator type is added, I don't think we need to distinguish between
an author and a device operator in chapter 3.9 about robust permissions. For 
one the device operator and author does not need to be multiple signers. I 
would assume that the device operator and the firmware author is the same 
entity in this case. Then the device code can have an author, the OEM code can
have an author...
 
The distinction I want to make with an OEM operator and a Device operator is
that the OEM device is just a sub-system of the device, but authorities around 
the OEM device may be dictated between the OEM Operator and the Network 
Operator. This is different than the relationship between the OEM and the 
device operator. One would assume that the device operator wants to have 
control of the authority to accept or reject a firmware upgrade to be able to
synchronize when and how firmware updates are accepted to be applied, but 
he/she does not need to have full control over what an OEM device will accept 
or reject.

The OEM may be dictated by rules of synchronization of updates based on 
requirements from the network operator. It becomes the middleman between the 
Device operator and the Network operator and it should have its own signing
authority. The code running the OEM device may be certified or qualified 
between the OEM operator and the Network operator, totally outside of what the 
device operator has any influence over. Some network operators may even demand 
that the firmware is upgraded at a specific timeline. Not conforming to those 
timelines may lead to the Network operator outright rejecting devices from 
accessing parts of the network functionality.

Some example scenarios for explanation

Scenario 1: Multiple chip update, OEM radio chip
---------

Think of a device with an external OEM radio chip that is only valid in the 
network if it running certain firmware versions. This demand comes from the 
network operator, and is to be enforced by the device operators that use the
OEM radio without subject access to the OEM firmware except accepting a new
signed version from the OEM and adjusting the application to conform to any
changes in API to interface to it.

Both the OEM update and the main application may need to be updated atomically
for the firmware to be applied.

Having multiple signers prevents someone from applying a new firmware version 
on the OEM device out-of-time that may have a catastrophic effect (like an 
incompatible API change). The OEM device firmware is properly signed by the
OEM so it is a valid firmware update, but the addition of the extra authority
from the device operator prevents this from being falsely applied out-of-time.

The device operator is the last in the chain with regards to signing and will
(most likely) have control over when the firmware update process takes place. 
It can only accept or reject based on its own authority, not the authority of
any other signer (which may be accepted/rejected at a later stage in the 
firmware upgrade process).


Scenario: Single chip update, OEM peripheral
---------

If the OEM device is a generic peripheral that shares CPU resources with device
wherein it is used (e.g. for drivers and-or control of the peripheral) it is 
possible that the OEM vendor for the peripheral device wants to have the same
level of control as in the case of an external chip. If the system is complex
enough they may want to give out the firmware to use device under their own
control. An example of this could be a complex communication stack that is 
certified as a whole.

The firmware to run the peripheral may have the same same kind of API 
compatibility scheme you would need as in an IPC to an external chip. The OEM
may want to own all code that is run to interface with the peripheral, e.g.
by signing the firmware delivered to their customers that use the peripherals.

Having a requirement on authority to control when a new firmware is applied by
using multiple signers gives the OEM and the device operator the same level of
security with regards to not applying isolated parts of the firmware 
out-of-time. The device operator will be the last signer in the chains he/she
will be able to control the timeline of when the updates are finally applied 
(and any firmware that needs to be applied in a synchronized manner).


Regards
Frank Audun Kvamtrø

>#Additional suggestions
>
>Section 3.9 of [SUIT-ARCH] talks about multiple authorizations wherein 
>an unnecessary distinction has been made between critical 
>infrastructure and non-critical infrastructure. Even in non-critical 
>infrastructure, operators would want to the ability to install updates 
>according to their own preferences. In such scenarios, forced 
>installations may violate user’s control of the device. Accordingly, we 
>propose that the device operator SHOULD have the authority to accept or 
>reject firmware updates.

Initially: I don't see forced updates stated anywhere in 3.9. It only talks
about authorization. I do share your sentiment that there is a possible 
complexity in referring the term critical infrastructure, but I do see
where the terms come from. Possibly the wording of this could be simplified
by adding another type of actor (mentioned later in this e-mail)
 
I think the reason the text states MAY and not SHOULD like you propose is to 
support both cases, simple single signer or a multiple of signers

I don't argue that the device operator has the final say on
the synchronization of when a firmware upgrade is to be applied, but I don't 
think that the device operator should invoke an acceptance on behalf of
something that it doesn't have signing rights over. The device operator is the
last signer so he/she has a base acceptance criteria for starting a firmware 
upgrade, but I argue that it may not have rights to accept on behalf of all 
sub-systems described in the firmware upgrade. I feel the standard tries
to do this by describing critical infrastructure and talk about the 

I will try to explain my thinking

CC'ing in Brendan as this is a wider point than the change of wording.

There is probably an operator type that isn't expressed in the architecture 
specification that might make chapter 3.9 and multiple signing authorities a bit
clearer. At least it clears up the use-cases a bit more in my mind. It also
has some impact on the difference between a firmware author and a device operator.
I have problem distinguishing the two in the architecture document and I think 
the role may become clearer if the top level actor is the device operator

I suggest we add the third type of operator, an OEM operator

- OEM Operator: Actor responsible for the day-to-day operation of
 OEM units in devices connected to an IoT network

The distinction I want to make with an OEM operator and a device operator is
that the OEM device is just a sub-system of the device, but authorities around 
the OEM device may be dictated between the OEM and the Network Operator. This
is  different than the relationship between the OEM and the device operator. One
would assume that the device operator wants to have control of the authority to 
accept or reject a firmware upgrade to be able to synchronize when and how
firmware updates are accepted to be applied, but he/she does not need to have full
control of what an OEM device will accept or reject.

The OEM may be dictated by rules of functionality and synchronization of updates
based on requirements from the network operator. It becomes the middleman
between the Device operator and the Network operator and it should have its
own signing authority. The code running the OEM device may be certified or
qualified between the OEM operator and the Network operator, totally outside of 
what the device operator has any influence over. Some network operators may 
even demand that the firmware is upgraded at a specific timeline. Not conforming
to those timelines may lead to the Network operator outright rejecting devices 
from accessing parts of the network functionality.

Some example scenarios to justify this thoughts

Scenario: Justifying requirement of multiple signers: Multiple chip update
---------

Think of a device with an external OEM radio chip that is only valid in the 
network if it running certain firmware versions. This demand comes from the 
network operator, and is to be enforced by the device operators that use the
OEM radio without subject access to the OEM firmware except accepting a new
signed version from the OEM and adjusting the application to conform to any
changes in API to interface to it.

Both the OEM update and the main application may need to be updated atomically.

Having multiple signers prevents someone from applying a new firmware version 
on the OEM device out-of-time that may have a catastrophic effect (like an 
incompatible API change). The OEM device firmware is properly signed by the
OEM so it is a valid firmware update, but the addition of the extra authority
from the device operator prevents this from being falsely applied out-of-time

The device operator is the last in the chain with regards to singing and will
most likely have control over when the firmware update process takes place. It 
can only accept or reject based on its own authority, not the authority of any
other signer (which may be accepted/rejected at a later stage in the firmware 
upgrade process).


Scenario: Justifying requirement of multiple signers: Single chip update
---------

If the OEM device is a generic peripheral that shares CPU resources with device
wherein it is used (e.g. for drivers and-or control of the peripheral) it is 
possible that the OEM vendor for the peripheral device wants to have the same
level of control as in the case of an external chip. If the system is complex
enough they may want to give out the firmware to use device under their own
control. An example of this  could be a complex communication stack that is 
certified as a whole.

The firmware to run the peripheral may have the same same kind of API 
compatibility scheme you would need as in an IPC to an external chip. The OEM
may want to own all code that is run to interface with the peripheral, e.g.
by signing the firmware delivered to their customers that use the peripherals.

Having a requirement on authority to control the application of a new versions
gives the OEM and the device operator the same level of security with regards
to not applying isolated parts of the firmware out-of-time. The device operator 
will be the last signer in the chains he/she will be able to control the 
timeline of when the updates are finally applied (and any firmware that needs
to be applied in a synchronized manner)


Chapter 3.9 should probably have some refreshing of the language and I think 
that it is possible to clear up some misunderstandings.


Regards
Frank Audun Kvamtrø

> -----Original Message-----
> From: Suit [mailto:[e-mail]] On Behalf Of Gurshabad Grover
> Sent: 12. juli 2018 11:42
> To: David Brown <[e-mail]>
> Cc: Sandeep Jha <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [Suit] HR Review: Firmware Update Architecture for IoT Devices
> 
> Hi David,
> 
> Thanks. Just to clarify that particular suggestion: we suggested that the
> draft mention that the device operator SHOULD have the ability to accept or
> reject updates, not "MUST".
> 
> In any case, I re-read draft-ietf-suit-architecture, and found the updated
> Section 3.10 useful. Because of the great diversity in the devices in scope
> of the architecture, I understand that it is hard to take a call on whether
> client authorisation is desirable in the general case. We can leave this
> suggestion out.
> 
> Thank you.
> Gurshabad
> 
> On Thursday 12 July 2018 05:28 AM, David Brown wrote:
> > This depends a lot on who the device operator is referring to.  From a
> > security perspective, the vendor may wish to make certain types of
> > security updates mandatory.  As stated earlier, for devices say in a
> > factory, or installed on a water meter, it is unclear who the device
> > operator is.  An organization installing water meeting IoT devices is
> > unlikely to allow the individual consumers of water to have any
> > authority as to whether firmware is installed.
> >
> > Realistically, calling this mandatory in the spec would mostly just
> > result in that criteria of the spec being ignored.
> >
> > One challenge with SUIT, in general, is that those producing these
> > end-use devices have little motivation to comply with the spec.  The
> > benefits gained to them are resources (such as reference code) and
> > infrastructure that wouldn't have to be implemented.  They have little
> > reason to not modify any behavior of the code that doesn't suit their
> > own requirements.
> >
> > Although there may be good reasons to desire that decisions like this
> > be granted to certain parties, the SUIT documents have little
> > authority for enforce them.
> >
> > David