Re: [Suit] Improvements to draft-moran-suit-manifest-03

Martin Pagel <Martin.Pagel@microsoft.com> Wed, 13 February 2019 21:31 UTC

Return-Path: <Martin.Pagel@microsoft.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 13BC7128766 for <suit@ietfa.amsl.com>; Wed, 13 Feb 2019 13:31:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, 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=microsoft.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 iyr_1NdWzIi2 for <suit@ietfa.amsl.com>; Wed, 13 Feb 2019 13:31:41 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780123.outbound.protection.outlook.com [40.107.78.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE1B12F295 for <suit@ietf.org>; Wed, 13 Feb 2019 13:31:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a4C17PWLuOMB4YH5euXL5aE94QVWkgmsMDJHiKP6Iag=; b=IVv/dxGRbbU0tri5l3pm6QkXokeiNMsEG9+9GL0VG+VE/GnpWcPPP6pxuq37umydMa3m22rwab3orEcWXwJJFQxzych7qtYGQPw4UttX6vLhuR2B5aUPfjkDKdSZ04KAhk2A+Af/YaR2mVMS5NUvIj06JLO6IBXHdYZUJbE5ZHA=
Received: from BYAPR21MB1317.namprd21.prod.outlook.com (20.179.60.199) by BYAPR21MB1287.namprd21.prod.outlook.com (20.179.58.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.4; Wed, 13 Feb 2019 21:31:39 +0000
Received: from BYAPR21MB1317.namprd21.prod.outlook.com ([fe80::50ac:a450:32d1:a3ba]) by BYAPR21MB1317.namprd21.prod.outlook.com ([fe80::50ac:a450:32d1:a3ba%6]) with mapi id 15.20.1622.006; Wed, 13 Feb 2019 21:31:39 +0000
From: Martin Pagel <Martin.Pagel@microsoft.com>
To: "Kvamtrø, Frank Audun" <frank.kvamtro@nordicsemi.no>, Brendan Moran <Brendan.Moran@arm.com>, Amyas Phillips <amyas@ambotec.org>
CC: "suit@ietf.org" <suit@ietf.org>, "hannes.tschofenig@gmx.net" <hannes.tschofenig@gmx.net>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, "Rønningstad, Øyvind" <Oyvind.Ronningstad@nordicsemi.no>
Thread-Topic: [Suit] Improvements to draft-moran-suit-manifest-03
Thread-Index: AQHUuWi8UixHuaseU0GRJA2HOUI10qXao+oAgAADpiCAAH1vwIAA/a0AgAAWTVCAAH3bgIAAxlyAgADSIDA=
Date: Wed, 13 Feb 2019 21:31:38 +0000
Message-ID: <BYAPR21MB13176A3708BFD3044B6F95F49D660@BYAPR21MB1317.namprd21.prod.outlook.com>
References: <78FF2A20-1AF3-425F-B4BB-6F520E85DE46@arm.com> <CAO6t1cj7qDNA3VnkbxiPQEm6P+o=mQALYVr+JMTvVXnvV_4vNQ@mail.gmail.com> <HE1PR05MB3228C1819381A6B0630AF6DB88640@HE1PR05MB3228.eurprd05.prod.outlook.com> <BYAPR21MB1317B2E9FA61E8374C384B0A9D640@BYAPR21MB1317.namprd21.prod.outlook.com> <CAO6t1ciQd7kUq=kVGr0xsv3ngOYNm=T2FFoyf=Aq9qmg57=fpw@mail.gmail.com> <AM6PR05MB56398DC31C9EB0582AF9E30BFC650@AM6PR05MB5639.eurprd05.prod.outlook.com> <0E2EB7D0-84D7-4000-BCAD-3C012B1D2718@arm.com> <AM6PR05MB5639FC0FE54E5EB19ABDF3E8FC660@AM6PR05MB5639.eurprd05.prod.outlook.com>
In-Reply-To: <AM6PR05MB5639FC0FE54E5EB19ABDF3E8FC660@AM6PR05MB5639.eurprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mapagel@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-02-13T21:31:36.9905793Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=250f157a-16f1-4290-8cad-c7d359bd3202; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
x-originating-ip: [2001:4898:80e8:a:f69e:f49b:19ce:1b28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c1841267-70f2-4b34-ce54-08d691faa393
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7193020); SRVR:BYAPR21MB1287;
x-ms-traffictypediagnostic: BYAPR21MB1287:
x-ms-exchange-purlcount: 1
x-microsoft-exchange-diagnostics: 1;BYAPR21MB1287;23:3Ue/w5cSVuB/P3ibxLN/ZcVoJzI5ALE1M+ilCSbo1Ss9wZ11urgxsre/wISsAJZ5G9kcT3ibeB7QsuvRlZWvcug04+oa9BvUN1F0Q9nXGB8RQxNZvV7od2PSVUPnPqVpFP1yo8zWw3yJ5MD3vRnmGK0XbiAI55uZdNGMKTJy5ka/uQEOIgILogqXU/sXmL8soXPMnlDxHMLU7AgfgnS0kgeJ70KIrMu0UBmJEAxe7+NKIvPAHh+bENJ5K7Xyl5JvkUBTr3ZdWsU97X7Jla5tRlh9i1uyt8HBmJksF9F/pgzuMCl5eue4pvlnvmNKrvWDERKhVgJi8bmg3o7Kkb1RyOpJsppNib/lhqUPbFQwVxOrz3BwT7oIjsInQciNeYKY4rwM9i6WcPg0Ig5y7an5SreKhTvMFI7s6T70gmAwlWJvIhvL85/qEtnhvAOjINh6KVpOOXceK2SrO4YwvgjFSlT6m+ep0gnBmIIgTaQ5u6UYqgM+iXIjBmP3UaFN0Zvz6E+E/gL9xebu9fSMdg7mXaKarwAuh641rAlwl1dbhouDfxuawvphU1hJ4IVv4mEJm1yVSZ+Ns5N5/hHIfP/P/0A5cqzKaTF99qSJFpIMvN2lhoux/gH+EMLHUNU+8WY8Pyr8X6cHlRlySbw2s31WdsKuMz8bUWJXaKVYk+fY5kOnIgVS2bGYjPsddhXbeAVrTjscYiuR96NRhMIyAz68wP489DM1Jo7TzJRMCPQVm3yreb0Jj0b1/uL56CzWLiQnLs40F7jOnFtO0r0Q6U9dGQ7cD2PN+oBks8jQ/ZLVhkiVt3DcHnUSjIA8RzLchUYqQYOMON9Sy+Oub3oguGmvxajJm9xhL00u5luYk9c8X5KywhEkFyRKNzOjen3+UFcjzK/dMSs3P/kQ5i/ACAJZGj9fj2M5nOBtrqc8943G/+XKDdh8fka1OHCznnN0KrHwP/l1wa+eLgLgTgCEZ90kdOFgFXvjIFvg4+x3rWvwFlaVAe803JI94Zg81bAGPots9Tbvfm9yGvvENC9d6rcsGwkhXU4P+iWrOGDlgxjBlAJnl5PxN/6Vm3Nyj+QnkIvWhThij4RpTAOPYicXY06Yna6sTte+JHFAY2cUONrJIpUOlLO72A9azZVA3FE7AsFNRvxBigERhXkbVZ7+IZ/dBoE56sUlM5d485tRSK9/jtEk3If+N5AtfLfKygIGBL3zEqUuRk7PZt5k7FBeULkotF+EMVdVYnSeLbFYmRMsAAe7uYqMnHna0oKWcqIvwVX8hgSKmq0Dzlb7+NXS/L51h5QpngflljaYKHOmS3CK+ij/Dj3nOAHM08sIt1/o0pRwxzWYQKHdZbEhmJnvBcdM4oMsOTgmr8zF+L6zCziEdVKlZUAcVL2JYvAsSskX4Qz7nCcgCJ55a8a0IaloR+m9ABrvYQftWTcuSXW+uSbhUcyfFG9GjDaKkrTEQ4ym+iXi8iPT+o2Z99BvnyeYKz7QeoGjZRRRzrCm5p/dJY1vx73szwrihNXPRDLLPNiIVq2s4er+rolKXSTRUTI2FIPz3p22ZGZJxWpn2lFEuCW6CJaMC9p+/Rhjl3ATLnhyFn22hLH2zcdzjKvv3z5t8ONSc/Qzii2nH10Ir3Or12Uq8gTCA6pD4r8PfFuoRouBIV1g4XccMRuEpwJk62ujr5vYL89IkIaEedG6cil+YL7K5+k=
x-microsoft-antispam-prvs: <BYAPR21MB12876216119380AC22C023B39D660@BYAPR21MB1287.namprd21.prod.outlook.com>
x-forefront-prvs: 094700CA91
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(376002)(396003)(136003)(85644002)(189003)(199004)(51444003)(40434004)(6436002)(86612001)(4326008)(14454004)(25786009)(5070765005)(68736007)(74316002)(7736002)(105586002)(22452003)(55016002)(66574012)(486006)(106356001)(236005)(966005)(53946003)(6306002)(54896002)(9686003)(86362001)(97736004)(72206003)(6246003)(7696005)(8676002)(76176011)(99286004)(606006)(10290500003)(6346003)(46003)(8936002)(5024004)(81156014)(81166006)(14444005)(102836004)(33656002)(53546011)(6506007)(54906003)(53936002)(11346002)(110136005)(71200400001)(446003)(229853002)(256004)(478600001)(8990500004)(10090500001)(476003)(30864003)(2906002)(316002)(6116002)(790700001)(93886005)(186003)(71190400001)(290074003)(50840200001)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR21MB1287; H:BYAPR21MB1317.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Martin.Pagel@microsoft.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: tbE00XCFbwFtD/MWDoflL/X1B6IZJaDErshpVitGi1a7iwFzWjmQWeqKuoPJBcmYcj6iR0Tt31emo2VtX5D3k2nI1Ti/j7+solMaMv3Hm5v0YaaXWipE7HJBPiwi9XEgmCW4fa4CSKPKTnsUPJIrzme//6N60U+jTb+irJllHaXM9SVW17VA+ImFh6AdNhGIGMsW+3zOi9uXp+ZZgyB2ZYzWr2j7hBBs/QzsdXBV1Fj8xwew3M/oDsKjWN+8+DayHBKqm1OYTzP1ndwEklrAqd+Kua2jDvXHDbPbgjd5S1Q9bWSJ80kZmal/Ykvy65Qcerphe5Q5zVqydYyoFY7UqeJjQ9glayFtv9Qkyd6wYIMlfa7Bi0b14qb6j8MxQzu+yJtOvrogNrUN03ISTv83Lar5HGBOdtr+/L56OiOo98M=
Content-Type: multipart/alternative; boundary="_000_BYAPR21MB13176A3708BFD3044B6F95F49D660BYAPR21MB1317namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c1841267-70f2-4b34-ce54-08d691faa393
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2019 21:31:39.0463 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR21MB1287
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/0V_jHX2j54DlouH3G9yvKX-Tv0k>
Subject: Re: [Suit] Improvements to draft-moran-suit-manifest-03
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: Wed, 13 Feb 2019 21:31:47 -0000

Frank,
I agree that a single signed manifest for installation and boot would be desirable and signature verification should be mandatory. Another reason to keep the manifest as compact as possible.
It would require that all payloads would need to be signed such that the payload has been installed, meaning after decryption, unpacking, or installation processing (for formats such as elf, s-record…) which I think is fine.
Yes, it would not allow signature verification BEFORE installations and therefore may require a rollback if the signature doesn’t verify, but I think that’s a reasonable tradeoff.
Best
Martin

From: Kvamtrø, Frank Audun <frank.kvamtro@nordicsemi.no>
Sent: Wednesday, February 13, 2019 5:38 AM
To: Brendan Moran <Brendan.Moran@arm.com>; Amyas Phillips <amyas@ambotec.org>
Cc: Martin Pagel <Martin.Pagel@microsoft.com>; suit@ietf.org; hannes.tschofenig@gmx.net; Henk Birkholz <henk.birkholz@sit.fraunhofer.de>; Rønningstad, Øyvind <Oyvind.Ronningstad@nordicsemi.no>
Subject: RE: [Suit] Improvements to draft-moran-suit-manifest-03

This comment is only on the potential threat vectors that may arise from shedding information during installation.

Main point: We don’t want to make it easy to misunderstand the standard, leading to implementations with easily identifiable security holes.

Standards and specifications on Root of Trust and secure boot (e.g. GlobalPlatform and ARM PSA) mention different means of validation during boot. One concept is MAC rekeying and another is digest verification and reporting using a TPM module. The signature around a firmware upgrade instruction is very beneficial for maintaining trust both in context of installation and boot given that it is based on the Root of Trust Public Key. Transition of trust from a signed upgrade instruction and a subsequent trust in boot should be explicit and not open for interpretations. If the boot procedure is no longer based on a Root of Trust public key, there is an inherent reduction in trust that must be visible to the implementers.

It is very beneficial if this there exists a mutual trust between the author (s) of a signed manifest and the implementation of the bootloader, ensuring that a reduction in trust can’t be dictated by one party only.

Here are some alternatives to try to enable a mutual trust:

  *   The main manifest is always stored and you must check this signature on all subsequent boots.
  *   Enable verifiable requirements for what the boot material is expected to contain (e.g. boot *must* use a signature check, boot *must* decrypt, boot *must* be based on a rekeyed MAC etc.). These requirement are expected to be verifiable before installation to prevent removing necessary security in an installation procedure. Failure to provide the necessary level of security after installation will be rejected.

With regards to boot-requirements, this can possibly be handled in an opaque way only reliant that the fact that a boot signature is present (or not).

One way to be explicit about the transitions of trust is to distinguish between an upgrade manifest and a boot manifest. Having a boot manifest may solve issues with regards to multi-component heterogenous systems. In such systems it may be impossible to utilize explicit boot-manifests, which can be skipped. If the external chip boot manifest is not present, then the booting of said external chip is purposely outside the scope of the SUIT. The same goes for systems without security restrictions during boot (e.g. on severely restricted devices). You can explicitly just skip the boot manifest altogether, making the boot procedure outside of the scope of the SUIT both in terms of functionality and trust.

Regards
Frank Audun Kvamtrø

From: Brendan Moran <Brendan.Moran@arm.com<mailto:Brendan.Moran@arm.com>>
Sent: 12. februar 2019 21:52
To: Kvamtrø, Frank Audun <frank.kvamtro@nordicsemi.no<mailto:frank.kvamtro@nordicsemi.no>>; Amyas Phillips <amyas@ambotec.org<mailto:amyas@ambotec.org>>
Cc: Martin Pagel <Martin.Pagel@microsoft.com<mailto:Martin.Pagel@microsoft.com>>; suit@ietf.org<mailto:suit@ietf.org>; hannes.tschofenig@gmx.net<mailto:hannes.tschofenig@gmx.net>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>>
Subject: Re: [Suit] Improvements to draft-moran-suit-manifest-03

Hi Amyas,

Having spoken to some of Arm’s cryptographers, they suggest that validation should take place prior to decryption. They explained that this is because it prevents decrypted, inauthentic code from ever being present on the recipient system. However, in many of the use-cases targeted by SUIT, the overhead of writing an image to flash, then decrypting it in-place is not only too high, it is also too risky in robustness to power failure. Therefore, there are use cases where we must sacrifice this assurance for other properties (such as robustness to power failure and reduced flash cycles).

Looking at the use case you have described, there are a few possibilities:

  1.  The device downloads & decrypts into flash. It verifies the flash when complete. It executes from flash. This is explicitly covered by draft-moran-suit-manifest-03.
  2.  The device downloads & decrypts the payload, re-encrypting it with a local key before storing it to external flash. The device loads the external image into RAM, decrypting on the fly, and runs from RAM. This is implicitly covered by draft-moran-suit-manifest-03
  3.  The device downloads the payload into flash. The device loads the external image into RAM, decrypting on the fly, and runs from RAM. This is not covered by draft-moran-suit-manifest-03.

Draft-moran-suit-manifest-03 assumes that the payload digest is the digest of the plaintext. The intent was that a digest of the cipher text could be specified in a future draft once we got most of the draft right. However, this use case ties in neatly with a similar one surrounding decompressing from flash into a run-from-RAM device, so we’ll put some more work into this part of the specification and try to get that ready for draft-moran-suit-manifest-04.

Hi Frank,
I’ve put some comments inline below.

Best Regards,
Brendan


On 12 Feb 2019, at 14:43, Kvamtrø, Frank Audun <frank.kvamtro@nordicsemi.no<mailto:frank.kvamtro@nordicsemi.no>> wrote:

I’m happy you found the post-conditions, but as you state, the bootloader needs extra information to know the correct behavior…

The usage of transformative steps (also named as processes)  in SUIT has been touched upon by Brendan and others in previous discussions. I am under the assumption that this is currently being worked on, and that this question is of great importance with regards to the complexity of a parser used in context of a boot compared to what is needed for a full firmware upgrade. You state that post-install checks and cleanup is out of the scope of SUIT and right now that might be somewhat true, but it doesn’t need to be. The signer of a firmware upgrade package is assumed to have access to data to qualify the new FW to be run on the device, and it makes a lot of sense to utilize this knowledge on boots after the install.

You’re absolutely right: we are working on the use of steps. In previous documents, we used processors for this, They were very flexible in terms of what they could describe, however they were quite limited in terms of how they were used, they were difficult to parse and use in a constrained environment, and they encoded unnecessary information. The new approach as described in the first message of this thread reduces the complexity, but we’re still left with the question of how to distinguish between operations that occur in the update process and in the boot process.

I think we have some of the building blocks, for instance severable fields, but supporting this in draft-moran-suit-manifest-03 would require adding a new section for directives, and I don’t like the complexity that this adds. I think that changing how the sections are divided might get us headed in the right direction. It might also help with making the parsing of the manifest more consistent, which will make it easier to implement and simpler to code.

Storing a full manifest after an upgrade might be a good guideline, but it may also infer a complexity in the parsed material if it needs to be used on each boot. I personally hope that SUIT comes up with a transitive shedding of “unnecessary” complexity during an installation of a new FW upgrade. This could mean a simplified but post-installation metadata format that is stored on the device.  Having such a metadata format to store the explicit state would mean that an immutable first stage bootloader is simpler to write. It doesn’t need to remove  the possibility to e.g. decrypt during boot and/or facilitating boot validation.

We have already partially dealt with this, by dividing the manifest into sections, which can be discarded. I think we should rearrange these sections slightly, but we are still working on the details of the rearrangement.

 Transformative shedding of data should be written in a way that the authors of a FW upgrade has the capability to select to either decrypt during installation or decrypt on every boot. The same goes for the capability to selectively decide if you want to verify a signature during each boot vs measuring digests. Security wise it is better that such a mechanism is written to be explicit about the post-installed state, rather than relying on automatic behavior assumed by the implementer. It might be convenient to store a full manifest for rollback capabilities, but I can’t recommend disregarding  the signature as an automatic behavior after install.

Do you think that the manifest should carry the information used to decide whether the manifest is verified at boot? That sounds like a pretty big threat vector to me.

 I think that Root of Trust during a boot is valid in context of SUIT scope, as this is core to secure architecture requirements. It is important that SUIT is specified in a way that you don’t break any requirements. Utilizing the post-conditions in an original signed firmware upgrade manifest might give you the ability to selectively do extra operations during boot, but it requires more logic/complexity on a lower level in the boot. Transitively reaching an explicit post-installation state with only the necessary instructions for what to do on the next times you boot removes some of that logic/complexity. This post-installation material can of course have its own signature instead of relying on the signature of the original manifest to ensure that all subsequent boots provide the same level of trust as the initial manifest.

This is exactly what we have in mind. Details will follow once I have a chance to fully document them.

I do believe SUIT has inherited an assumption of trusted boot, or at least it has a vested interest in facilitating this as part of the functionality

I agree. I don’t think that SUIT needs to mandate that SUIT is used for trusted boot, but I think it needs to be an option.


Regards
Frank Audun Kvamtrø

From: Suit <suit-bounces@ietf.org<mailto:suit-bounces@ietf.org>> On Behalf Of Amyas Phillips
Sent: 12. februar 2019 13:02
To: Martin Pagel <Martin.Pagel@microsoft.com<mailto:Martin.Pagel@microsoft.com>>
Cc: suit@ietf.org<mailto:suit@ietf.org>; Brendan Moran <Brendan.Moran@arm.com<mailto:Brendan.Moran@arm.com>>; Amyas Phillips <amyas@ambotec.org<mailto:amyas@ambotec.org>>; hannes.tschofenig@gmx.net<mailto:hannes.tschofenig@gmx.net>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>>
Subject: Re: [Suit] Improvements to draft-moran-suit-manifest-03

Øyvind your approach of including hashes of both the plaintext and encrypted image in the manifest sounds pretty good. Your approach decrypts once, validates on every start, keeps the manifest as the sole authorization/authentication of the image, and only requires the bootloader to know it is validating the postcondition not the hash of the encrypted image. Your solution isn't what I meant in my option 2 at all, it's another alternative altogether, "option 7" maybe. By using the postconditions your solution brings this use case back into scope of SUIT. I didn't think of using the postconditions. This seems a very natural application of postconditions - except that draft-moran-suit-manifest-03 expects postcponditions to be validated only once, after installation. If we accept this as a common use case then perhaps Brendan could give a nod to it in the postconditions section, acknowledging potential repeated validation of the postconditions by a trusted boot process.

David and Martin, your comments made me think harder about bootloaders' use for a manifest.  SUIT's problem is the integral and confidential distribution of software assets, in a way that can be adopted consistently across a wide spectrum of device constraints and application topologies. If a bootloader is the endpoint of a SUIT distribution, then at image installation time it needs to validate all the conditions in the manifest, and do any decryption or other processing required, as SUIT expects. Anything after installation other than triggering post-install checks and cleanup is out of scope for SUIT.  But we have this common scenario where the bootloader is also responsible for trusted boot. Trusted boot isn't part of SUIT's scope (IMO) but installing a signature for validation by a trusted boot process is arguably within scope of the use cases for SUIT.  What's our recommendation for how to do it?  Is there even a generally recommendable solution?

We do have this manifest handy with a signature already in it, so we could use that, especially if the bootloader is anyway validating manifests at installation time. On each start (as opposed to each installation) the bootloader only needs to validate the signature of the manifest and the hash over the image in it, and get the image version to compare with any new candidates. After installation, the rest of the manifest is redundant unless you're planning to reinstall, eg. for a rollback facility, or to do a fresh installation on every boot. As well as enabling re-installs, keeping the manifest around has the advantage that the metadata in there is already signed using a key whose certificate the device already has safely squirrelled away. Taking metadata out means finding other ways to protect it. So maybe keeping manifests around isn't required, but we can generally recommend it.

Then we get back to the question of what to do if the image is encrypted and we don't want to decrypt it on every start, but we do want to validate it. Recommending additional signing and/or encryption around SUIT to support this use case feels like we probably haven't solved the problem enough. Can we do it inside SUIT? Øyvind's solution seems good to me.  The only downside is that any process using the payload has to take a guess about whether it is currently encrypted or not.  Øyvind thinks it will be obvious. I agree: if encryption is in use the image will be encrypted everywhere except on the device itself, where some process will decrypt it and store is somewhere where a downstream process (eg a bootloader) will be expecting to find a decrypted image.

So in summary, for trusted boot scenarios where the image is to be sent encrypted to the device, could we recommend putting hashes of both the encrypted and unencrypted payloads in the manifest so that the manifest can be used to validate the decrypted image as boot time, as Øyvind has proposed?

Brendan this is really no more than a suggestion to you, it would be interesting to know your thoughts.

Thanks everyone
Amyas




On Mon, 11 Feb 2019 at 20:59, Martin Pagel <Martin.Pagel@microsoft.com<mailto:Martin.Pagel@microsoft.com>> wrote:
Option 5 sounds dangerous: if the manifest signature is not verified during boot, an attacker might do a rollback attack: modify the manifest to use an old/compromised image, install such image and from it.
Øyvind, I do like the boot loader only having to verify the installed image (no decrypt), meaning option 2…

Martin

From: Suit <suit-bounces@ietf.org<mailto:suit-bounces@ietf.org>> On Behalf Of Rønningstad, Øyvind
Sent: Monday, February 11, 2019 6:14 AM
To: Amyas Phillips <amyas@ambotec.org<mailto:amyas@ambotec.org>>
Cc: hannes.tschofenig@gmx.net<mailto:hannes.tschofenig@gmx.net>; suit@ietf.org<mailto:suit@ietf.org>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>>; Brendan Moran <Brendan.Moran@arm.com<mailto:Brendan.Moran@arm.com>>
Subject: Re: [Suit] Improvements to draft-moran-suit-manifest-03

Hi Amyas.

Brendan probably has his own thoughts, but here is how I envision this being solved. The upgrade procedure will go something like this:


  1.  The manifest specifies that the payload is encrypted.
  2.  Upon reception, the payload is processed (decrypted, decompressed etc) before being stored.
  3.  The manifest is permanently stored for use during boot validation.
  4.  The bootloader will, on each boot, check the manifest signature, and then validate the postConditions (which contain the hash of the unencrypted firmware image).

The bootloader needs to be a little smart, by which I mean that it will correctly infer on each boot whether it should treat the manifest as an incoming update or as an existing app. This can be achieved in a number of ways: e.g. with some sort of flag stored with the manifest, or by moving the manifest from an “upgrade” spot to a “boot” spot, or by checking the postConditions first, and if they fail, treat the manifest as an upgrade.

This might be similar to your option 2, but I disagree that it is any more a “wrapper around SUIT” that what is needed for upgrades. For upgrades as well, there must be a device-specific way to tag data as being manifests and payloads in various stages of processing.

Of course, anyone is free to do option 5. I.e. use SUIT for upgrades but not for booting.

Best regards,
Øyvind Rønningstad

From: Suit <suit-bounces@ietf.org<mailto:suit-bounces@ietf.org>> On Behalf Of Amyas Phillips
Sent: Monday, February 11, 2019 14:12
To: Brendan Moran <Brendan.Moran@arm.com<mailto:Brendan.Moran@arm.com>>
Cc: hannes.tschofenig@gmx.net<mailto:hannes.tschofenig@gmx.net>; suit@ietf.org<mailto:suit@ietf.org>; Henk Birkholz <henk.birkholz@sit.fraunhofer.de<mailto:henk.birkholz@sit.fraunhofer.de>>
Subject: Re: [Suit] Improvements to draft-moran-suit-manifest-03

I have another use case for you Brendan:

A project wants to send its firmware images encrypted, and wants a trusted boot process.

Faced with this, my first thought might be that I'm going to have the bootloader validate the manifest.

What should we recommend?

I can see lots of ways of doing it:
1. Encrypt the firmware image, then create the manifest. Store the encrypted firmware on the target device and on each start have the bootloader validate the manifest and encrypted firmware, before decrypting the firmware into a location from where it can be run. This is the model more-or-less implied in the manifest specification. It works for devices that can afford to decrypt the image to an executable location on each start, e.g. execute-from-RAM devices..
2. Reverse the order of signing and encryption: first create the manifest, then encrypt the firmware image. Have the receiving process on the device decrypt the image and store the decrypt and the manifest in NVRAM for the bootloader to validate. This saves devices from having to decrypt and install the firmware image on each start. Receiving processes can potentially also decrypt images into storage as they arrive, saving on NVRAM. This approach is in effect a wrapper around SUIT.
3. Create a manifest for the bootloader's use and package it up with the firmware. Encrypt this package as a new payload and mint another manifest for the use of the retrieving process.  Have the retrieving process assemble the package, validate it and then decrypt it into the appropriate location for the bootloader.
4. Create a manifest for the bootloader's use. Encrypt the firmware image and create a second manifest for the retrieving process's use, this time including a dependency on the first manifest. Have the retrieving process retrieve, validate, decrypt and install the firmware image. Have it also retrieve and install the first manifest.
5. Relax the requirement for the bootloader to validate a manifest. Maybe it doesn't really need to. I can't see any benefits to having a bootloader validate manifests except that it seems tidier to use manifests for all our validation needs. Instead of that simply sign the firmware image, in whatever way the bootloader expects. Then encrypt the signed object and ship it under a manifest. Have the receiving process validate it and decrypt it into the appropriate location for the bootloader.
6. Rely on channel security for confidentiality. Relying on encrypted channels nets you confidentiality without having to leave space on each device to store encrypted images for validation. This may often be acceptable but is against one of the SUIT design principles as I understand them: channel-independence.   I think SUIT can recognise it as an option but not rely on it for in-scope usecases.

My vote is for option 5.

Many thanks
Amyas Phillips







On Thu, 31 Jan 2019 at 13:27, Brendan Moran <Brendan.Moran@arm.com<mailto:Brendan.Moran@arm.com>> wrote:
Following IETF103, I have been collecting more use cases and user stories to influence the development of the manifest.

Three points have become very clear:

First, the processing tree is too complicated. There are many possible configurations that would never be used. There is plenty of room for error. In reality, the configurations that seem to be usable are all the combinations of these three operations:
* decrypt
* decompress
* unpack (delta, relocate, hex, etc.)

I have yet to find a use-case where these operations do not appear in this order, or where there is another operation that is missing from this list.

That being the case, a processing tree, while very general-purpose is extra overhead that is not needed. With that in mind, I would like to propose changing the payload model back to something more conventional.

The payload-installation-info structure contains information about
* where to store the firmware image (install-component),
* where to retrieve it (uris),
* whether the firmware image is encrypted and with what algorithm (encrypt-info),
* whether a compression algorithm has been applied to the firmware image and what algorithm has been used (compression-algorithm),
* whether the image is a binary diff or requires relocation (unpack), and
* an indication whether these fields may be overridden by an authorized party (allow-override).

Here is a proposed CDDL snippet for draft-moran-suit-manifest-04:

payload-installation-info = {
   install-component => component-identifier,
   ? allow-override => bool,
   ? uris => uri-list,
   ? encrypt-info => COSE_Encrypt0 / COSE_Encrypt,
   ? compression-algorithm => compression-algorithm-ids,
   ? unpack => [
       unpack-algorithm : unpack-algorithm-ids, ; binary diff, or relocation, or binary-to-text algorithm identifier
       ? unpack-arguments : bytes                 ; private config for the unpack algorithm selected
   ]
}

This should be much easier to understand and implement.


The second point is that regen-info is frequently misunderstood and misused... After some discussion with suit participants, it’s become clear that the regen-info block should be represented as a dedicated “digest algorithm” which solves the same problem as the regen-info block currently does. When incorporated with the changes recommended by Jim Schaad, the result is that we replace COSE_Digest with SUIT_Digest and we remove regen-info. Here is a CDDL snippet that represents SUIT_Digest:

SUIT_Digest = [
   digest-algorithm-id: int,
   digest: bytes,
   ? digest-extra-info: bytes
]

Any needed regen-info can then be contained in the digest-extra-info section with an appropriate algorithm identifier.


The third point of clarity is that we need to do some work in making the manifest easier to parse and process in a constrained environment. I don’t have a simple change to enable that, but we’re working on it.

Best Regards,
Brendan
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.
_______________________________________________
Suit mailing list
Suit@ietf.org<mailto:Suit@ietf.org>
https://www..ietf.org/mailman/listinfo/suit<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7CMartin.Pagel%40microsoft.com%7C7f231fc4d15d40bb828b08d691b86eee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636856618678314334&sdata=vJzOtK1q%2BrsAgu4hDOp0FUlK0PdvTRIwWFjBvbVm%2B2o%3D&reserved=0>

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.