Re: [Suit] Introducing draft-moran-suit-manifest-04

David Brown <> Fri, 22 March 2019 17:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBC151313A5 for <>; Fri, 22 Mar 2019 10:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v3YgmyVt82S6 for <>; Fri, 22 Mar 2019 10:44:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00EFB13139B for <>; Fri, 22 Mar 2019 10:44:43 -0700 (PDT)
Received: by with SMTP id w20so1707443qka.7 for <>; Fri, 22 Mar 2019 10:44:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=RKH8v/ectdBCSbfqubAdPmzhHVNc6L3xyjmbDulQdB0=; b=ezXcAtihlzlmRU9yyUifa54gwExN4g/sBfsdERGinoGlgOk6zaIoMkjW6Ar6LR/jXr Ghfdh6QE77vvW1lCL6Sg/1Rht8lHPFwbkdrxoZCwKj6+bhE4F+xitgHL9yjg7QLxHdxM AEp70+wL4HG7ltDEGHg0jPR4lKSMn+kZxf2JpuqkUv4wSwbd2grr/yq78aTPCxI4/NuL gXwPMfYsMHB/R4GN4OXq3OBQWT8arQS/mYyWFPF69euaEtfegEEZfoDAX3imf1BAU9s3 J0dvAMTVDqUCoDAZvxhyUUCG9IrermukHLpF8ohDEgQed6H1MjFWt3Lryjmkn/c7vcAf 7HVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=RKH8v/ectdBCSbfqubAdPmzhHVNc6L3xyjmbDulQdB0=; b=e9TxBICV6wPIvmbtSmQILLWNcIw0EHK/TmOBGi1WRBpl5Tvcd6me4eNPLmOCHDTY8s KnKSTH5lw7IwES6PU+D8kfiaf2kVd++nGLfbq016zmIUQJz/l3DkkzRLni9ed9NyeE7i J6Zkzc4BiLzJB3YpeIxk5VrLWFzngtwIZ8UPaXq+VhJ35ycI8vUZUhiz5uU32j17BdD0 Nptl+fekA7YxmWL4nAETKl9dEpW2yZAq/haxm9rui4D4/JUv9erHvjTj38WVxG2NXxrZ qP7nHqFTE6ThvrCH4tS35K/rV1FucFQIdWeziKKAgw3CkC2vBXShQP4xCh8sjA4vpZ+4 s9Ww==
X-Gm-Message-State: APjAAAV9GPVWq/M3uj/GIVmx+xw+iV4HLigfU0vQ2E25H9tYA77ZxhtJ KXd2pe3mj0+7gEJYcs7/bgX54A==
X-Google-Smtp-Source: APXvYqzf7gpwd4gxbk15fy93YS64mc1XHI0EdFijtaH+0evHjqe1nVgeeDTs2QvPc8wZm6UEfkTHLQ==
X-Received: by 2002:a37:e315:: with SMTP id y21mr8843393qki.233.1553276682904; Fri, 22 Mar 2019 10:44:42 -0700 (PDT)
Received: from ( []) by with ESMTPSA id l129sm4716846qkb.44.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Mar 2019 10:44:42 -0700 (PDT)
Date: Fri, 22 Mar 2019 11:44:39 -0600
From: David Brown <>
To: Brendan Moran <>
Cc: "" <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Mar 2019 17:44:46 -0000

In regards to encrypting images.  I wanted to explain a little how
this works in MCUboot.

The basic process is similar to the swap described in:

However, the image in the secondary slot is always encrypted, and the
image in the primary slot is always unencrypted.  This makes an
assumption that the primary slot is more difficult to access (usually
an internal device), and that the secondary slot lives in an external

The manifest is not changed when the image is moved between the slots
(and decrypted/encrypted).  Right now this logic is hard-coded into
MCUboot.  It would certainly be possible to keep it hard-coded, and
have the manifest describe both the encrypted and unencrypted payload
that MCUboot would then just know which one to use.

Note also that the primary image is re-encrypted when the swap
happens.  It uses the same IV for the encryption, which bothers me,
since it makes it slightly vulnerable to the plaintext being modified
(although if the plain text can be modified, many other attacks are

Any other thoughts on how to handle this?  BTW, this is not really
talking about encrypted payloads that are downloaded and decrypted
before being written to flash.  This is where there are two images in
flash, the executable one being unencrypted.