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

Gurshabad Grover <gurshabad@cis-india.org> Wed, 11 July 2018 21:30 UTC

Return-Path: <gurshabad@cis-india.org>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800A4130E73; Wed, 11 Jul 2018 14:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rx5IINMxvDFY; Wed, 11 Jul 2018 14:30:54 -0700 (PDT)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1340130DDD; Wed, 11 Jul 2018 14:30:53 -0700 (PDT)
Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gurshabad@cis-india.org>) id 1fdMhH-0002Aq-44; Wed, 11 Jul 2018 23:30:52 +0200
To: suit@ietf.org, hrpc@irtf.org
Cc: Sandeep Jha <sandeepkjha18@gmail.com>
From: Gurshabad Grover <gurshabad@cis-india.org>
Openpgp: preference=signencrypt
Autocrypt: addr=gurshabad@cis-india.org; keydata= xsFNBFriroIBEADfyDpCD8eborMUMXKtZzjo4t2KzrAlUVYgE/TFtrwUP+4Xw4dzakDIzST8 sVYmlXIWhM5NBBTZSQ190vsxrkbi0xxLcXYM2olZEtqkJ8zONZeZLBeGvcfMymtHqD4jHwYb Zm7OXnS45fWDL+HOoMP/VCwEn098rYfnllIkYQD1Gc28Ig+ywjGg8y5p0qMmmmhm2ckgLjnG MJX8t273MSc8wsn/UYH922yif3MQXmrzqgnRl9hRzf90SKqAw38bw7wccb55pIItloKYsi0r zYBKJSOPXn91Z21TpOSTy21M0MZYEAlDn1zeea+q8TggfHNWxOXoKrIm1pqZFRz0k+8i2siJ AHf8bRm/fhukA6szZ6b2nNPxjkAmOv9zvGu6RZGbmeLvQYVBSSnZ67ayZrkKwn7KIyAV6hQM /bVnD8eEZ2tZ0S8lxoZFYSNeMGt2b6WelFZO97/LbjxaJUHd9K8g5H0MwqN1NXoBxRwllVRC 3sVHVoWTBqnKo8qplzvQEAto69PpvuxxKTOFEJeQqmn1b/fo3sLRb4YiIg8Ax+Np7Huzzjk6 vKKgpIwIN7yEUj/ReWi/UA/W4wSg3XkcqTf7h73crnN/1At0PdgozbDV2UbcApaldStP4DfG UiQl0/7MiYLKapDDuSahmoeH3xrNnrzS9BAfuGHezzDbMyPLXQARAQABzSpHdXJzaGFiYWQg R3JvdmVyIDxndXJzaGFiYWRAY2lzLWluZGlhLm9yZz7CwX0EEwEIACcFAlriroICGyMFCQlm AYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQrbl/X+ubfC7/bQ//YQv7zqQE433xxsN/ 3GYKoOFccBy3WvV4DxrTskJ3n3k5lfcZolbc8TQksQOTzyerNt2ZA7fsGZa7eFSW+xR4Yq3/ C9o+5FOoHGhyZhb+x17MILhmyvyUNSj7SdKrRISgurMbV2Vv8LxmTcdrK6CdFF6JLH+opzU1 NlRKwZqROPgbYZEB2QFIUbGfgh2I5AXNyV2XbT7fagfkHk+v9AUV7POP2H1+AZ1xq6iFTm2o 9ufNZsp2bInsDohcVBKC3aH2cnFMjvIXpNoUOx8vb5A2xW0aBUTTJDB/uZw53WOg3kehrCNb ZkML3FnDZLRuu1e8DSWmwk5YIoDzt5bMCgfUwb0C6Q+JuM8lC+8CEEa9qamLc+fhvFAzcrWp VWuSaVeLdhe5NxmtlRYNZdGuKy6sRHjwsEWlwzRylhm74fiDR3aA1eIFsfmYLd4z+i1Fp23Y dHJf7/Gor2CmOxphog9DEA9WCuORXfx4De7hoMKwW4gWKw1A8B12Cv4EOkXmCsWsOnfDEarr 2Yl6elxkhQRfKjAesXb0cezRzZgwsWIsbeYsuWFF7Xi6IzUJ27lxU3p5PcyY8O8aDYOn+pu0 YFJ7s3u2VRRgptVZJmkcN3WTApXSHY8fGl5xAakM/bqFJj9uj5zlMnFN2EplC6/mQkfYfy2f siaGTP/GQV4OSuOeuMLOwU0EWuKuggEQAJ4lAzB72gHw4+rbyxmQNNVmvgYVZPjFtO/MQdYi x1QwRP/gxxqPqTd/ZwQvmPGzXRKw10B7uKSRk6YP12+IG0mXJwHGp9q5CWJE0XNGqX3UWbAc KIzxqPNpsf8e6Bv7jdW0YwLBxJ+RW0NNL6uAxz0sr2frbnS+EZB3cU+zOZzp/9YfTUZO2lxF NzgJoErKe/HLp7aBeJXBBcwO0LQlIT80rTZx2KihBa/Ww/y9E9gV/HacJu/Ncb6E/G3e4xGj 9w9L+UW43q01wy+FSUKy9FLc7D40WqQsj8SXZEpl84SyLcJRoX3mtj59bX2SAN2VB2BAksTu qCh00IcIUGfyHziu5PwUWYM96gOhDSocP4wSeiQ8TwLzaffllz2qhdI296a9lCIYIeWVytEd NU9jJ3RbzXAgE0pnDauNXDaQv1FS5jYi8rlslJUxKnrS69BFNjM5RqQ16Cm0C4rKL7/a8wHC r4VjcjSCM8Lzv8YOOitJ9Yt4Y8SVfO5s3YvxcdSr56nX0W3B1kGbG1GpqWTzOgXzGF5bIsbV 7SPecwUs9ShvmLmZzDUxIQ68n4zj3lMZn5I+pP+Ew6nAAiuSmKdr5cygnCH/NVJzil07t+X4 uR6oKHBhuMFYF1c6Wxk36m+EZz5ZHFaT4rN0WDIJdAEqRzD0Z56V6ansDF8y+ksh0SHlABEB AAHCwWUEGAEIAA8FAlriroICGwwFCQlmAYAACgkQrbl/X+ubfC50rhAAloTaq/fZC1gtiVtU wOB+00gEkjgmzt+rLkW+l2EySTST7tje57W83UZwzCX746B2O//Bqardxz9R1Vr0VFiwHA8g 3qeBqPqiv1WoQch/iZ5d/1MxK4A9xDag1uyqLR8RuGlZ8lATmcP3IabKiuiBV4MlFZ7V2Ib6 5ToPf28xxSyjMzTjQObIG0e009uHlu2z+iQVshLyoyVVAOWWa88D6iuBDC/EtBRjlpjLAjuR YhWVYX6KHdVUijKMHN2RqjpX5O2wPL7NcMY/wsTq7EteUeI75hxFvargRXkEt1XR8t52LC0u IE2OjpzY5re/ROUbfsqL8trjAOrSJ+Fx5H8AYl9JaoVxohhxDZgNtgNtPbh/8Nnlf9daj/bh lZcTBO98XLQwMnyHGPdyhIodpWPq2C09Ys3TkQsbcdMMB1pqnEK5Vz1zIKkEEX7QVsLdrz7C 2CFsauc/9PHj+4njCHslXtzBOiVu5FXTnbCwPrLJs5iEUkUCb6qtE/2mSCTrAanzOTTOmqiM cnNTI1Tj0ht462S9VypppQnKCv8shGxXG7BadZTv+pNCA/WfB2kk1sS3ZwB0wBWX4p41fxs+ ArM9ew2SzQ/vBrEfO7ljPfZZmBqH4t/vgAZBnOtTxCGlPEIJqiMqtGHRqIqpiR20QfxEUuXI MfMfa9QJpisdNmqoUyc=
Message-ID: <11993b06-5da6-e397-3457-de6ecec87bb4@cis-india.org>
Date: Thu, 12 Jul 2018 03:00:48 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Gbpss3sAxMHeB20MlvRrDOH6ylt8kxaGV"
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: 028245575ea82c532dbb94a201c00fd0
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/vH6PL5czghj5eLohdZgLysCwElc>
Subject: [Suit] HR Review: Firmware Update Architecture for IoT Devices
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2018 21:30:58 -0000

