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

From: Cody Addison <[email-masked]>
Date: Thu, 7 Feb 2019 16:51:57 -0600

Brendan,

Thanks for the update. I agree with the changes and think they make the spec easier to understand. I have two followup questions:

How do you propose embedding payloads in the manifest? Is the plan to handle this in the payload-installation-info referenced below or do you have another proposal?

When do you plan on releasing manifest version 4? I have a need to deliver a prototype SUIT container in the next few months and would like to base it off version 4.

Brendan Moran writes:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: David Brown <[email-masked]>
Date: Thu, 7 Feb 2019 15:59:39 -0700

On Thu, Feb 07, 2019 at 04:51:57PM -0600, Cody Addison wrote:

>When do you plan on releasing manifest version 4? I have a need to
>deliver a prototype SUIT container in the next few months and would
>like to base it off version 4.

I'd appreciate any insight into this as well.  I have made a prototype
implementation of draft 3 for MCUboot, and having an idea (even a
guess) with scheduling can help with our planning.

Thanks,
David

---

From: Amyas Phillips <[email-masked]>
Date: Mon, 11 Feb 2019 13:11:58 +0000

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 <[email-masked]> wrote:

> Following IETF103, I have been collecting more use cases and user stories
> to influence the development of the manifest.
>
> 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
> 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.
>
> * whether a compression algorithm has been applied to the firmware image
> and what algorithm has been used (compression-algorithm),
>        unpack-algorithm : unpack-algorithm-ids, ; binary diff, or
> relocation, or binary-to-text algorithm identifier
> 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 = [
> 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.

---

From: Rønningstad, Øyvind <[email-masked]>
Date: Mon, 11 Feb 2019 14:14:12 +0000

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 <[email-masked]> On Behalf Of Amyas Phillips
Sent: Monday, February 11, 2019 14:12
To: Brendan Moran <[email-masked]>
Cc: [email-masked]; [email-masked]; Henk Birkholz <[email-masked]>
Subject: Re: [Suit] Improvements to draft-moran-suit-manifest-03

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.

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 <[email-masked]<mailto:[email-masked]>> wrote:
Following IETF103, I have been collecting more use cases and user stories to influence the development of the manifest.

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 = [

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit

---

From: David Brown <[email-masked]>
Date: Mon, 11 Feb 2019 09:35:46 -0700

On Mon, Feb 11, 2019 at 01:11:58PM +0000, Amyas Phillips wrote:

>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
>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. 
>
>My vote is for option 5.

At least in the MCUboot scenario, this won't work.  The bootloader has
to be responsible for actually installing the image.  When using
encrypted images, it also means that it is resposible for decrypting
the image.  It would be possible to have the encryption information
duplicated inside on the image, but that doesn't really fit with how
the manifest represents an encrypted image.

I've already prototyped up support for draft 3's signed manifest in
MCUboot.  I may or may not be also trying to prototype something with
encryption.  (Depends on scheduling decisions).

Without encryption, it is certainly possible to have a separate
signature on the image in a bootloader-specific format.  However, you
now have two separate signatures and have to think about what happens
if one is valid and the other is not.

David

---

From: Martin Pagel <[email-masked]>
Date: Mon, 11 Feb 2019 20:59:08 +0000

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 <[email-masked]> On Behalf Of Rønningstad, Øyvind
Sent: Monday, February 11, 2019 6:14 AM
To: Amyas Phillips <[email-masked]>
Cc: [email-masked]; [email-masked]; Henk Birkholz <[email-masked]>; Brendan Moran <[email-masked]>
Subject: Re: [Suit] Improvements to draft-moran-suit-manifest-03

Hi Amyas.

Best regards,
Øyvind Rønningstad

From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Amyas Phillips
Sent: Monday, February 11, 2019 14:12
To: Brendan Moran <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Suit] Improvements to draft-moran-suit-manifest-03

My vote is for option 5.

Many thanks
Amyas Phillips

SUIT_Digest = [

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
[email-masked]<mailto:[email-masked]>
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%7C4c539f2bad3c4667f0a008d6902b3ad8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636854912699600694&sdata=NoLIL30T6Ea8pJhKnSbDvDdprHcUlEIwDu0en5RtySM%3D&reserved=0>

---

From: Amyas Phillips <[email-masked]>
Date: Tue, 12 Feb 2019 12:01:54 +0000

Ø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 <[email-masked]>
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.
>
> *From:* Suit <[email-masked]> *On Behalf Of * Rønningstad, Øyvind
> *Sent:* Monday, February 11, 2019 6:14 AM
> *To:* Amyas Phillips <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Henk Birkholz <
> [email-masked]>; Brendan Moran <[email-masked]>
> *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:
>
>
>
>    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.
>
>
>
> *From:* Suit <[email-masked]> *On Behalf Of *Amyas Phillips
> *Sent:* Monday, February 11, 2019 14:12
> *To:* Brendan Moran <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Henk Birkholz <
> [email-masked]>
> *Subject:* Re: [Suit] Improvements to draft-moran-suit-manifest-03
>
>
>
> misused.. After some discussion with suit participants, it’s become clear
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cmartin.pagel%40microsoft.com%7C4c539f2bad3c4667f0a008d6902b3ad8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636854912699600694&sdata=NoLIL30T6Ea8pJhKnSbDvDdprHcUlEIwDu0en5RtySM%3D&reserved=0>
>
>

---

From: Kvamtrø, Frank Audun <[email-masked]>
Date: Tue, 12 Feb 2019 14:43:40 +0000

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.

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.

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.

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.

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

Regards
Frank Audun Kvamtrø

From: Suit <[email-masked]> On Behalf Of Amyas Phillips
Sent: 12. februar 2019 13:02
To: Martin Pagel <[email-masked]>
Cc: [email-masked]; Brendan Moran <[email-masked]>; Amyas Phillips <[email-masked]>; [email-masked]; Henk Birkholz <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Rønningstad, Øyvind
Sent: Monday, February 11, 2019 6:14 AM
To: Amyas Phillips <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>; Brendan Moran <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Suit] Improvements to draft-moran-suit-manifest-03

Hi Amyas.

Best regards,
Øyvind Rønningstad

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

My vote is for option 5.

Many thanks
Amyas Phillips

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 = [

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
[email-masked]<mailto:[email-masked]>
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%7C4c539f2bad3c4667f0a008d6902b3ad8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636854912699600694&sdata=NoLIL30T6Ea8pJhKnSbDvDdprHcUlEIwDu0en5RtySM%3D&reserved=0>

---

From: Brendan Moran <[email-masked]>
Date: Tue, 12 Feb 2019 20:52:11 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

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.

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.

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.

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

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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Amyas Phillips
Sent: 12. februar 2019 13:02
To: Martin Pagel <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Brendan Moran <[email-masked]<mailto:[email-masked]>>; Amyas Phillips <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Suit] Improvements to draft-moran-suit-manifest-03

Thanks everyone
Amyas

Martin

Hi Amyas.

Best regards,
Øyvind Rønningstad

My vote is for option 5.

Many thanks
Amyas Phillips

SUIT_Digest = [

Best Regards,
Brendan

---

From: Kvamtrø, Frank Audun <[email-masked]>
Date: Wed, 13 Feb 2019 13:37:40 +0000

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 <[email-masked]>
Sent: 12. februar 2019 21:52
To: Kvamtrø, Frank Audun <[email-masked]>; Amyas Phillips <[email-masked]>
Cc: Martin Pagel <[email-masked]>; [email-masked]; [email-masked]; Henk Birkholz <[email-masked]>
Subject: Re: [Suit] Improvements to draft-moran-suit-manifest-03

Hi Amyas,

Hi Frank,

Best Regards,
Brendan

Regards
Frank Audun Kvamtrø

Thanks everyone
Amyas

Martin

Hi Amyas.

Best regards,
Øyvind Rønningstad

My vote is for option 5.

Many thanks
Amyas Phillips

SUIT_Digest = [

Best Regards,
Brendan

---

From: Martin Pagel <[email-masked]>
Date: Wed, 13 Feb 2019 21:31:38 +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 <[email-masked]>
Sent: Wednesday, February 13, 2019 5:38 AM
To: Brendan Moran <[email-masked]>; Amyas Phillips <[email-masked]>
Cc: Martin Pagel <[email-masked]>; [email-masked]; [email-masked]; Henk Birkholz <[email-masked]>; Rønningstad, Øyvind <[email-masked]>
Subject: RE: [Suit] Improvements to draft-moran-suit-manifest-03

Regards
Frank Audun Kvamtrø

From: Brendan Moran <[email-masked]<mailto:[email-masked]>>
Sent: 12. februar 2019 21:52
To: Kvamtrø, Frank Audun <[email-masked]<mailto:[email-masked]>>; Amyas Phillips <[email-masked]<mailto:[email-masked]>>
Cc: Martin Pagel <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Suit] Improvements to draft-moran-suit-manifest-03

Hi Amyas,

Hi Frank,

Best Regards,
Brendan

Regards
Frank Audun Kvamtrø

Thanks everyone
Amyas

Martin

Hi Amyas.

Best regards,
Øyvind Rønningstad

My vote is for option 5.

Many thanks
Amyas Phillips

SUIT_Digest = [

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
[email-masked]<mailto:[email-masked]>
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>

---

From: David Brown <[email-masked]>
Date: Fri, 15 Feb 2019 12:02:49 -0700

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

> 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

---

From: David Brown <[email-masked]>
Date: Fri, 15 Feb 2019 12:09:17 -0700

On Tue, Feb 12, 2019 at 12:01:54PM +0000, Amyas Phillips wrote:

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

For my prototype implementation, I parse the manifest very strictly.
I don't really interpret the instructions, just require them to have
a specific value.  Right now, the severable fields must be empty, but
it would not be difficult for me to allow them to be included (would
not expand the code all that much), especially if the bootloader
doesn't really care about what is in them.

Where our story is lacking is in the process of getting the image to
the device.  I do want to make sure that all of the concerns about
this process (including a device with multiple images) are addressed
while, as much as possible, not placing undue constraints on what the
bootloader does.  I believe I have an implementation of a manifest
verification that is small enough to be included in the bootloader,
and that it verifies the image hash, and the signature of the manifest
on every boot.

In other words, I'm pretty happy with this restricted manifest that
I'm seeing right now, but I realize that it may not be best for
incorporating other information.  Something like MCUboot will likely
want to keep its manifest parsing at about this level, where it
expects a very specific format for the manifest.

Thanks,
David

---

From: Brendan Moran <[email-masked]>
Date: Thu, 28 Feb 2019 15:38:28 +0000

Hi Frank,

I think you’re right that there may be threat vectors that arise from shedding some data, but not other data. I’m trying to adapt the shedding of data so that it works a bit better. Data should only be shed if it’s never needed again. For instance, you don’t need the information used to install a payload after that payload is installed. So, that information should be shed as a block. Likewise, you don’t need text once the manifest is pushed to a device, since this is for machine consumption only.

In attempting to improve the regularity of the manifest and to reduce this threat, I’m going to propose a few more reorganisations. Right now, the manifest consists of several kinds of information.

  *   mandatory information (structure version, sequence number)
  *   dependency information
  *   payload information
  *   Checks and actions to perform in each step of the manifest lifecycle
  *   Information about how to install the payload
  *   Text information

I think we could make this easier to parse by making the information about how to install the payload an action: set-payload-info. This would make the manifest more regular. It would also make an override scheme much more understandable: this directive could also be partially populated by a dependent, so that it could append or override URIs, formats (for example gateway decryption), etc.

I think we could also redefine the way that conditions and directives are packaged. Instead of each step in the lifecycle containing a list of conditions and a list of directives, I think it makes sense to make change this into a flat of conditions and directives. The implication is that condition codes must not overlap with directive codes.

Then, we could rearrange the lifecycle. It would become:

  1.  Dependency Fetch
  2.  Firmware installation

Then, to support secure boot, we could also have:

  1.  Validation
  2.  Load/boot

Best Regards,
Brendan

On 13 Feb 2019, at 13:37, Kvamtrø, Frank Audun <[email-masked]<mailto:[email-masked]>> wrote:

Regards
Frank Audun Kvamtrø

Hi Amyas,

Hi Frank,

Best Regards,
Brendan

Regards
Frank Audun Kvamtrø

Cc: [email-masked]<mailto:[email-masked]>; Brendan Moran <[email-masked]<mailto:[email-masked]>>; Amyas Phillips <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>

Thanks everyone
Amyas

Martin

Hi Amyas.

Best regards,
Øyvind Rønningstad

My vote is for option 5.

Many thanks
Amyas Phillips

SUIT_Digest = [

Best Regards,
Brendan

---

From: David Brown <[email-masked]>
Date: Thu, 28 Feb 2019 13:07:14 -0700

On Thu, Feb 28, 2019 at 03:38:28PM +0000, Brendan Moran wrote:

>I think you’re right that there may be threat vectors that arise from shedding
>some data, but not other data. I’m trying to adapt the shedding of data so that
>it works a bit better. Data should only be shed if it’s never needed again. For
>instance, you don’t need the information used to install a payload after that
>payload is installed. So, that information should be shed as a block. Likewise,
>you don’t need text once the manifest is pushed to a device, since this is for
>machine consumption only.

MCUboot has an interesting case/configuration where this isn't quite
true, about the installation.

MCUboot can be configured to perform "swap" upgrades.  Flash is
partitioned into a primary and an upgrade slot (and there is a scratch
area to use to do the swap with recovery).  After the image swap, it
tries running the new image.  If something goes wrong, and the image
is not able to boot up and mark itself as valid, the next reboot,
MCUboot will swap the two images back.

In this case, any information on installation would still need to be
there.  Although, also in this case, the installation is very simple,
and isn't going to be large (my current prototype does not include
it).

David