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

"Rønningstad, Øyvind" <Oyvind.Ronningstad@nordicsemi.no> Tue, 09 June 2020 12:52 UTC

Return-Path: <Oyvind.Ronningstad@nordicsemi.no>
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 EFBCD3A08B9 for <suit@ietfa.amsl.com>; Tue, 9 Jun 2020 05:52:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordicsemi.onmicrosoft.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 fGJwrhcBriE2 for <suit@ietfa.amsl.com>; Tue, 9 Jun 2020 05:52:15 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70088.outbound.protection.outlook.com [40.107.7.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716293A08B8 for <suit@ietf.org>; Tue, 9 Jun 2020 05:52:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lEXwo1CLurARJMUTTzkjHTPDmAoEwL0iSj+Iz8Y+3bu3QQi8u/FidRarHPjrCMIws1M2Z4kMh/kVdVMFIrPd3lg6dNB1eO4uOpgzrTZmdk9oUx9NMHX7142bP73EPFaaE/y9t0WraNpHDiZFVBtKYuU38+oXWPDk6uvaTGfSqAwXMLrMGYPOrN+7Fgg6RfexuDnZzSRnp58RsNIm3KrgclSR17m+R0XFe4lHYze/lqvEWeEVD+Ms80zbXSvKYg/9ylPbxi4duUJVbd9puxVPDGg90ONKTMe1CiXYJ6oZiNrJ1mnzSzV5NJqaK1ax0meKEZP5TfdyjVB0AQFSB3oU6Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wYeV/FB5MALoLC9bq1RTWsrzChPM6MwgJm18z98lGFo=; b=JjgvFeHO2AmNotDyHEaOcqWRMlmSAiha6a4Xr3KiXBCfxy4cltLQ+Tg2z7UATpttXI48jf6eJX+EvjAGnFZxSJr2vgNk+QgaRVXZDpql3qiiSUVLGfE447VywEOPvTUnMgCWCoY+bc/w9Jq47vPuMDB2jgNwtF80pZ3kAmZUMSzehe+4w7HoAnGvbYwL/CEZPDi6LFbQZDY/voapU+cVAlzVn2HFnhbxuN0RwH50hLO+wbXRhyMBK69LqiLm5vIm8d6HdhLmwu3rq/ockfb+1sU/76vdZ2s8+Hwn88HmGN6/pAogxY4noHKFypqyEHiKT4OSBP9yRawVhWEeV69dKQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nordicsemi.no; dmarc=pass action=none header.from=nordicsemi.no; dkim=pass header.d=nordicsemi.no; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordicsemi.onmicrosoft.com; s=selector2-nordicsemi-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wYeV/FB5MALoLC9bq1RTWsrzChPM6MwgJm18z98lGFo=; b=bGUDVv9w0/YAfOsOu7uiqh4ZlP0YiUn4mqjoQjKErYoW7gfgYNmYubFL4Rw49y7w1UH7Sw3nY7Uij7oj9zZaAl/LyoZlgl9T47uVZtF48TwHD3USk8II1jtYjN/bOqSSHcinPmbPHTr6iexNv9Qw5s/77lRXPKIYqM5+8bnW3yA=
Received: from AM0PR05MB4339.eurprd05.prod.outlook.com (2603:10a6:208:67::17) by AM0PR05MB5859.eurprd05.prod.outlook.com (2603:10a6:208:124::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.22; Tue, 9 Jun 2020 12:52:11 +0000
Received: from AM0PR05MB4339.eurprd05.prod.outlook.com ([fe80::3911:9394:f1a3:660c]) by AM0PR05MB4339.eurprd05.prod.outlook.com ([fe80::3911:9394:f1a3:660c%7]) with mapi id 15.20.3066.023; Tue, 9 Jun 2020 12:52:10 +0000
From: =?utf-8?B?UsO4bm5pbmdzdGFkLCDDmHl2aW5k?= <Oyvind.Ronningstad@nordicsemi.no>
To: Brendan Moran <Brendan.Moran@arm.com>, Dick Brooks <dick@reliableenergyanalytics.com>
CC: suit <suit@ietf.org>
Thread-Topic: [Suit] Valid but partial updates (possible threat)
Thread-Index: AdY9hz9HHRG3eHplSsijjyFulvlEYAAGAUWAAAJna4AAKUkCIA==
Date: Tue, 9 Jun 2020 12:52:10 +0000
Message-ID: <AM0PR05MB4339C167E024F3B063B5FA5088820@AM0PR05MB4339.eurprd05.prod.outlook.com>
References: <AM0PR05MB4339615FC81DB1B90F72BBEB88850@AM0PR05MB4339.eurprd05.prod.outlook.com> <1e1cd01d63d9f$46a45ec0$d3ed1c40$@reliableenergyanalytics.com> <EC72F0E5-5C9B-4F0C-B73B-D0C634A7722F@arm.com>
In-Reply-To: <EC72F0E5-5C9B-4F0C-B73B-D0C634A7722F@arm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=nordicsemi.no;
x-originating-ip: [2001:8c0:5140:12:48c6:23d0:5484:5a84]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a367478c-4884-4a52-a506-08d80c73ecff
x-ms-traffictypediagnostic: AM0PR05MB5859:
x-microsoft-antispam-prvs: <AM0PR05MB58591C03DA3A15656BBCFF8D88820@AM0PR05MB5859.eurprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 042957ACD7
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EkJCypl7pyy2ORXcZ7ML9LiVgMqWAAhaaC0sSM12H4bp0/ZHh9u5Xb5o2y3HdgmJVNjOOUXhEgmM1w//huBvhaZQDhseFuOl8QRtDbATSTkopZeZY6Mc9yjEYYaNL1YF+1mIqNiSCVw8o7pfLKmroNdnbJoeDaUSD1WeePrkPL9K930ZUHKPnRZG/eT7+I4NLq7LLU/uQS9IRTkGOt4+AkbLe6sYebYeP/uhCACrQ3GjN/SbvKFOsfRmMf8gZrqZYILWSJSdcwoLH72851wUABnRcp7RsXzXOi4cB/V58y7BWOOsYJg8WFsiivrLxG30xJdcTPFmheslmPsVBcDOKtUxIAq2shqpAQeM4eosQtDurR1gnWEdvxEA/7/sudE5RfFRIJ9UxhiKih8B3N9MXP6w3pK3EXsPdaRNvr7AUFJWAMniEc2sPXPXBzyyIwfh5bW5h0UYmzFLXaN38g1X0Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR05MB4339.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(376002)(346002)(39850400004)(136003)(55016002)(8676002)(33656002)(9686003)(316002)(110136005)(86362001)(8936002)(4326008)(2906002)(478600001)(52536014)(53546011)(15650500001)(5660300002)(85202003)(66574014)(66556008)(6506007)(85182001)(71200400001)(7696005)(66446008)(66476007)(966005)(186003)(64756008)(66946007)(76116006)(83380400001)(777600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: ZI73R85128Ed+ZG1Rlg2N+LH2clwnrtQqF/uoG+gTAosufG+FK9aOO+WXLeX9MuSa2y3Y7a1ZtNyD7H90SzSqNJ/x3W7HwvGmlk65RtjCVlHP5NiT5fRdpfFO/U6JsiMOI2ZsfLSRNYAiGfJ26JM6Vk+rD3daLOmiAx2HzI8prydkN7S50ym9a7PJ1SmPJliOQwd5wKAK8rsh/iQ9/SshjM4VHJQouO4Y/xAqjX+YwPtrzvCG2B0NGUNBkoloM9jCuilsWbFq6tYPeFtpxQjN+B85/3rxbtb94YKAC/6hxF8YFhVuszaIAXAQifBBmsXacnrsbFaPojh9Au8KgE42zPzFB0FehJmIUkspl3DIQS/snzrQsRLoeiwMwnhiaKlvrd+3b/lvGhqhcTLdI5TSXD3j/93etLMYs/fiwwIfjiK0lo9tmRa4qFhHz8O+9TrgvF4UupjNGDEzIjxg1AY4ToWpVe73V16l32YUZCYWvumvCdATdJIytnEkfIIJIwTTCy8B6+vLNBqgJgGlLMomE+a/1Wu+sRw1q2BgYBMAtA=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nordicsemi.no
X-MS-Exchange-CrossTenant-Network-Message-Id: a367478c-4884-4a52-a506-08d80c73ecff
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 12:52:10.8165 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 28e5afa2-bf6f-419a-8cf6-b31c6e9e5e8d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: iwNZPcspSh0H7SVQqPJ+VtxPRaPowKIu6oNx37CgpAr8PjWO9+g5zCP9SXMmr1qLhr/RN+q2a9ExpXdORT7w/RPrMAHCeOGvaiQBS+9iAuaJwniN4xVpVcnSjuvNGxol
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR05MB5859
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/HCnYXeod6byHtF-Vxl5etpVR6tQ>
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: Tue, 09 Jun 2020 12:52:17 -0000

Thanks.

1. This will fully mitigate the threat, but will require each implementer to be very cognizant, so should be explained carefully.

2. This seems a more fuzzy requirement, and I can envision it being tricky to implement, and will not work in cases where partial updates are sometimes valid (e.g. minor update to network stack).

Both of these will work, but are very use-case dependent. I'm thinking we should take care to formulate them so that they can be implemented generically, with each user configuring the behavior to suit their product. This is to make it easier to implement correctly, or rather, harder to implement incorrectly.

One idea building on your 1st mitigation: A new directive "enable-update" which takes as parameter any or all of: vendor-id, class-id, device-id, and component. The update fails if after the first suit-common block, the update hasn't been "enabled" with the right signing key and parameters. Because of the override mechanics, sub-manifests don't need to include the "enable" call.

We can also formalize the 2nd mitigation to something like: A SUIT implementation MUST keep a list of components that must be updated together. An update must fail if it cannot find all these components in either the dependency-components list or the components list.

What do you think?

BR,
Øyvind

From: Brendan Moran <Brendan.Moran@arm.com> 
Sent: Monday, June 8, 2020 17:24
To: Dick Brooks <dick@reliableenergyanalytics.com>
Cc: Rønningstad, Øyvind <Oyvind.Ronningstad@nordicsemi.no>no>; suit <suit@ietf.org>
Subject: Re: [Suit] Valid but partial updates (possible threat)

There are several possible resolutions to this concern. I think that any realistic deployment should address more than one of them. The two most important mitigation are: 


1. A key that is used to verify root manifests should be marked as such in the device. Verification of a root manifest should fail if it is signed by a key that is not marked for verifying root manifests.


2. Any valid tree of manifests must contain a specification for every element of an interdependent set of components. Independent groups of components may be specified with separate trees. This can be checked at dependency-resolution and system-validation time.

I’ve had some text about this in the past, but I don’t believe it is in the manifest specification. I think this detail should be in Section 6.2: Required Checks.

Please let me know what you think?

Best Regards,
Brendan


On 8 Jun 2020, at 15:15, Dick Brooks <mailto:dick@reliableenergyanalytics.com> wrote:

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! T
http://www.reliableenergyanalytics.com
Email: mailto:dick@reliableenergyanalytics.com
Tel: +1 978-696-1788

-----Original Message-----
From: Suit <mailto:suit-bounces@ietf.org> On Behalf Of Rønningstad, Øyvind
Sent: Monday, June 08, 2020 7:37 AM
To: mailto: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
mailto:Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit

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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.