Hi,

Thanks to the authors and the working group for developing the
comprehensive drafts.

As part of efforts in the Human Rights Protocol Considerations (HRPC)
group, Sandeep and I have reviewed the human rights considerations (RFC
8280) in the three drafts.

Following the updates to the drafts on July 2nd, we reached out to some
of you. We are aware that some of the concerns we raise may no longer
apply since the updates; we are sharing our review hoping to engage you
on our other observations (and their solutions) in next week's HRPC
sessions at IETF102.

Review: A Firmware Update Architecture for Internet of Things Devices
=====================================================================

An assessment of human rights considerations in
* draft-ietf-suit-architecture-01
* draft-moran-suit-manifest-02
* draft-ietf-suit-information-model-01

Introduction
------------
‘A Firmware Update Architecture for Internet of Things Devices’
(draft-ietf-suit-architecture-01) proposes an architecture for firmware
update mechanism suitable for IoT devices, and lists various
requirements associated with the same. [SUIT-ARCH]

‘A CBOR-based Manifest Serialisation Format’
(draft-moran-suit-manifest-02) describes the format of the manifest
which contains firmware update metadata for a device. The draft defines
components of the manifest and specifies their functions in
firmware-update process. [SUIT-MF]

‘Firmware Updates for Internet of Things Devices - An Information Model
for Manifests’ (draft-ietf-suit-information-model-01) describes the
information in the manifest, a threat model for the architecture, and
provides security requirements for the mitigation of these threats.
[SUIT-IM]

