IETF Logo Mail Archive

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

David Brown <david.brown@linaro.org> Fri, 15 February 2019 19:02 UTC

Return-Path: <david.brown@linaro.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 7B7501271FF for <suit@ietfa.amsl.com>; Fri, 15 Feb 2019 11:02:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=linaro.org
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 Lxz-VRSL3XIX for <suit@ietfa.amsl.com>; Fri, 15 Feb 2019 11:02:56 -0800 (PST)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 E656212F1A2 for <suit@ietf.org>; Fri, 15 Feb 2019 11:02:53 -0800 (PST)
Received: by mail-qk1-x734.google.com with SMTP id m9so6353538qkl.4 for <suit@ietf.org>; Fri, 15 Feb 2019 11:02:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=smaxr7vmlMLTt6nR/CUeJLjjN90j+54ugtY2EQuxm9Y=; b=pDjkhilIaSdmmn4w6lNyMbJ6dV9SOXbcEXwMy5aqrvg/BHseT2yh4kqvSx5bVPNBe2 JWksWfwwIgmI1B/h37ZXNlQSeT1UC5TnSWWvLrJ85dHxea8HqgZ5ir0YzvDH1SN8yF8v 7XjFUFqAsfG2Hep3huxE1zzNvS8qa4zA7xwBylZCJIAcV/KUU+88E4BSrIgPHU9ltVqT UOHdMQtae1qFmFxwPyWTS0ENwpzOkSqZZ/CDMsKRxZUFgWbvYzgHrRMQ3ZLf101scBC5 JBZW3UBl43gLHDFEXCKD1CKhhtzUe9Wq0tXYw5/19UFdwZxB77Z68mcd4yBvRLROCNjH Tr9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=smaxr7vmlMLTt6nR/CUeJLjjN90j+54ugtY2EQuxm9Y=; b=fJj9OeF6t2xuH3DsgjhVqWFTJNPS3gLp49E9F4Br+7aIR1TswmcR0pq9RJhbDYK778 ToYS/qzNTNke6maGsmBToe+yxZIRO9ZgD7NoWpcav0ApTTnFOUrgtzoeEyHrsCbWojdQ 3gcxDFY66Vlbedv18QfQMmjGC8M1SZfu0hH23jAOZmNVAZFmodAkhC6fmIRkEBe6z7kg r2ZeaLkb+rrFzHLiYQ9DbUaxDGn7wH6PW4I/yZsB1nTTOjDn6qBgSMjXHFrLDdGh+WSV 8GnAbdSi/B/PujYLI55liWmjsxE0HPvdqlMUdd57fTMc7U0T334FnBqHDB/I+Fu8XSvr qZsw==
X-Gm-Message-State: AHQUAuYt5hGl2WA9icYraVF3k6l4o1/Q1i77+bgxkhYfBc1UYSqBHKse qqfzrKJjrknEFdPKDFo5tPq7iA==
X-Google-Smtp-Source: AHgI3IbIZArDtVLysjUF2are9QdY/GrIRCkK929Tzp877wji2Wn7CA9D8EoaNqA+OzjN3Ustjn+M3A==
X-Received: by 2002:a37:d649:: with SMTP id t70mr8281873qki.44.1550257372573; Fri, 15 Feb 2019 11:02:52 -0800 (PST)
Received: from davidb.org (cn-co-b07400e8c3-142422-1.tingfiber.com. [64.98.48.55]) by smtp.gmail.com with ESMTPSA id d14sm3504118qkb.88.2019.02.15.11.02.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Feb 2019 11:02:51 -0800 (PST)
Date: Fri, 15 Feb 2019 12:02:49 -0700
From: David Brown <david.brown@linaro.org>
To: Brendan Moran <Brendan.Moran@arm.com>
Cc: "Kvamtrø, Frank Audun" <frank.kvamtro@nordicsemi.no>, Amyas Phillips <amyas@ambotec.org>, "hannes.tschofenig@gmx.net" <hannes.tschofenig@gmx.net>, "suit@ietf.org" <suit@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Martin Pagel <Martin.Pagel@microsoft.com>
Message-ID: <20190215190249.GA17651@davidb.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
In-Reply-To: <0E2EB7D0-84D7-4000-BCAD-3C012B1D2718@arm.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/HBBEWbuiF2evgUe4qU-jTGqraGs>
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: Fri, 15 Feb 2019 19:02:59 -0000

On Tue, Feb 12, 2019 at 08:52:11PM +0000, Brendan Moran wrote:

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

What MCUboot currently does (with its own manifest, not SUIT):

  The device downloads the encrypted payload and places it in the
  upgrade area of flash, and then triggers a reset.

  The bootloader begins to exchange the primary and upgrade slots,
  decrypting the data as it is moved from upgrade to primary, and
  encrypting it as it is moved from primary to upgrade.  If the backup
  image is not needed, the old image in primary is simply discarded.

The idea is that the primary image often exists in internal flash, and
the device executes directly out of it.  The upgrade image may exist
in an external flash device, and therefore should always contain an
encrypted image.

Some devices will have sufficient RAM to execute out of RAM, but
support for this is on a future roadmap for MCUboot.

David

v2.23.0 | Report a Bug | By Email