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

[David Brown <[e-mail]>]

On Wed, Jul 11, 2018 at 10:07:39PM +0000, Dave Thaler wrote:
>Thanks Gurshabad.
>
>A clarifying question below...
>
>> # Privacy ([RFC8280], section 6.2.2)
>> Privacy considerations are with regards to maintaining the confidentiality of firmware image and
>> manifest. Both the firmware image and manifest contain information about the device. As mentioned
>> in the older version of the drafts, Class ID and Vendor ID are typically compiled as strings into the
>> firmware image. If an untrusted intermediary storage is assumed, as in [SUIT-ARCH], this device
>> information will be available to all intermediary and snooping parties, which may violate the device
>> operator’s privacy. Additionally, device information can be used by an attacker to design and mount
>> targeted attacks on the device.
>>
>> Concern: The drafts are inconsistent in its recommendation of encryption of firmware images.
>> Section 3.3.13 of [SUIT-IM] says that the information model must enable encrypted payloads to
>> prevent the attackers from reading the content of the firmware images whereas Section 3.3 of
>> [SUIT-ARCH] leaves the choice of encryption to the authors/OEMs.
>>
>> Recommendation: We recommend removing these inconsistencies, and that the drafts mandate
>> the encryption of the firmware image. Accordingly, we recommend the relevant text of section
>> 3.3 of [SUIT-ARCH] be updated.
>
>I believe the argument for it not being mandatory is that many IoT devices are not associated with
>humans.  For example, factory devices are owned by the factory not a human.   Can you elaborate
>on what the concern is for such devices that would warrant mandatory encryption?   Your comment
>seems focused on devices associated with humans, and so I cannot tell whether your comment
>applies more generally to all use cases that are in scope for the drafts.

In addition, the range of devices covered by these drafts include
those with insufficient capabilities to support encryption.

It is also unclear how it would be possible to not present class and
vendor information in plain text somewhere.  The systems involved in
the software upgrade process need to be able to know what firmware
image to look at, presumably this will be indexed by these values, or
something equivalent.  Even if the image were encrypted, it would be
clear from where the image is coming from what device it applies to.

The intention of encrypting the information is to protect the firmware
author, and I'm not sure that it addresses privacy concerns about the
image.

David