This is a review of the human rights considerations in the three drafts.
(See [RFC8280], ‘Research Into Human Rights Protocol Considerations’).

Human Rights Considerations
---------------------------

# 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.


Concern: The manifest also contains information of the device (such as
device-manufacturer’s name, model name, and model number) which an
end-user operates, but the drafts have not recommended the encryption of
the manifest.

Recommendation: We recommend that the drafts ([SUIT-ARCH], [SUIT-MF])
recommend encryption of the manifest as well.

# Security  ([RFC8280], section 6.2.4)

Security concerns have been emphasised in the draft [SUIT-IM]; various
threats have been covered in the thread model (section 3.1 of [SUIT-IM])
and possible mitigations have been discussed.

# Internationalization ([RFC8280], section 6.2.5) and Localization
([RFC8280], section 6.2.12)

Concern: For the specific question, “Does your protocol have text
strings that have to be understood or entered by humans?” [RFC8280]: An
email highlighting the recent updates to the drafts [MF-MAIL] notes that
a container in the manifest will have “severable” text meant for humans.
However, it is not clear from the draft what this text will contain.
Since the update server may choose to send the text to the device (if
the device supports it), human readability of these text strings is a
concern from a human rights perspective.

Recommendation: Support of multiple languages for text meant to be read
by humans advances access to information and non-discrimination. OEMs
must have the ability to internationalise and localise any text meant to
be read by humans. CBOR does support UTF-8; we recommend that the draft
make the internationalisation ability explicit for all text meant for
humans.

# Open standards ([RFC8280], section 6.2.7)
 
Pertaining to the question in [RFC8280], “is your protocol fully
documented in such a way that it could be easily implemented, improved,
built upon, and/or further developed?”, we found some statements in the
drafts that might impede further improvement and development:
* The use of the ‘extensions’ field of the manifest, defined in Section
2.1 of [SUIT-MF], has not been defined.
* Section 4.18 of [SUIT-IM] says that linked manifests must be installed
simultaneously. For clarity, we recommend that the draft specify that
each linked manifest must be validated separately.


