Re: [Suit] Valid but partial updates (possible threat)

Dick Brooks <dick@reliableenergyanalytics.com> Mon, 08 June 2020 14:15 UTC

Return-Path: <dick@reliableenergyanalytics.com>
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 227683A0B62 for <suit@ietfa.amsl.com>; Mon, 8 Jun 2020 07:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 57zNft-eGTeD for <suit@ietfa.amsl.com>; Mon, 8 Jun 2020 07:15:37 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590963A0B60 for <suit@ietf.org>; Mon, 8 Jun 2020 07:15:37 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B260E5C00C7; Mon, 8 Jun 2020 10:15:35 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 08 Jun 2020 10:15:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=gb1RUxYzOz/0EMTnjikOw6jLm3+LwIIpRW+xxsdy3 Mc=; b=t3fSPsmYMuKurL+ee4ZRreH/RsO5WsKlPq3FiGIUfd5lWYPWvyaFZiVPn PveajyPwUaQYQTW9CGws1DgPPsHAaTNg+5J2orv2zZkl/AT3P4KAZyscLCc2APN7 tnCdZWDEKnurLg25I/YO7F/ov2NskAiPmq9fLd2N8U3kMJwMI3ulSHsB31nNqzV6 qEgp0+DUHY0UgSA3EQjspuKu3cbKP2ItfMHLM+N4ouO3kdSuJSqcxjui8nFNBKIO tuZ4b7k2mFoZwERq8Hoi9WoRjT5r4cVWm6nIZTMWAJkELAouO/LWzPLZcIpzcwtZ alTa4yb0LTppA28en6yydTFxwn/sg==
X-ME-Sender: <xms:B0jeXtTkXVsoheT8ikdop2odpeywX1_37OYoEpPkXFG2uy5hjZ3c1A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehvddgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvfhfjgfuffhokfggtgfgofhtse htqhertddvtddunecuhfhrohhmpedfffhitghkuceurhhoohhkshdfuceoughitghksehr vghlihgrsghlvggvnhgvrhhghigrnhgrlhihthhitghsrdgtohhmqeenucggtffrrghtth gvrhhnpeekgfelffejtdduuddvtdeugeevjefhhfehfeeutdeukedvieefhfefffeiuefg vdenucffohhmrghinheprhgvlhhirggslhgvvghnvghrghihrghnrghlhihtihgtshdrtg homhdpihgvthhfrdhorhhgnecukfhppedvudeirdduleefrddugedvrddvvdenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguihgtkhesrhgvlh hirggslhgvvghnvghrghihrghnrghlhihtihgtshdrtghomh
X-ME-Proxy: <xmx:B0jeXmwC91V3x4nsZFOy2DFZdbsC9gIf8Ha9norLVfgMfRVeiXbKng> <xmx:B0jeXi1oSWHK1_TZEC3Fy-TXQHUAk8cJjs7lG4NAt3_6ZzOuH5pZVg> <xmx:B0jeXlA1ObSbxOmAQKb9GsiO6s0xwo_Lrvc_qHl0TvpeNUsLOmwJkQ> <xmx:B0jeXhTlgZd1j6sVuouZHgKbZENmn0u3zwT3zxI-cJn_lMz4nnhA3w>
Received: from farpoint (unknown [216.193.142.22]) by mail.messagingengine.com (Postfix) with ESMTPA id 1F4433061DC5; Mon, 8 Jun 2020 10:15:35 -0400 (EDT)
From: "Dick Brooks" <dick@reliableenergyanalytics.com>
To: =?iso-8859-1?Q?'R=F8nningstad=2C_=D8yvind'?= <Oyvind.Ronningstad@nordicsemi.no>, <suit@ietf.org>
References: <AM0PR05MB4339615FC81DB1B90F72BBEB88850@AM0PR05MB4339.eurprd05.prod.outlook.com>
In-Reply-To: <AM0PR05MB4339615FC81DB1B90F72BBEB88850@AM0PR05MB4339.eurprd05.prod.outlook.com>
Date: Mon, 8 Jun 2020 10:15:31 -0400
Organization: Reliable Energy Analytics
Message-ID: <1e1cd01d63d9f$46a45ec0$d3ed1c40$@reliableenergyanalytics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH8BjzMoS/Ro1UJIeYo9HWw+CF6iKiDMXFw
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/wBbMNfwsjR968ZD-pYvJ3rMKXCE>
Subject: Re: [Suit] Valid but partial updates (possible threat)
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 08 Jun 2020 14:15:39 -0000

This is precisely the type of attack I'm looking to detect before any
attempt at installation of the software. Good use case, Øyvind. 

Thanks,

Dick Brooks

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: dick@reliableenergyanalytics.com
Tel: +1 978-696-1788

-----Original Message-----
From: Suit <suit-bounces@ietf.org> On Behalf Of Rønningstad, Øyvind
Sent: Monday, June 08, 2020 7:37 AM
To: suit@ietf.org
Subject: [Suit] Valid but partial updates (possible threat)

Hi
I have a concern about root manifests. By root manifest I mean the manifest
that describes the whole coordinated update (all payloads, dependencies, and
conditions). For secure boot, the root manifest serves as the "entry point"
for booting the system.

Imagine a device is expecting a new root manifest, and an attacker inserts a
different manifest in its stead. The replacement manifest is a valid
dependency manifest of a valid new root manifest but not a root manifest
itself.. When executed as a root manifest this manifest leaves the device in
a bad state (e.g. No app or incompatible with existing app/libraries). How
to protect against this (without resorting to transport-specific security)?
Maybe a dedicated component for the manifest, with a separate class ID? If
so, this must be known by the implementer, so it should be made explicit in
the manifest document. I think this can also go into the information model
as a distinct threat (even if it is very related to 4.2.3.
THREAT.IMG.INCOMPATIBLE: Mismatched Firmware), since it needs specific
action from the implementer.  Something like:

"Valid but partial update
An attacker sends a subset of a valid update, that when applied in isolation
breaks compatibility with other software on the device, or otherwise leaves
the Software in a bad or incomplete state."

Øyvind Rønningstad

_______________________________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit