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

[Rønningstad, Øyvind <[e-mail]>]

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 <[e-mail]> On Behalf Of Amyas Phillips
Sent: Monday, February 11, 2019 14:12
To: Brendan Moran <[e-mail]>
Cc: [e-mail]; [e-mail]; Henk Birkholz <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/suit