# Reliability ([RFC8280], section 6.2.14)

Reliability concerns have been addressed in Section 3.5 and 3.6 of
[SUIT-ARCH].

Concern: With regard to the question, “[d]o you have a documented way to
announce degradation?” [RFC8280], [SUIT-ARCH] does not provide any
mechanism to convey the degradation to either the author or the device
operator.

Recommendation: We recommend that [SUIT-ARCH] recommend that degradation
is made apparent to the operator.


Concern: With regard to the question, “[d]o you have measures in place
for recovery or partial healing from failure?”, Section 3.6 of
[SUIT-ARCH] says that a recovery mechanism is optional. The lack of a
recovery mechanism will render the device inoperational in case an
update fails; this aspect is especially important in the case of
constrained devices where communication about the failure of the update
may not always be apparent to the operator.

Recommendation: Instead of making the recovery mechanism optional, we
suggest that the firmware architecture recommend or mandate the
inclusion of a recovery mechanism to ensure high reliability of the
devices in case the update fails.

# Integrity ([RFC8280], section 6.2.16)
Integrity concerns mentioned have been adequately addressed in the
Section 3.3 of the [SUIT-IM].

# Authenticity ([RFC8280], section 6.2.17)
Authenticity concerns have been adequately addressed in the Section 3.3,
in particular, the subsections 3.3.5, 3.3.6 of [SUIT-IM].

# Outcome Transparency ([RFC8280], section 6.2.12)
Whenever possible, the fact whether a update has been successful or
unsuccessful should be conveyed to the device operator. In case of
update failure, an error description should be provided. The status
tracker, described in Section 2 of [SUIT-ARCH] as offering device
management functionalities and update progress tracking, can serve this
function. However, its mechanism is not sufficiently clear in the
drafts. The coordination between status tracker and communicator has
been mentioned in Section 3.10 of [SUIT-ARCH], but the mechanism has not
been elaborated on.

# Others
After going through the drafts, we found no concerns for Heterogeneity
Support ([RFC8280], section 6.2.8) since the architecture makes little
or no assumptions about the devices or transport of the firmware image
and manifest. Concerns in the following sections are out of scope:
Connectivity ([RFC8280], section 6.2.1), Anonymity ([RFC8280], section
6.2.9), Pseudonymity ([RFC8280], section 6.2.10), Decentralization ([RFC
8280], section 6.2.13), Accessibility ([RFC8280], section 6.2.11),
Content Agnosticism ([RFC8280], section 6.2.3), and Censorship
Resistance ([RFC8280], section 6.2.6).

#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.

References
----------
[RFC8280] ten Oever, N., Cath, C., “Research into Human Rights Protocol
Considerations”, RFC 8280, October 2017,
<https://www.rfc-editor.org/info/rfc8280>.
[SUIT-ARCH] Moran, B., Meriac, M., Tschofenig, H., “A Firmware Update
Architecture for Internet of Things Devices”,
draft-ietf-suit-architecture-01, June 2018,
<https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/>.
[SUIT-MF] Moran, B., Meriac, M., Tschofenig, H., “A CBOR-based Manifest
Serialisation Format”, draft-moran-suit-manifest-02, January 2018,
<https://datatracker.ietf.org/doc/draft-moran-suit-manifest/>.
[SUIT-IM] Moran, B., Tschofenig, H., Birkholz, H., Jimenez, J.,
“Firmware Updates for Internet of Things Devices - An Information Model
for Manifests”, draft-ietf-suit-information-model-01, June 2018,
<https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/>.
[MF-MAIL] Moran, B., “[Suit] [suit]: draft-moran-suit-manifest-02”, IETF
Mail Archive, July 2018,
<https://mailarchive.ietf.org/arch/msg/suit/rc1gkzf2jhICwcXHSq5JggdGiHo>

Thanks to Mallory K., Amelia A., Niels t. and Sunil A. for their inputs.

Regards,
Gurshabad